undefined symbol: clock_gettime

[pshareghi]

Using Centos 6 GCC 4.9 using devtools-3 Java 7 Kernel 2.6.32-504.12.2.el6.x86_64

I am getting the following error after running a test for a while. /usr/java/latest/bin/java: symbol lookup error: /tmp/librocksdbjni2974434001434564758..so: undefined symbol: clock_gettime

The same test runs fine on RocksDb 3.6. My investigation shows that librt.so is not linked with RocksDb correctly. My test (with 3.10.2) worked correctly after I ran export LD_PRELOAD=/lib64/rtkaio/librt.so.1

To investigate the 3.10.2 library, I ran nm $nm /tmp/librocksdbjni2974434001434564758..so | grep clock 0000000000332260 T _ZNSt6chrono3_V212steady_clock3nowEv 000000000037e33c R _ZNSt6chrono3_V212steady_clock9is_steadyE 0000000000332230 T _ZNSt6chrono3_V212system_clock3nowEv 000000000037e33d R _ZNSt6chrono3_V212system_clock9is_steadyE U clock_gettime

I ran nm on the older rocksdb-3.6 nm /tmp/librocksdbjni1323312933457066341..so |grep clock 0000000000287390 T _ZNSt6chrono3_V212steady_clock3nowEv 00000000002c783c R _ZNSt6chrono3_V212steady_clock9is_steadyE 0000000000287360 T _ZNSt6chrono3_V212system_clock3nowEv 00000000002c783d R _ZNSt6chrono3_V212system_clock9is_steadyE

You can see that clock_gettime is undefined in 3.10.2 highlighted in the result of first nm command. Looking at the code, the single call to this function is only included in the C++ code if OS_LINUX or OS_FREEBSD is defined.

Judging from the above nm results, do you think, in 3.6, none of the two flags above were set, where as in 3.10, somehow at least one gets set?

[igorcanadi]

Interesting. We do set -lrt when we compile: https://github.com/facebook/rocksdb/blob/master/build_tools/build_detect_platform#L125

Do we need to set something other than -lrt? Do you see that flag in your compile log?

[DerekSchenk]

I'm experiencing the same issue using the rocksdbjni 3.10.2 jar from Maven, running on Centos 6.6.

Using Centos 6.6 2.6.32-504.16.2.el6.x86_64 #1 SMP Wed Apr 22 06:48:29 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux java version "1.8.0_40"

I was using version 3.9.1 previously, and had no issues. This is the nm results:

3.9.1: # nm librocksdbjni-linux64.so | grep clock
00000000002408b0 T _ZNSt6chrono12system_clock3nowEv

3.10.1: ]# nm librocksdbjni-linux64.so | grep clock
0000000000295690 T _ZNSt6chrono12system_clock3nowEv
                 U clock_gettime

I build the library from the latest, this is the results:

\ To save others from possible frustration contrary to the INSTALL.md details... 1) gcc version 4.8+ is required on Centos, not 4.7. Without this compiling fails with:

  CC       util/thread_status_impl.o
util/thread_status_impl.cc: In static member function ‘static std::map<std::basic_string<char>, long unsigned int> rocksdb::ThreadStatus::InterpretOperationProperties(rocksdb::ThreadStatus::OperationType, const uint64_t*)’:
util/thread_status_impl.cc:88:20: error: ‘class std::map<std::basic_string<char>, long unsigned int>’ has no member named ‘emplace’
util/thread_status_impl.cc:90:20: error: ‘class std::map<std::basic_string<char>, long unsigned int>’ has no member named ‘emplace’
util/thread_status_impl.cc:94:20: error: ‘class std::map<std::basic_string<char>, long unsigned int>’ has no member named ‘emplace’
util/thread_status_impl.cc:96:20: error: ‘class std::map<std::basic_string<char>, long unsigned int>’ has no member named ‘emplace’
util/thread_status_impl.cc:98:20: error: ‘class std::map<std::basic_string<char>, long unsigned int>’ has no member named ‘emplace’
util/thread_status_impl.cc:101:20: error: ‘class std::map<std::basic_string<char>, long unsigned int>’ has no member named ‘emplace’
make: *** [util/thread_status_impl.o] Error 1

