Bug #47039
closedclient: mutex lock FAILED ceph_assert(nlock > 0)
0%
Description
/data/ceph/src/common/mutex_debug.h: In function 'void ceph::mutex_debug_detail::mutex_debug_impl<<anonymous> >::_pre_unlock() [with bool Recursive = false]' thread 7f6427fff700 time 2020-08-19T08:47:43.812354-0400 /data/ceph/src/common/mutex_debug.h: 159: FAILED ceph_assert(nlock > 0) /data/ceph/src/common/mutex_debug.h: In function 'void ceph::mutex_debug_detail::mutex_debug_impl<<anonymous> >::_pre_unlock() [with bool Recursive = false]' thread 7f641ffff700 time 2020-08-19T08:47:43.812390-0400 /data/ceph/src/common/mutex_debug.h: 159: FAILED ceph_assert(nlock > 0) ceph version 16.0.0-4464-gc0f44e002b (c0f44e002b606e01a85213b09fa5f43217e3a62a) pacific (dev) 1: (ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0x1aa) [0x7f6454f9aa2a] 2: (()+0x165dcac) [0x7f6454f9acac] 3: (ceph::mutex_debug_detail::mutex_debug_impl<false>::_pre_unlock()+0x35) [0x7f645e7cc18b] 4: (ceph::mutex_debug_detail::mutex_debug_impl<false>::unlock(bool)+0x1d) [0x7f645e7c7fd5] 5: (std::scoped_lock<ceph::mutex_debug_detail::mutex_debug_impl<false> >::~scoped_lock()+0x20) [0x7f645e7c736e] 6: (()+0xb8f73) [0x7f645e7f4f73] 7: (Messenger::ms_deliver_dispatch(boost::intrusive_ptr<Message> const&)+0xe9) [0x7f645515573f] 8: (DispatchQueue::entry()+0x61d) [0x7f645515419f] 9: (DispatchQueue::DispatchThread::entry()+0x1c) [0x7f64552d111e] 10: (Thread::entry_wrapper()+0x78) [0x7f6454f36c48] 11: (Thread::_entry_func(void*)+0x18) [0x7f6454f36bc6] 12: (()+0x82de) [0x7f64529cc2de] 13: (clone()+0x43) [0x7f645e475133]
Updated by Xiubo Li over 3 years ago
Introduced by https://github.com/ceph/ceph/pull/35410 ?
Updated by Patrick Donnelly over 3 years ago
Xiubo Li wrote:
Introduced by https://github.com/ceph/ceph/pull/35410 ?
I don't think so. The commit looks to be using the unique_lock properly.
Updated by Xiubo Li over 3 years ago
Patrick Donnelly wrote:
Xiubo Li wrote:
Introduced by https://github.com/ceph/ceph/pull/35410 ?
I don't think so. The commit looks to be using the unique_lock properly.
Yeah, it is.
Updated by Xiubo Li over 3 years ago
IMO, it is not safe to use the client_lock.lock/.unlock diretctly without any check before it, if we use them we'd better to do the ceph_assert(ceph_mutex_is_locked_by_me(client_lock)) check first.
Updated by Xiubo Li over 3 years ago
- Status changed from New to In Progress
Checked the whole libcephfs code, didn't find any suspicious code about it. And I have one enhancement about the client_lock related code.
Updated by Xiubo Li over 3 years ago
- Status changed from In Progress to Fix Under Review
- Pull request ID set to 36730
It should be caused by my local code. I added more check code for using the client_lock directly.
Updated by Patrick Donnelly over 3 years ago
- Status changed from Fix Under Review to Resolved
- Target version set to v16.0.0
- Source set to Development