Re: [BUG] 2.2.21 Panic: file imap-client.c: line 841 (client_check_command_hangs): assertion failed: (!have_wait_unfinished || unfinished_count > 0)
On 04 Jan 2016, at 09:58, Florian Pritz bluewind@xinu.at wrote:
On 04.01.2016 15:49, Timo Sirainen wrote:
What about:
#5 0x000000000041dde6 in client_check_command_hangs (client=0x2363450) at imap-client.c:841 cmd = 0x0 unfinished_count = 0 have_wait_unfinished = true __FUNCTION__ = "client_check_command_hangs"
Either the new code that's detecting hanging-bugs is somehow broken or it's actually preventing a hang by crashing instead, in which case the bug is elsewhere..
Output below.
Sending a private mail because I don't know what that session ID in the output can be used for.
The session ID is harmless. Anyway, I'm having trouble figuring out how the crash could happen or how to reproduce it. According to the backtrace it seems like the client is running IDLE and then it sends "DONE\r\nNOOP\r\n" in same IP packet. But when doing that, I don't see a crash. Although during testing I did find several other bugs. Could you try patching and seeing if you still get the same crash after them? Or have you seen the crash after the initial few times?
https://github.com/dovecot/core/commit/1ddf959a750f3860feff4ab3f0e908f327409... https://github.com/dovecot/core/commit/c8e9fa2ffa2566e75f0500808b1bc9bf5d9db... https://github.com/dovecot/core/commit/15307c2c91854e766bd9fb095d611a29b3f75... https://github.com/dovecot/core/commit/c7801f830c7d2e7d340065cdd5a5c795b1726...
On 04 Jan 2016, at 12:54, Timo Sirainen tss@iki.fi wrote:
On 04 Jan 2016, at 09:58, Florian Pritz bluewind@xinu.at wrote:
On 04.01.2016 15:49, Timo Sirainen wrote:
What about:
#5 0x000000000041dde6 in client_check_command_hangs (client=0x2363450) at imap-client.c:841 cmd = 0x0 unfinished_count = 0 have_wait_unfinished = true __FUNCTION__ = "client_check_command_hangs"
Either the new code that's detecting hanging-bugs is somehow broken or it's actually preventing a hang by crashing instead, in which case the bug is elsewhere..
Output below.
Sending a private mail because I don't know what that session ID in the output can be used for.
The session ID is harmless. Anyway, I'm having trouble figuring out how the crash could happen or how to reproduce it. According to the backtrace it seems like the client is running IDLE and then it sends "DONE\r\nNOOP\r\n" in same IP packet. But when doing that, I don't see a crash. Although during testing I did find several other bugs. Could you try patching and seeing if you still get the same crash after them? Or have you seen the crash after the initial few times?
https://github.com/dovecot/core/commit/1ddf959a750f3860feff4ab3f0e908f327409... https://github.com/dovecot/core/commit/c8e9fa2ffa2566e75f0500808b1bc9bf5d9db... https://github.com/dovecot/core/commit/15307c2c91854e766bd9fb095d611a29b3f75... https://github.com/dovecot/core/commit/c7801f830c7d2e7d340065cdd5a5c795b1726...
Actually, maybe this is enough:
https://github.com/dovecot/core/commit/f136b0050b3125b466af73984177250b7ed1a...
I still wasn't able to reproduce it though.
On 2016-01-04 19:21, Timo Sirainen wrote:
On 04 Jan 2016, at 12:54, Timo Sirainen tss@iki.fi wrote:
On 04 Jan 2016, at 09:58, Florian Pritz bluewind@xinu.at wrote:
On 04.01.2016 15:49, Timo Sirainen wrote:
What about:
#5 0x000000000041dde6 in client_check_command_hangs (client=0x2363450) at imap-client.c:841 cmd = 0x0 unfinished_count = 0 have_wait_unfinished = true __FUNCTION__ = "client_check_command_hangs"
Either the new code that's detecting hanging-bugs is somehow broken or it's actually preventing a hang by crashing instead, in which case the bug is elsewhere..
Output below.
Sending a private mail because I don't know what that session ID in the output can be used for.
The session ID is harmless. Anyway, I'm having trouble figuring out how the crash could happen or how to reproduce it. According to the backtrace it seems like the client is running IDLE and then it sends "DONE\r\nNOOP\r\n" in same IP packet. But when doing that, I don't see a crash. Although during testing I did find several other bugs. Could you try patching and seeing if you still get the same crash after them? Or have you seen the crash after the initial few times?
https://github.com/dovecot/core/commit/1ddf959a750f3860feff4ab3f0e908f327409... https://github.com/dovecot/core/commit/c8e9fa2ffa2566e75f0500808b1bc9bf5d9db... https://github.com/dovecot/core/commit/15307c2c91854e766bd9fb095d611a29b3f75... https://github.com/dovecot/core/commit/c7801f830c7d2e7d340065cdd5a5c795b1726...
Actually, maybe this is enough:
https://github.com/dovecot/core/commit/f136b0050b3125b466af73984177250b7ed1a...
I still wasn't able to reproduce it though.
Seeing this too, FYI:
Jan 18 12:11:31 imap(info@XXXXX.dk): Panic: file imap-client.c: line 841 (client_check_command_hangs): assertion failed: (!have_wait_unfinished || unfinished_count > 0) Jan 18 12:11:32 imap(info@XXXXX.dk): Error: Raw backtrace: /usr/lib/dovecot/libdovecot.so.0 [0x3e2d67e07a] -> /usr/lib/dovecot/libdovecot.so.0 [0x3e2d67e0e6] -> /usr/lib/dovecot/libdovecot.so.0 [0x3e2d67d4ac] -> dovecot/imap [info@XXXXX.dk X.X.X.X NOOP] [0x4177a6] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x49) [0x3e2d690579] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0xdc) [0x3e2d691c3c] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0xa9) [0x3e2d6906b9] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x38) [0x3e2d6909e8] -> /usr/lib/dovecot/libdovecot.so.0(master_service_run+0x13) [0x3e2d62e533] -> dovecot/imap info@XXXXX.dk X.X.X.X NOOP [0x42406c] -> /lib64/libc.so.6(__libc_start_main+0xf4) [0x3a62c1d9f4] -> dovecot/imap [info@XXXXX.dk X.X.X.X NOOP] [0x40c029] Jan 18 12:11:32 imap(info@XXXXX.dk): Fatal: master: service(imap): child 27828 killed with signal 6 (core dumps disabled)
Can't apply patch, but will report back in 2.2.22
// Tom
On 04.01.2016 18:54, Timo Sirainen wrote:
Could you try patching and seeing if you still get the same crash after them? Or have you seen the crash after the initial few times?
Thanks for the patches, but sadly I don't know how this happened and only saw it happening twice today in my log (within 10 minutes IIRC). Didn't see it since and not before. Sorry that I can't verify the patches.
Glad you found other bugs though.
Florian
participants (3)
-
Florian Pritz
-
Timo Sirainen
-
Tom Sommer