SIGSEGV on db open

Rocksdb version: 5.14.2
JVM version: JDK-1_8_0_72

### Actual behavior: Segmentation fault during rocksdb open. This wasn't happening in the past and we have been on this version for almost 3 months now. Please let me know if any other information would be helpful

Stack trace:

```
R14=0x00007f7ce3ffb060: in /export/content/lid/apps/followfeed-storage/50b8fc1343aa4fbdcfd954006b616c5e8a73e5ef/tmp/librocksdbjni2249206131915847291.so at 0x00007f7ce3701000
R15=0x000000000000003a is an unknown value

Stack: [0x00007f7ab04f6000,0x00007f7ab05f7000], sp=0x00007f7ab05f4650, free space=1017k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [librocksdbjni2249206131915847291.so+0x4435d5] rocksdb::InstrumentedMutex::Lock()+0x125
C [librocksdbjni2249206131915847291.so+0x382962] rocksdb::DBImpl::Open(rocksdb::DBOptions const&, std::string const&, std::vector > const&, std::vector >*, rocksdb::DB**, bool)+0x9b2
C [librocksdbjni2249206131915847291.so+0x383c58] rocksdb::DB::Open(rocksdb::DBOptions const&, std::string const&, std::vector > const&, std::vector >*, rocksdb::DB**)+0x18
C [librocksdbjni2249206131915847291.so+0x384322] rocksdb::DB::Open(rocksdb::Options const&, std::string const&, rocksdb::DB**)+0x6b2
C [librocksdbjni2249206131915847291.so+0x2db03a] std::_Function_handler::_M_invoke(std::_Any_data const&, rocksdb::Options const&, std::string const&, rocksdb::DB**)+0x1a
C [librocksdbjni2249206131915847291.so+0x2d32fe] rocksdb_open_helper(JNIEnv_*, long, _jstring*, std::function)+0x7e
C [librocksdbjni2249206131915847291.so+0x2d343e] Java_org_rocksdb_RocksDB_open__JLjava_lang_String_2+0x3e
j org.rocksdb.RocksDB.open(JLjava/lang/String;)J+0
J 15025 C1 com.linkedin.utils.rocksdb.RocksDBAccessor.open(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Lcom/linkedin/utils/rocksdb/RocksDbConfig;Lcom/linkedin/followfeed/publicapis/metrics/Sensor;)Lcom/linkedin/utils/rocksdb/RocksDBAccessor; (181 bytes) @ 0x00007f96a3dc59b4 [0x00007f96a3dc4f60+0xa54]
j com.linkedin.utils.rocksdb.RocksDBStorageImpl.lambda$openDb$1(I)V+101
j com.linkedin.utils.rocksdb.RocksDBStorageImpl$$Lambda$131.run()V+8
J 14343 C1 java.util.concurrent.Executors$RunnableAdapter.call()Ljava/lang/Object; (14 bytes) @ 0x00007f96a1630a0c [0x00007f96a1630900+0x10c]
J 14346 C1 java.util.concurrent.FutureTask.run()V (126 bytes) @ 0x00007f96a365f784 [0x00007f96a365f540+0x244]
J 14343 C1 java.util.concurrent.Executors$RunnableAdapter.call()Ljava/lang/Object; (14 bytes) @ 0x00007f96a1630a0c [0x00007f96a1630900+0x10c]
J 14346 C1 java.util.concurrent.FutureTask.run()V (126 bytes) @ 0x00007f96a365f784 [0x00007f96a365f540+0x244]
J 14676 C1 java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V (225 bytes) @ 0x00007f96a3c91abc [0x00007f96a3c90ae0+0xfdc]
J 14461 C1 java.util.concurrent.ThreadPoolExecutor$Worker.run()V (9 bytes) @ 0x00007f96a13a6c04 [0x00007f96a13a6b00+0x104]
J 14358 C1 java.lang.Thread.run()V (17 bytes) @ 0x00007f96a14bdabc [0x00007f96a14bd980+0x13c]
v ~StubRoutines::call_stub
V [libjvm.so+0x68c616] JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x1056
V [libjvm.so+0x68cb21] JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x321
V [libjvm.so+0x68cfc7] JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*)+0x47
V [libjvm.so+0x723d80] thread_entry(JavaThread*, Thread*)+0xa0
V [libjvm.so+0xa69dcf] JavaThread::thread_main_inner()+0xdf
V [libjvm.so+0xa69efc] JavaThread::run()+0x11c
V [libjvm.so+0x91d9d8] java_start(Thread*)+0x108
C [libpthread.so.0+0x7dd5] start_thread+0xc5
```

### Steps to reproduce the behavior: The issue is happening intermittently and we do not have a specific way to reproduce at this point.