2) 'yum install gcc47-c++' does not work. Follow the instructions at http://superuser.com/questions/381160/how-to-install-gcc-4-7-x-4-8-x-on-centos for 4.8

wget http://people.centos.org/tru/devtools-2/devtools-2.repo -O /etc/yum.repos.d/devtools-2.repo
yum install devtoolset-2-gcc devtoolset-2-binutils devtoolset-2-gcc-c++
export PATH=/opt/rh/devtoolset-2/root/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin
export CC=/opt/rh/devtoolset-2/root/usr/bin/gcc
export CPP=/opt/rh/devtoolset-2/root/usr/bin/cpp
export CXX=/opt/rh/devtoolset-2/root/usr/bin/c++

When running 'make shared_lib' it does appear to include the -lrt flag, but clock_gettime is still undefined:

/opt/rh/devtoolset-2/root/usr/bin/c++ -shared -Wl,-soname -Wl,librocksdb.so.3.11  -g -W -Wextra -Wall -Wsign-compare -Wshadow -Wno-unused-parameter -I. -I./include -std=c++11  -DROCKSDB_PLATFORM_POSIX  -DOS_LINUX -fno-builtin-memcmp -DROCKSDB_FALLOCATE_PRESENT -DSNAPPY -DGFLAGS=google -DZLIB -DBZIP2 -march=native   -isystem ./third-party/gtest-1.7.0/fused-src -O2 -fno-omit-frame-pointer -momit-leaf-frame-pointer -DNDEBUG -Woverloaded-virtual -Wnon-virtual-dtor -Wno-missing-field-initializers -fPIC db/builder.cc db/c.cc db/column_family.cc db/compaction.cc db/compaction_job.cc db/compaction_picker.cc db/db_filesnapshot.cc db/dbformat.cc db/db_impl.cc db/db_impl_debug.cc db/db_impl_readonly.cc db/db_impl_experimental.cc db/db_iter.cc db/experimental.cc db/event_logger_helpers.cc db/file_indexer.cc db/filename.cc db/flush_job.cc db/flush_scheduler.cc db/forward_iterator.cc db/internal_stats.cc db/log_reader.cc db/log_writer.cc db/managed_iterator.cc db/memtable_allocator.cc db/memtable.cc db/memtable_list.cc db/merge_helper.cc db/merge_operator.cc db/repair.cc db/slice.cc db/table_cache.cc db/table_properties_collector.cc db/transaction_log_impl.cc db/version_builder.cc db/version_edit.cc db/version_set.cc db/wal_manager.cc db/write_batch.cc db/write_batch_base.cc db/write_controller.cc db/write_thread.cc port/stack_trace.cc port/port_posix.cc table/adaptive_table_factory.cc table/block_based_filter_block.cc table/block_based_table_builder.cc table/block_based_table_factory.cc table/block_based_table_reader.cc table/block_builder.cc table/block.cc table/block_hash_index.cc table/block_prefix_index.cc table/bloom_block.cc table/cuckoo_table_builder.cc table/cuckoo_table_factory.cc table/cuckoo_table_reader.cc table/flush_block_policy.cc table/format.cc table/full_filter_block.cc table/get_context.cc table/iterator.cc table/merger.cc table/meta_blocks.cc table/plain_table_builder.cc table/plain_table_factory.cc table/plain_table_index.cc table/plain_table_key_coding.cc table/plain_table_reader.cc table/table_properties.cc table/two_level_iterator.cc util/arena.cc util/auto_roll_logger.cc util/bloom.cc util/build_version.cc util/cache.cc util/coding.cc util/comparator.cc util/crc32c.cc util/db_info_dumper.cc util/dynamic_bloom.cc util/env.cc util/env_hdfs.cc util/env_posix.cc util/file_util.cc util/filter_policy.cc util/hash.cc util/hash_cuckoo_rep.cc util/hash_linklist_rep.cc util/hash_skiplist_rep.cc util/histogram.cc util/instrumented_mutex.cc util/iostats_context.cc utilities/backupable/backupable_db.cc utilities/convenience/convenience.cc utilities/checkpoint/checkpoint.cc utilities/compacted_db/compacted_db_impl.cc utilities/document/document_db.cc utilities/document/json_document_builder.cc utilities/document/json_document.cc utilities/flashcache/flashcache.cc utilities/geodb/geodb_impl.cc utilities/leveldb_options/leveldb_options.cc utilities/merge_operators/put.cc utilities/merge_operators/string_append/stringappend2.cc utilities/merge_operators/string_append/stringappend.cc utilities/merge_operators/uint64add.cc utilities/redis/redis_lists.cc utilities/spatialdb/spatial_db.cc utilities/ttl/db_ttl_impl.cc utilities/write_batch_with_index/write_batch_with_index.cc utilities/write_batch_with_index/write_batch_with_index_internal.cc util/event_logger.cc util/ldb_cmd.cc util/ldb_tool.cc util/log_buffer.cc util/logging.cc util/memenv.cc util/murmurhash.cc util/mutable_cf_options.cc util/options_builder.cc util/options.cc util/options_helper.cc util/perf_context.cc util/rate_limiter.cc util/skiplistrep.cc util/slice.cc util/sst_dump_tool.cc util/statistics.cc util/status.cc util/string_util.cc util/sync_point.cc util/thread_local.cc util/thread_status_impl.cc util/thread_status_updater.cc util/thread_status_updater_debug.cc util/thread_status_util.cc util/thread_status_util_debug.cc util/vectorrep.cc util/xfunc.cc util/xxhash.cc   -lpthread -lrt -lsnappy -lgflags -lz -lbz2 -o librocksdb.so.3.11.0

