Bug #4530: client: Assert failure on session close - CephFS - Ceph

Actions

Copy link

Bug #4530

closed

client: Assert failure on session close

Added by Sam Lang about 11 years ago. Updated almost 8 years ago.

Status:

Resolved

Priority:

Normal

Assignee:

Sam Lang

Category:

Target version:

% Done:

Source:

Development

Tags:

Backport:

Regression:

Severity:

3 - minor

Reviewed:

Affected Versions:

ceph-qa-suite:

Component(FS):

Client

Labels (FS):

Pull request ID:

Crash signature (v1):

Crash signature (v2):

Description

During testing of #4451:

../../src/common/Cond.h: In function 'int Cond::Signal()' thread 7fe04c36f700 time 2013-03-22 11:06:00.897442
../../src/common/Cond.h: 89: FAILED assert(waiter_mutex == _null || waiter_mutex->is_locked())
ceph version 0.56-601-ge863840 (e863840be2a005f7467db6ac22aed8965d08d699)
1: (ceph::_ceph_assert_fail(char const*, char const*, int, char const*)+0x9b) [0x7fe05056cf61]
2: (Cond::Signal()+0x55) [0x7fe0503776bb]
3: (Client::kick_requests(int, bool)+0x1e2) [0x7fe0503396ec]
4: (Client::_closed_mds_session(int, MetaSession*)+0x5c) [0x7fe050334568]
5: (Client::handle_client_session(MClientSession*)+0x41a) [0x7fe0503349bc]
6: (Client::ms_dispatch(Message*)+0x2d9) [0x7fe050337571]
7: (Messenger::ms_deliver_dispatch(Message*)+0xa1) [0x7fe05044a56f]
8: (DispatchQueue::entry()+0x54f) [0x7fe050449ae7]
9: (DispatchQueue::DispatchThread::entry()+0x22) [0x7fe050552362]
10: (Thread::_entry_func(void*)+0x29) [0x7fe050559159]
11: (()+0x7e9a) [0x7fe052a8de9a]
12: (clone()+0x6d) [0x7fe051ea0cbd]
NOTE: a copy of the executable, or `objdump -rdS <executable>` is needed to interpret this.
terminate called after throwing an instance of 'ceph::FailedAssertion'

Actions

Copy link

Updated by Ian Colle about 11 years ago

Status changed from New to In Progress

Actions

Copy link

Updated by Sam Lang about 11 years ago

Status changed from In Progress to Fix Under Review

I pushed some fixes to wip-4530 for the client side part of this. Needs review.

Actions

Copy link

Updated by Sam Lang about 11 years ago

I went to file another bug for the client reconnect triggering a session close, but the log indicates that its not actually a client reconnect that triggers the session close. The client is requesting a session close before the mds restarts, so its while handling the sessions after mds restart that the client gets the session close because it was already in a closing state.

This behavior looks correct, so the only known issue is the assert reported above, which the commits to wip-4530 propose to fix. I'll update the main commit message with the correct steps that lead to it.

Actions

Copy link