You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Todd Lipcon (JIRA)" <ji...@apache.org> on 2016/10/04 05:04:20 UTC

[jira] [Resolved] (KUDU-400) cbtree-test failure: pointer used most significant bit

     [ https://issues.apache.org/jira/browse/KUDU-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Todd Lipcon resolved KUDU-400.
------------------------------
       Resolution: Cannot Reproduce
    Fix Version/s: n/a

This is over two years old and was likely fixed by ed01385a7bbdc40161f93cd42da7f59301c2c06e.

> cbtree-test failure: pointer used most significant bit
> ------------------------------------------------------
>
>                 Key: KUDU-400
>                 URL: https://issues.apache.org/jira/browse/KUDU-400
>             Project: Kudu
>          Issue Type: Bug
>          Components: tablet
>    Affects Versions: M4.5
>            Reporter: Adar Dembo
>             Fix For: n/a
>
>         Attachments: cbtree-test.txt
>
>
> 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.
> {noformat}
> [==========] 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
> {noformat}
> What's weird is that the stacktrace that followed came from a SIGSEGV, not a SIGABRT:
> {noformat}
> *** 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)
> {noformat}
> 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.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)