# nm librocksdb.so | grep clock
                 U clock_gettime@@GLIBC_2.2.5
0000000000250630 T _ZNSt6chrono3_V212steady_clock3nowEv
0000000000262be0 R _ZNSt6chrono3_V212steady_clock9is_steadyE
0000000000250600 T _ZNSt6chrono3_V212system_clock3nowEv
0000000000262be1 R _ZNSt6chrono3_V212system_clock9is_steadyE

I'm not sure what to check next, however if you have suggestions I'm happy to try.

[pshareghi]

One thing I don't understand is how clock_gettime was not included at all in Rocksdb 3.6, but now it shows up unlinked.

I don't have time to try and build but one suggestion I found online is to use -Wl,--no-as-needed

http://stackoverflow.com/questions/17150075/undefined-reference-to-clock-gettime-although-lrt-is-given

From ld man:

--as-needed
       --no-as-needed
           This option affects ELF DT_NEEDED tags for dynamic libraries
           mentioned on the command line after the --as-needed option.
           Normally the linker will add a DT_NEEDED tag for each dynamic
           library mentioned on the command line, regardless of whether the
           library is actually needed or not.  --as-needed causes a DT_NEEDED
           tag to only be emitted for a library that satisfies an undefined
           symbol reference from a regular object file or, if the library is
           not found in the DT_NEEDED lists of other libraries linked up to
           that point, an undefined symbol reference from another dynamic
           library.  --no-as-needed restores the default behaviour.

[pshareghi]

@igorcanadi if you can explain how clock_gettime was not included at all in Rocksdb 3.6 or 3.9.1, but now it shows up unlinked, that would be very helpful. Also, it looks like the code in older Rocksdb versions did not reference clock_gettime at all. I looked at build_detect_platform, but I don't see a big change that may have caused the code to start using clock_gettime. Any idea?

[DerekSchenk]

I found the same article, and I tried to change the build_detect_platform and set the following:

