[Dovecot] imap segfaults in dovecot 1.2 on logout
Hi Timo,
when logging out like
a001 logout
the imap child dies from signal 11. The back trace looks like this:
Program received signal SIGSEGV, Segmentation fault. 0xb7ed4991 in strcasecmp () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb7ed4991 in strcasecmp () from /lib/tls/i686/cmov/libc.so.6 #1 0x0806ab6c in command_unregister (name=0x815b9ab "LOGOUT") at commands.c:83 #2 0x0806ac56 in command_unregister_array (cmdarr=0x815ba8c, count=25) at commands.c:101 #3 0x0806ae36 in commands_deinit () at commands.c:146 #4 0x08073a8f in main_deinit () at main.c:273 #5 0x08073b7b in main (argc=1, argv=0xbfacb884, envp=0xbfacb88c) at main.c:310 (gdb) up #1 0x0806ab6c in command_unregister (name=0x815b9ab "LOGOUT") at commands.c:83 83 if (strcasecmp(cmd[i].name, name) == 0) { (gdb) p cmd[i] $1 = {name = 0xb7e65ce7
, func = 0xb7e6432d, flags = 0} ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^For some reasons this does _not_ happen when I simply close the connection (without explicitly logging out)...
cheers sascha
Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
On Oct 15, 2008, at 5:57 PM, Sascha Wilde wrote:
#1 0x0806ab6c in command_unregister (name=0x815b9ab "LOGOUT") at
, func =
commands.c:83 83 if (strcasecmp(cmd[i].name, name) == 0) { (gdb) p cmd[i] $1 = {name = 0xb7e65ce7
0xb7e6432d, flags = 0} ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^For some reasons this does _not_ happen when I simply close the connection (without explicitly logging out)...
Your plugin isn't probably unregistering some command it registered
and the plugin is unloaded before commands_deinit() is called.
valgrind might also show something.
Timo Sirainen tss@iki.fi writes:
On Oct 15, 2008, at 5:57 PM, Sascha Wilde wrote:
#1 0x0806ab6c in command_unregister (name=0x815b9ab "LOGOUT") at commands.c:83 83 if (strcasecmp(cmd[i].name, name) == 0) { (gdb) p cmd[i] $1 = {name = 0xb7e65ce7
, func = 0xb7e6432d, flags = 0} ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^For some reasons this does _not_ happen when I simply close the connection (without explicitly logging out)...
Your plugin isn't probably unregistering some command it registered and the plugin is unloaded before commands_deinit() is called.
As said in my other mail, that was indeed the problem and it is now solved. The question still left is: why didn't I see the segfoult in the logs when the connection was closed hard?
A quick look with gdb shows, that the deinit stuff is called in both cases, so I'd guess its an logging issue?
cheers sascha
Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
On Thu, 2008-10-16 at 13:49 +0200, Sascha Wilde wrote:
Timo Sirainen tss@iki.fi writes:
On Oct 15, 2008, at 5:57 PM, Sascha Wilde wrote:
#1 0x0806ab6c in command_unregister (name=0x815b9ab "LOGOUT") at commands.c:83 83 if (strcasecmp(cmd[i].name, name) == 0) { (gdb) p cmd[i] $1 = {name = 0xb7e65ce7
, func = 0xb7e6432d, flags = 0} ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^For some reasons this does _not_ happen when I simply close the connection (without explicitly logging out)...
Your plugin isn't probably unregistering some command it registered and the plugin is unloaded before commands_deinit() is called.
As said in my other mail, that was indeed the problem and it is now solved. The question still left is: why didn't I see the segfoult in the logs when the connection was closed hard?
A quick look with gdb shows, that the deinit stuff is called in both cases, so I'd guess its an logging issue?
I've no idea really. Perhaps it was just luck? :) If the process crashed, you would have gotten a "killed with signal 11" error to logs since it's detected and logged by the master process.
Timo Sirainen tss@iki.fi writes:
On Thu, 2008-10-16 at 13:49 +0200, Sascha Wilde wrote:
Timo Sirainen tss@iki.fi writes:
On Oct 15, 2008, at 5:57 PM, Sascha Wilde wrote:
#1 0x0806ab6c in command_unregister (name=0x815b9ab "LOGOUT") at commands.c:83 83 if (strcasecmp(cmd[i].name, name) == 0) { (gdb) p cmd[i] $1 = {name = 0xb7e65ce7
, func = 0xb7e6432d, flags = 0} ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^For some reasons this does _not_ happen when I simply close the connection (without explicitly logging out)...
Your plugin isn't probably unregistering some command it registered and the plugin is unloaded before commands_deinit() is called.
As said in my other mail, that was indeed the problem and it is now solved. The question still left is: why didn't I see the segfoult in the logs when the connection was closed hard?
A quick look with gdb shows, that the deinit stuff is called in both cases, so I'd guess its an logging issue?
I've no idea really. Perhaps it was just luck? :)
No, this was really reproducible, I did it a couple of times, it always looked like this: With IMAP "LOGOUT" command: <info> dovecot[22653]: IMAP(1@example.com): Disconnected: Logged out bytes=31/953 <error> dovecot[22653]: child 22687 (imap) killed with signal 11
Connection closed without LOGOUT: <info> dovecot[22653]: IMAP(1@example.com): Connection closed bytes=0/272 and no hint of signal 11...
cheers sascha
Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
Sascha Wilde wilde@intevation.de writes:
when logging out like
a001 logout
the imap child dies from signal 11. The back trace looks like this:
Program received signal SIGSEGV, Segmentation fault. 0xb7ed4991 in strcasecmp () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb7ed4991 in strcasecmp () from /lib/tls/i686/cmov/libc.so.6 #1 0x0806ab6c in command_unregister (name=0x815b9ab "LOGOUT") at commands.c:83
Could this be the same issue as the one in http://dovecot.org/list/dovecot/2008-October/034211.html ? If so, it appears to be a bug in the ACL plugin.
I recall having a similar problem with the Annotation plugin. IIRC it had something to do with not unregistering commands properly when the plugin was unloaded. In that case the array of known commands retains dangling pointers to the names of the commands that point to the unloaded shared object file.
Bernhard
-- Bernhard Herzog | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
On 15.10.2008, Bernhard Herzog wrote:
I recall having a similar problem with the Annotation plugin. IIRC it had something to do with not unregistering commands properly when the plugin was unloaded. In that case the array of known commands retains dangling pointers to the names of the commands that point to the unloaded shared object file.
I think this is indeed the case with the ACL plugin if it is patched to
implement the ACL IMAP commands, as is the case in the kolab branch. The
commands are only unregistered if acl_next_hook_mail_storage_created != NULL.
Now that variale is set in acl_plugin_init but there's no guarantee that it
will always be != NULL afterwards. If the ACL plugin is the first plugin to
change hook_mail_storage_created, acl_next_hook_mail_storage_created will be
NULL after acl_plugin_init has been executed and registered the commands, but
the deinit function will not unregister the commands.
Bernhard
-- Bernhard Herzog | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
Bernhard Herzog bh@intevation.de writes:
On 15.10.2008, Bernhard Herzog wrote:
I recall having a similar problem with the Annotation plugin. IIRC it had something to do with not unregistering commands properly when the plugin was unloaded. In that case the array of known commands retains dangling pointers to the names of the commands that point to the unloaded shared object file.
I think this is indeed the case with the ACL plugin if it is patched to implement the ACL IMAP commands, as is the case in the kolab branch. The commands are only unregistered if acl_next_hook_mail_storage_created != NULL.
Now that variale is set in acl_plugin_init but there's no guarantee that it will always be != NULL afterwards. If the ACL plugin is the first plugin to change hook_mail_storage_created, acl_next_hook_mail_storage_created will be NULL after acl_plugin_init has been executed and registered the commands, but the deinit function will not unregister the commands.
Yes, I came to the same conclusion. I checked in a fix to the acl-branch[0] as well as to the generic kolab-branch[1] repository.
cheers sascha
[0] http://hg.intevation.org/kolab/dovecot-1.2_acl-branch/ [1] http://hg.intevation.org/kolab/dovecot-1.2_kolab-branch/
Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
participants (3)
-
Bernhard Herzog
-
Sascha Wilde
-
Timo Sirainen