Actions
Bug #24124
closedabort in unittest_async_shared_mutex with clang/libc++
% Done:
0%
Source:
Tags:
asio
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):
Description
Two of the test cases in unittest_async_shared_mutex are aborting due to object lifetime issues:
[ RUN ] SharedMutex.async_prioritize_exclusive Program received signal SIGABRT, Aborted. 0x000000080179084a in thr_kill () from /lib/libc.so.7 (gdb) bt #0 0x000000080179084a in thr_kill () from /lib/libc.so.7 #1 0x0000000801790814 in raise () from /lib/libc.so.7 #2 0x0000000801790789 in abort () from /lib/libc.so.7 #3 0x000000000047697f in __clang_call_terminate () at memory:1105 #4 0x0000000000483bf9 in std::__1::__tuple_leaf<1ul, std::__1::shared_lock<ceph::async::SharedMutex<boost::asio::io_context::executor_type> >, false>::~__tuple_leaf (this=0x7fffffffd2c0) at shared_mutex:364 #5 0x0000000000483ba9 in _ZNSt3__112__tuple_implINS_15__tuple_indicesIJLm0ELm1EEEEJN5boost6system10error_codeENS_11shared_lockIN4ceph5async11SharedMutexINS3_4asio10io_context13executor_typeEEEEEEED2Ev (this=0x7fffffffd2b0) at tuple:369 #6 0x0000000000483ab5 in _ZNSt3__15tupleIJN5boost6system10error_codeENS_11shared_lockIN4ceph5async11SharedMutexINS1_4asio10io_context13executor_typeEEEEEEED2Ev (this=0x7fffffffd2b0) at tuple:474 #7 0x000000000046ea49 in _ZN4ceph5async17CompletionHandlerIZNS0_7captureERNSt3__18optionalIN5boost6system10error_codeEEERNS2_11shared_lockINS0_11SharedMutexINS4_4asio10io_context13executor_typeEEEEEE3$_1NS2_5tupleIJS6_SF_EEEED2Ev (this=0x7fffffffd2a0) at bind_handler.h:36 #8 0x000000000046ea25 in _ZN4ceph5async17ForwardingHandlerINS0_17CompletionHandlerIZNS0_7captureERNSt3__18optionalIN5boost6system10error_codeEEERNS3_11shared_lockINS0_11SharedMutexINS5_4asio10io_context13executor_typeEEEEEE3$_1NS3_5tupleIJS7_SG_EEEEEED2Ev (this=0x7fffffffd2a0) at forward_handler.h:38 #9 0x00000000004705d5 in _ZN5boost4asio6detail11executor_opIN4ceph5async17ForwardingHandlerINS4_17CompletionHandlerIZNS4_7captureERNSt3__18optionalINS_6system10error_codeEEERNS7_11shared_lockINS4_11SharedMutexINS0_10io_context13executor_typeEEEEEE3$_1NS7_5tupleIJSA_SI_EEEEEEENS7_9allocatorINS4_6detail14CompletionImplISG_SK_NS4_6AsBaseINSH_12AsyncRequestISD_EEEEJSA_SI_EEEEENS1_19scheduler_operationEE11do_completeEPvPSY_RKSA_m (owner=0x0, base=0x801e1c720) at executor_op.hpp:73 #10 0x000000000047fef0 in boost::asio::detail::scheduler_operation::destroy (this=0x801e1c720) at scheduler_operation.hpp:45 #11 0x000000000047fa31 in boost::asio::detail::scheduler::shutdown (this=0x801e48000) at scheduler.ipp:120 #12 0x00000000004801a0 in boost::asio::detail::service_registry::shutdown_services (this=0x801e1f060) at service_registry.ipp:44 #13 0x0000000000480108 in boost::asio::execution_context::shutdown (this=0x7fffffffdb68) at execution_context.ipp:41 #14 0x000000000047cfc9 in boost::asio::execution_context::~execution_context (this=0x7fffffffdb68) at execution_context.ipp:34 #15 0x0000000000477095 in boost::asio::io_context::~io_context (this=0x7fffffffdb68) at io_context.ipp:57 #16 0x000000000045d5e4 in ceph::async::SharedMutex_async_prioritize_exclusive_Test::TestBody (this=0x801e3c010) at /usr/home/cbodley/ceph/src/test/common/test_async_shared_mutex.cc:228
This happens because the async_lock() completion stores a std::unique_lock which holds a pointer to the SharedMutex. If the SharedMutex goes out of scope after a completion is scheduled, but before the io_context executes that completion, the unique_lock destructor will try to unlock a SharedMutex that has been destructed.
Actions