Linux)
        PLATFORM=OS_LINUX
        COMMON_FLAGS="$COMMON_FLAGS -DOS_LINUX"
        if [ -z "$USE_CLANG" ]; then
            COMMON_FLAGS="$COMMON_FLAGS -fno-builtin-memcmp"
        fi
        PLATFORM_LDFLAGS="$PLATFORM_LDFLAGS -Wl,--no-as-needed -lpthread -lrt"

But the output of nm is still:

# nm librocksdb.so | grep clock
                 U clock_gettime@@GLIBC_2.2.5
0000000000250630 T _ZNSt6chrono3_V212steady_clock3nowEv
0000000000262be0 R _ZNSt6chrono3_V212steady_clock9is_steadyE
0000000000250600 T _ZNSt6chrono3_V212system_clock3nowEv
0000000000262be1 R _ZNSt6chrono3_V212system_clock9is_steadyE

I also see that clock_gettime was not included in the 3.9.1 release, so it looks new to 3.10.

It's worth noting that setting the workaround you defined export LD_PRELOAD=/lib64/rtkaio/librt.so.1 worked to let me startup the code.

[pshareghi]

@DerekSchenk What are you running that you get the clock_gettime error? I didn't see the error in our production env. I only noticed it when I tried to write a million dummy KVs to a dummy db to see the effect of Snappy compression vs NO_COMPRESSION. Do you know if it happens during read, write, or is it the statistics gathering piece of code that is causing this issue?

[DerekSchenk]

@pshareghi I'm not 100% certain, but it seems to happen when I initialize the database. I think it's caused because I use ".createStatistics()", but I do have compression enabled as well. I'd need to try a few scenarios to see for sure. If it's in fact the statistics I can disable that and work without it, but at the moment I can't upgrade at all.

[pshareghi]

I think it is statistics calculation that triggers the issue. I checked my LOG file when the problem happened, and it was in the middle of printing out the statistics.

[DerekSchenk]

@pshareghi Thanks for the tip - I can confirm that the issue is triggered when including statistics. I removed the call to .createStatistics() and I can use the 3.10 version. This was not an issue in the 3.9 release. While I do use the stats I can live without them for know.

[igorcanadi]

@igorcanadi if you can explain how clock_gettime was not included at all in Rocksdb 3.6 or 3.9.1, but now it shows up unlinked, that would be very helpful. Also, it looks like the code in older Rocksdb versions did not reference clock_gettime at all. I looked at build_detect_platform, but I don't see a big change that may have caused the code to start using clock_gettime. Any idea?

RocksDB 3.6 did call clock_gettime: https://github.com/facebook/rocksdb/blob/rocksdb-3.6.1/util/env_posix.cc#L1362 so I have no idea why it's showing up as unlinked right now and it worked before :(

[igorcanadi]

@DerekSchenk thanks for the report that our compilation doesn't work on gcc 4.7. We fixed this with https://github.com/facebook/rocksdb/commit/74f3832d85e932ed485a4f8d8c01b0adc6b3e502. We should probably set up contbuild using 4.7 to make sure this doesn't happen again.

[igorcanadi]

Are you both guys running with shared library?

[DerekSchenk]

@igorcanadi Something that occurred to me - is it possible that the newer build running against gcc 4.8 has linked a newer version of glibc (ie 2.2.5), and all my Centos 6.6 machines are runing glibc 2.12? That may explain how it worked in 3.9 (using gcc 4.7), and why it works on other platforms?

I am pulling the jar from Maven, and it uses the shared library. When I built it myself I also built shared.

[igorcanadi]

@DerekSchenk can you try building with gcc 4.7 on master now? If this works, it will partially verify your hypothesis.

[igorcanadi]

what does ldd binary give you?

[DerekSchenk]

# ldd --version 
ldd (GNU libc) 2.12
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

[igorcanadi]

ldd librocksdb.so

[DerekSchenk]

This is the output:

Version 3.9

r3.9 # ldd librocksdbjni-linux64.so 
    linux-vdso.so.1 =>  (0x00007fff074e8000)
    libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f4172820000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f417259c000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f4172385000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f4171ff1000)
    /lib64/ld-linux-x86-64.so.2 (0x0000003862e00000)

