[Dovecot] dovecot-auth core dumps
Seeing a few core dumps on my two proxy servers with dovecot-auth since upgrading to 1.0.2.
Example: Jul 30 13:36:51 alora kernel: pid 20234 (dovecot-auth), uid 0: exited on signal 11 (core dumped) Jul 30 13:36:51 alora dovecot: child 20234 (auth) killed with signal 11
Jul 29 19:17:08 marbella kernel: pid 70627 (dovecot-auth), uid 0: exited on signal 11 (core dumped) Jul 29 19:17:08 marbella dovecot: child 70627 (auth) killed with signal 11
Running: FreeBSD 6.1 i386 Dovecot 1.0.2
I'm not proficient in running 'gdb', so I followed the instructions from the wiki for a full backtrace. Output is below. Is there anything else I should be looking for, or any other commands I should send to gdb?
Thanks,
Cassidy
gdb /usr/local/libexec/dovecot/dovecot-auth /var/run/dovecot/dovecot- auth.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `dovecot-auth'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libpam.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libpam.so.3 Reading symbols from /usr/lib/libgssapi.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgssapi.so.8 Reading symbols from /usr/lib/libkrb5.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libkrb5.so.8 Reading symbols from /usr/lib/libasn1.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libasn1.so.8 Reading symbols from /usr/lib/libroken.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libroken.so.8 Reading symbols from /usr/lib/libcom_err.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libcom_err.so.3 Reading symbols from /usr/local/lib/mysql/libmysqlclient.so.15...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/mysql/libmysqlclient.so.15 Reading symbols from /lib/libcrypt.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.3 Reading symbols from /usr/lib/libssl.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libssl.so.4 Reading symbols from /lib/libcrypto.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypto.so.4 Reading symbols from /lib/libz.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.3 Reading symbols from /lib/libm.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.4 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 (gdb) bt full #0 0x180abc22 in gss_delete_sec_context () from /usr/lib/libgssapi.so.8 No symbol table info available. #1 0x08059246 in mech_deinit () No symbol table info available. #2 0x08053f12 in auth_request_handler_unref () No symbol table info available. #3 0x08050bef in auth_client_connection_destroy () No symbol table info available. #4 0x08050ead in auth_client_connection_create () No symbol table info available. #5 0x08065f54 in io_loop_handler_run () No symbol table info available. #6 0x08065605 in io_loop_run () No symbol table info available. #7 0x0805722a in main () No symbol table info available.
On Mon, 2007-07-30 at 14:06 -0600, Cassidy B. Larson wrote:
gdb /usr/local/libexec/dovecot/dovecot-auth /var/run/dovecot/dovecot- auth.core
This looks correct.
(gdb) bt full #0 0x180abc22 in gss_delete_sec_context () from /usr/lib/libgssapi.so.8 No symbol table info available. #1 0x08059246 in mech_deinit () No symbol table info available. #2 0x08053f12 in auth_request_handler_unref () No symbol table info available. #3 0x08050bef in auth_client_connection_destroy () No symbol table info available. #4 0x08050ead in auth_client_connection_create () No symbol table info available. #5 0x08065f54 in io_loop_handler_run () No symbol table info available. #6 0x08065605 in io_loop_run () No symbol table info available. #7 0x0805722a in main () No symbol table info available.
But this looks broken unfortunately. Usually it happens if the core file wasn't created by the exact same binary you gave to gdb.
One way to be sure would be to attach gdb to dovecot-auth while it's still running:
gdb /usr/local/libexec/dovecot/dovecot-auth <pid of dovecot-auth> continue <wait for crash> bt full
Also your dovecot-auth doesn't contain debugging information. It would be helpful to have that (make install probably strips them), but maybe not required if I just can get a nonbroken backtrace.
It appears the issue is when someone uses gssapi to authenticate. Hope this is what you want:
[root@carcel ~]# gdb /usr/local/libexec/dovecot/dovecot-auth 5863 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Attaching to program: /usr/local/libexec/dovecot/dovecot-auth, process 5863 Reading symbols from /usr/lib/libpam.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libpam.so.3 Reading symbols from /usr/lib/libgssapi.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgssapi.so.8 Reading symbols from /usr/lib/libkrb5.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libkrb5.so.8 Reading symbols from /usr/lib/libasn1.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libasn1.so.8 Reading symbols from /lib/libcrypto.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypto.so.4 Reading symbols from /usr/lib/libroken.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libroken.so.8 Reading symbols from /usr/lib/libcom_err.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libcom_err.so.3 Reading symbols from /usr/local/lib/mysql/libmysqlclient.so.15...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/mysql/libmysqlclient.so.15 Reading symbols from /lib/libcrypt.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.3 Reading symbols from /lib/libz.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.3 Reading symbols from /lib/libm.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.4 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 0x000000001149031c in kevent () from /lib/libc.so.6 (gdb) continue Continuing.
Program received signal SIGSEGV, Segmentation fault. 0x00000000107712a8 in gss_delete_sec_context () from /usr/lib/libgssapi.so.8
On 8/1/07, Timo Sirainen tss@iki.fi wrote:
On Mon, 2007-07-30 at 14:06 -0600, Cassidy B. Larson wrote:
gdb /usr/local/libexec/dovecot/dovecot-auth /var/run/dovecot/dovecot- auth.core
This looks correct.
(gdb) bt full #0 0x180abc22 in gss_delete_sec_context () from /usr/lib/libgssapi.so.8 No symbol table info available. #1 0x08059246 in mech_deinit () No symbol table info available. #2 0x08053f12 in auth_request_handler_unref () No symbol table info available. #3 0x08050bef in auth_client_connection_destroy () No symbol table info available. #4 0x08050ead in auth_client_connection_create () No symbol table info available. #5 0x08065f54 in io_loop_handler_run () No symbol table info available. #6 0x08065605 in io_loop_run () No symbol table info available. #7 0x0805722a in main () No symbol table info available.
But this looks broken unfortunately. Usually it happens if the core file wasn't created by the exact same binary you gave to gdb.
One way to be sure would be to attach gdb to dovecot-auth while it's still running:
gdb /usr/local/libexec/dovecot/dovecot-auth <pid of dovecot-auth> continue <wait for crash> bt full
Also your dovecot-auth doesn't contain debugging information. It would be helpful to have that (make install probably strips them), but maybe not required if I just can get a nonbroken backtrace.
On Wed, 2007-08-01 at 13:01 -0600, Cassidy B. Larson wrote:
It appears the issue is when someone uses gssapi to authenticate. Hope this is what you want: .. Program received signal SIGSEGV, Segmentation fault. 0x00000000107712a8 in gss_delete_sec_context () from /usr/lib/libgssapi.so.8
I would have still wanted "bt full", but .. So you really have allowed GSSAPI authentication for your proxy? Does it work normally? If not, how about just disabling it? :) I've no idea if it's supposed to even work..
Sorry about the no 'bt full'.
Program received signal SIGSEGV, Segmentation fault. 0x00000000107712a8 in gss_delete_sec_context () from /usr/lib/libgssapi.so.8 (gdb) bt full #0 0x00000000107712a8 in gss_delete_sec_context () from /usr/lib/libgssapi.so.8 No symbol table info available. #1 0x00000000004140cb in mech_deinit () No symbol table info available. #2 0x000000000040f38f in auth_request_handler_flush_failures () No symbol table info available. #3 0x0000000000421df9 in io_loop_handle_timeouts () No symbol table info available. #4 0x000000000042287a in io_loop_handler_run () No symbol table info available. #5 0x0000000000421eca in io_loop_run () No symbol table info available. #6 0x0000000000411dfb in main () No symbol table info available.
I use the 'masteruser' config on my proxies to let me accept secure passwords before I proxy off the connection to the storage servers. I suppose I could disable gssapi on the proxies, but figured I'd send this your way just in case there was a looming issue. I believe gssapi did work in the past, but can't quite remember.
-c
On 8/1/07, Timo Sirainen tss@iki.fi wrote:
On Wed, 2007-08-01 at 13:01 -0600, Cassidy B. Larson wrote:
It appears the issue is when someone uses gssapi to authenticate. Hope this is what you want: .. Program received signal SIGSEGV, Segmentation fault. 0x00000000107712a8 in gss_delete_sec_context () from /usr/lib/libgssapi.so.8
I would have still wanted "bt full", but .. So you really have allowed GSSAPI authentication for your proxy? Does it work normally? If not, how about just disabling it? :) I've no idea if it's supposed to even work..
On Wed, 2007-08-01 at 13:09 -0600, Cassidy B. Larson wrote:
Sorry about the no 'bt full'.
Program received signal SIGSEGV, Segmentation fault. 0x00000000107712a8 in gss_delete_sec_context () from /usr/lib/libgssapi.so.8
I guess this fixes it: http://hg.dovecot.org/dovecot-1.0/rev/d2da308f55d3
participants (2)
-
Cassidy B. Larson
-
Timo Sirainen