Major Description
Ran into this while running through TSAN tests. Been trying to repro it since, successfully did so once. The only difference in the test output the second time around was the lack of "Check failed..."; everything else was the same.
[==========] Running 15 tests from 1 test case. [----------] Global test environment set-up. [----------] 15 tests from TestCBTree [ RUN ] TestCBTree.TestNodeSizes [ OK ] TestCBTree.TestNodeSizes (3 ms) [ RUN ] TestCBTree.TestLeafNode [ OK ] TestCBTree.TestLeafNode (1 ms) [ RUN ] TestCBTree.TestLeafNodeBigKVs [ OK ] TestCBTree.TestLeafNodeBigKVs (1 ms) [ RUN ] TestCBTree.TestInsertAndVerify [ OK ] TestCBTree.TestInsertAndVerify (3503 ms) [ RUN ] TestCBTree.TestUpdate [ OK ] TestCBTree.TestUpdate (8 ms) [ RUN ] TestCBTree.TestInsertAndVerifyRandom [ OK ] TestCBTree.TestInsertAndVerifyRandom (179 ms) [ RUN ] TestCBTree.TestVersionLockSimple [ OK ] TestCBTree.TestVersionLockSimple (0 ms) [ RUN ] TestCBTree.TestVersionLockConcurrent [ OK ] TestCBTree.TestVersionLockConcurrent (223 ms) [ RUN ] TestCBTree.TestConcurrentInsert WARNING: Logging before InitGoogleLogging() is written to STDERR F0715 15:24:21.590517 44200 concurrent_btree.h:408] Check failed: !(p_int & kDiscriminatorBit) Pointer must not use most significant bit
What's weird is that the stacktrace that followed came from a SIGSEGV, not a SIGABRT:
*** Aborted at 1405463061 (unix time) try "date -d @1405463061" if you are using GNU date ***
*** Check failure stack trace: ***
PC: @ 0x7f29556882ed __tsan_atomic64_load
*** SIGSEGV (@0x18000001) received by PID 44174 (TID 0x7f294fffec40) from PID 402653185; stack trace: ***
@ 0x7f2955657114 rtl_sigaction() at ??:0
@ 0x7f2954876340 (unknown) at ??:0
@ 0x7f29556882ed __tsan_atomic64_load at ??:0
@ 0x7f29556c9b36 base::subtle::Acquire_Load() at ??:0
@ 0x7f29556c9a43 kudu::tablet::btree::VersionField::StableVersion() at ??:0
@ 0x7f29556ea5f1 kudu::tablet::btree::NodeBase<>::StableVersion() at ??:0
@ 0x7f29556ee599 kudu::tablet::btree::CBTree<>::StableRoot() at ??:0
@ 0x7f29556edaec kudu::tablet::btree::CBTree<>::TraverseToLeaf() at ??:0
@ 0x7f295570412b kudu::tablet::btree::CBTree<>::PrepareMutation() at ??:0
@ 0x7f29556c09ed kudu::tablet::btree::PreparedMutation<>::Prepare() at ??:0
@ 0x7f29556bf521 kudu::tablet::btree::CBTree<>::Insert() at ??:0
@ 0x7f29556f38e3 kudu::tablet::btree::InsertRange<>() at ??:0
@ 0x7f29556c3cfb kudu::tablet::btree::InsertAndVerify<>() at ??:0
@ 0x7f29556f2c45 boost::_bi::list5<>::operator()<>() at ??:0
@ 0x7f29556f2a18 boost::_bi::bind_t<>::operator()() at ??:0
@ 0x7f29556f299a boost::detail::thread_data<>::run() at ??:0
@ 0x7f2954c93a4a (unknown) at ??:0
@ 0x7f295564c3d5 __tsan_thread_start_func at ??:0
@ 0x7f295486e182 start_thread at ??:0
@ 0x7f295358d30d (unknown) at ??:0
@ 0x0 (unknown)
I've attached the full test output. It has a bunch of warnings from TSAN about signal-unsafe calls inside the signal handler which I think can be ignored.