Project

General

Profile

Bug #24124

abort in unittest_async_shared_mutex with clang/libc++

Added by Casey Bodley over 1 year ago. Updated about 1 year ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
05/14/2018
Due date:
% Done:

0%

Source:
Tags:
asio
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:

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.

History

#1 Updated by Casey Bodley over 1 year ago

  • Status changed from Verified to In Progress

#2 Updated by Casey Bodley about 1 year ago

  • Status changed from In Progress to Resolved

Also available in: Atom PDF