Version 3.10

r3.10 # ldd librocksdbjni-linux64.so 
    linux-vdso.so.1 =>  (0x00007ffff0e3d000)
    libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f5fcafd1000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f5fcad4d000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f5fcab36000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f5fca7a2000)
    /lib64/ld-linux-x86-64.so.2 (0x0000003862e00000)

And my attempt to build from head last week

# ldd librocksdb.so
    linux-vdso.so.1 =>  (0x00007fff09bff000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3e8c21a000)
    librt.so.1 => /lib64/librt.so.1 (0x00007f3e8c012000)
    libsnappy.so.1 => /usr/lib64/libsnappy.so.1 (0x00007f3e8be0c000)
    libgflags.so.2 => not found
    libz.so.1 => /lib64/libz.so.1 (0x00007f3e8bbf6000)
    libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f3e8b9e4000)
    libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f3e8b6de000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f3e8b45a000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f3e8b243000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f3e8aeaf000)
    /lib64/ld-linux-x86-64.so.2 (0x0000003862e00000)

I just updated on my build machine and will try building again using 4.7.

[DerekSchenk]

@igorcanadi The master build 'make shared_lib' now works on gcc 4.7, however it still looks as though it's not linked properly.

I should have probably know this already as the gcc version 4.7 is not fully installed either. The most up to date version of gcc you can get for Centos 6 through yum is 4.6, so I've got 4.7 and 4.8 installed in alternate locations. The yum command `yum install gcc47-c++' just gets your hopes up, then yum lets you down ;)

This is the output of the version I just built:

# nm librocksdb.so.3.11.0 | grep clock
                 U clock_gettime@@GLIBC_2.2.5
                 U _ZNSt6chrono12system_clock3nowEv@@GLIBCXX_3.4.11

# ldd librocksdb.so.3.11.0
    linux-vdso.so.1 =>  (0x00007fff779b1000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f569d50f000)
    librt.so.1 => /lib64/librt.so.1 (0x00007f569d307000)
    libsnappy.so.1 => /usr/lib64/libsnappy.so.1 (0x00007f569d101000)
    libgflags.so.2 => not found
    libz.so.1 => /lib64/libz.so.1 (0x00007f569ceeb000)
    libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f569ccd9000)
    libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f569c9d3000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f569c74f000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f569c538000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f569c1a4000)
    /lib64/ld-linux-x86-64.so.2 (0x0000003862e00000)

I wanted to run the test cases to see if it still fails, but 'make check' fails:

# make check
  GEN      util/build_version.cc
  CC       db/log_writer.o
db/log_writer.cc: In member function ‘rocksdb::Status rocksdb::log::Writer::AddRecord(const rocksdb::Slice&)’:
db/log_writer.cc:55:5: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]

[igorcanadi]

@DerekSchenk I'm not sure why our compiler doesn't complain about that. I fixed it here: https://github.com/facebook/rocksdb/commit/04feaeebb922c3af6fb08762326753d93231e000

[DerekSchenk]

@igorcanadi Thanks - that fix worked. I was able to compile and run this time. I was hoping one of the tests would it the clock_gettime call and confirm if it was working or not. Do you know what test would be a good one to confirm?

Off topic, not sure if you want this in a different issue, but the check run fails on one of the environment tests.

[ RUN      ] EnvPosixTest.AllocateTest
util/env_test.cc:686: Failure
Expected: ((f_stat.st_size + kPageSize + kBlockSize - 1) / kBlockSize) >= ((unsigned int)f_stat.st_blocks), actual: 2056 vs 204800
terminate called after throwing an instance of 'testing::internal::GoogleTestFailureException'
  what():  util/env_test.cc:686: Failure
Expected: ((f_stat.st_size + kPageSize + kBlockSize - 1) / kBlockSize) >= ((unsigned int)f_stat.st_blocks), actual: 2056 vs 204800
/bin/sh: line 5: 15873 Aborted                 (core dumped) ./$t
make: *** [check] Error 1

[igorcanadi]

Yes, please create the different issue for this one.

db_test calls clock_gettime a lot, so if it succeeded, then all is fine.

[pshareghi]

@igorcanadi I am building using I am not building shared libraries. My build command is make rocksdbjavastatic

Also, I am using GCC 4.9

yum install -y devtoolset-3-gcc-c++

ldd ./librocksdbjni-linux64.so
    linux-vdso.so.1 =>  (0x00007fffbb6f1000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f025d0ac000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f025cd0b000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f025d952000)

[pshareghi]

@DerekSchenk try this super simple test. I shamelessly modified RocksDbSample.java. Even though I commented out createStatistics(), it still dies halfway. https://gist.github.com/pshareghi/4f8852fc92272098b8da

[DerekSchenk]

@pshareghi I pulled down the RocksDbSample.java, and using the copy I built it worked (completed the test) if I removed the call to .createStatistics(), as well as the Statistics creation 'Statistics stats = options.statisticsPtr();', and the lines following 'db.getProperty("rocksdb.stats");'.

With those lines included the test fails every time with the missing symbol error.

I got looking at the build script for rocksdbjavastatic which doesn't work, and I realized the the LDFLAGS, notably -lrt isn't being passed when the library is created.

@igorcanadi Not sure if this is correct or not, but when I modified the Makefile, and changed the compile to this below line I'm able to build the Java library, and run the RocksDbSample.java file unmodified and it works properly

$(CXX) $(CXXFLAGS) -I./java/. $(JAVA_INCLUDE) -shared -fPIC \
          -o ./java/target/$(ROCKSDBJNILIB) $(JNI_NATIVE_SOURCES) \
          $(java_libobjects) $(COVERAGEFLAGS) \
          libz.a libbz2.a libsnappy.a liblz4.a $(LDFLAGS)

• Note the inclusion of $(LDFLAGS)

Original Makefile output

# java -cp java/target/rocksdbjni-3.11.0-linux64.jar:. TestNoCompression /tmp/test.db
You get a car test!
Wrote 0 keys (cumulative).
Wrote 10000 keys (cumulative).
....
Wrote 200000 keys (cumulative).
java: symbol lookup error: /datex/nexus/tmp/librocksdbjni5613367140043562332..so: undefined symbol: clock_gettime

Output with the LDFLAGS modification

# java -cp java/target/rocksdbjni-3.11.0-linux64.jar:. TestNoCompression /tmp/test.db
You get a car test!
Wrote 0 keys (cumulative).
Wrote 10000 keys (cumulative).
....
Wrote 990000 keys (cumulative).
stats:

** Compaction Stats [default] **
Level    Files   Size(MB) Score Read(GB)  Rn(GB) Rnp1(GB) Write(GB) Wnew(GB) Moved(GB) W-Amp Rd(MB/s) Wr(MB/s) Comp(sec) Comp(cnt) Avg(sec) Stall(cnt)  KeyIn KeyDrop
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
  L0      2/1         90   0.5      0.0     0.0      0.0       0.4      0.4       0.0   0.0      0.0    137.7         3        10    0.327          0       0      0
  L1     10/3         94   0.8      0.4     0.4      0.1       0.4      0.4       0.0   1.2    145.9    145.8         3         7    0.437          6    734K      0
  L2     21/0        266   0.3      0.0     0.0      0.0       0.0      0.0       0.2   1.5    125.0    125.0         0         1    0.290          0     49K      0
 Sum     33/4        450   0.0      0.5     0.4      0.1       0.9      0.8       0.2   2.1     72.9    140.9         7        18    0.368          6    784K      0
 Int      0/0          0   0.0      0.5     0.4      0.1       0.8      0.7       0.2   2.3     78.3    136.6         6        16    0.386          6    784K      0
Flush(GB): cumulative 0.439, interval 0.351
Stalls(count): 0 level0_slowdown, 0 level0_numfiles, 0 memtable_compaction, 6 leveln_slowdown_soft, 0 leveln_slowdown_hard

** DB Stats **
Uptime(secs): 11.0 total, 8.2 interval
Cumulative writes: 1000K writes, 1000K keys, 1000K batches, 1.0 writes per batch, ingest: 0.49 GB, 45.15 MB/s
Cumulative WAL: 1000K writes, 1000K syncs, 1.00 writes per sync, written: 0.49 GB, 45.15 MB/s
Cumulative stall: 00:00:0.000 H:M:S, 0.0 percent
Interval writes: 794K writes, 794K keys, 794K batches, 1.0 writes per batch, ingest: 394.56 MB, 47.86 MB/s
Interval WAL: 794K writes, 794K syncs, 1.00 writes per sync, written: 0.39 MB, 47.86 MB/s
Interval stall: 00:00:0.000 H:M:S, 0.0 percent

[igorcanadi]

Oh interesting. I'm actually not familiar with RocksJava compilation, but this change looks good to me. @yhchiang @fyrz @adamretter can you please evaluate the change? @DerekSchenk feel free to send the PR :)

[DerekSchenk]

@igorcanadi I've created a PR (should have probably waited until morning :) ) for this issue. Hope everything is fine.

[yhchiang]

@DerekSchenk: Thanks for the patch. The patch looks good to me. Once you've signed the Contributor License Agreement, I will proceed the merge :)

[adamretter]

@igorcanadi I have never used the static build of Rocks Java and I don't really know enough about C++ to say whether these linked changes are correct. @yhchiang seems to think they are fine, so that is also fine by me :-)

[fyrz]

same with me.

[DerekSchenk]

@yhchiang I've signed the CLA.

[DerekSchenk]

@igorcanadi I see that your releasing 3.11 shortly. Is there any chance that this patch will make it, so that the Maven package for RocksDB java gets updated with the fix?

[igorcanadi]

3.11 is already released internally. We can create 3.11.1 with the patch.

[pshareghi]

Thanks everyone!

[DerekSchenk]

@igorcanadi Do you have an approx date for a 3.11.1 release? I'd like to get this update rolled out to address a SEGV issue I'm having.

[igorcanadi]

How about next Wednesday?

[DerekSchenk]

Sure that would be great. Thanks.

[fyrz]

@igorcanadi did you release 3.11.1 yet ? It would be great if we can get 3.11.1 on maven central because it affects also the latest maven artifacts 3.10 - 3.10.1

[igorcanadi]

There you go guys: https://github.com/facebook/rocksdb/releases/tag/rocksdb-3.11.1

[DerekSchenk]

@igorcanadi Thanks! What's the process for getting this updated on maven central?

[igorcanadi]

I have no idea. @fyrz and @adamretter would know :)

[adamretter]

@igorcanadi @DerekSchenk To do this someone needs to have permission for the group id org.rocksdb I guess that is @criccomini. It would be good actually to get some more people approved for this.

[fyrz]

@adamretter another requirement is that people need access to MacOS. Just to be complete :-)

[adamretter]

@fyrz Ah yes, that's right. I wonder how @igorcanadi is doing with getting us a Mac build machine?

[fyrz]

@igorcanadi did you also see this: http://stackoverflow.com/questions/30706348/rocksdb-make-error ?

[igorcanadi]

Ah, crap. My least-favorite kind of bugs. I hope https://reviews.facebook.net/D39681 will fix.

[DerekSchenk]

@igorcanadi @adamretter @fryz Any idea on when a 3.11.1 might make it to Maven? I'm looking to update a large number of instances to address the SIGSEGV issue 547 that I was having, and I'd like to update them all with an "official" 3.11.1 release from Maven. Let me know if there is anything I can do to assist.

[snowtopcoffee]

@igorcanadi @adamretter @fryz when 3.11.1 might download from Maven? I really need it, thank you so much !

[fyrz]

@pyscala it really depends on @criccomini.

[FelixGV]

I believe @naveenatceg can also publish the artifacts to Maven.