Hi all, I found a whole bunch of core files from imap this evening, so here are the stack traces from each. Unlike my last message, I don't have debugging symbols for these, so there isn't any analysis I can easily do. There were several cores with the first stack trace and one with the second trace. The core dump for the second trace is the only one I noticed. I suspect that the first trace happens when the client host goes to sleep. If so, the situation needs to be handled more gracefully. I'm currently building a copy of imap with debugging symbols. Dovecot Version: 1.1.beta3 with the notify patch from a few days ago OS: NetBSD/sparc64 4.0_RC3 (big endian, 64bit) File System: local UFS #0 0x0000000040550010 in abort () from /usr/lib/libc.so.12 #1 0x0000000000180770 in i_error () #2 0x00000000001805fc in i_panic () #3 0x00000000001192a4 in client_destroy () #4 0x00000000001196c8 in client_continue_pending_input () #5 0x0000000000114ecc in cmd_fetch () #6 0x000000000011515c in cmd_fetch () #7 0x0000000000118828 in client_command_cancel () #8 0x00000000001190c8 in client_destroy () #9 0x0000000000186d64 in io_loop_handler_run () #10 0x0000000000186198 in io_loop_run () #11 0x0000000000120fe8 in main () #0 0x0000000000129c3c in maildir_uidlist_iter_deinit () #1 0x000000000012a064 in maildir_uidlist_sync_get_full_filename () #2 0x000000000012c380 in maildir_uidlist_sync_deinit () #3 0x00000000001282ac in maildir_sync_notify () #4 0x0000000000128574 in maildir_storage_sync_init () #5 0x000000000016ec74 in mailbox_sync_init () #6 0x000000000016ed10 in mailbox_sync () #7 0x0000000000117484 in cmd_select_full () #8 0x0000000000117610 in cmd_select () #9 0x0000000000118c78 in client_send_command_error () #10 0x0000000000118d60 in client_send_command_error () #11 0x0000000000119430 in client_input () #12 0x0000000000186d64 in io_loop_handler_run () #13 0x0000000000186198 in io_loop_run () #14 0x0000000000120fe8 in main ()
On 2007-10-23 21:32:29 +1300, Lloyd Parkes wrote:> I found a whole bunch of core files from imap this evening, so here > are the stack traces from each. Unlike my last message, I don't have > debugging symbols for these, so there isn't any analysis I can easily > do. There were several cores with the first stack trace and one with > the second trace. The core dump for the second trace is the only one > I noticed. I suspect that the first trace happens when the client > host goes to sleep. If so, the situation needs to be handled more > gracefully. I'm currently building a copy of imap with debugging > symbols. > > Dovecot Version: 1.1.beta3 with the notify patch from a few days ago > OS: NetBSD/sparc64 4.0_RC3 (big endian, 64bit) > File System: local UFS > > #0 0x0000000040550010 in abort () from /usr/lib/libc.so.12 > #1 0x0000000000180770 in i_error () > #2 0x00000000001805fc in i_panic () > #3 0x00000000001192a4 in client_destroy () > #4 0x00000000001196c8 in client_continue_pending_input () > #5 0x0000000000114ecc in cmd_fetch () > #6 0x000000000011515c in cmd_fetch () > #7 0x0000000000118828 in client_command_cancel () > #8 0x00000000001190c8 in client_destroy () > #9 0x0000000000186d64 in io_loop_handler_run () > #10 0x0000000000186198 in io_loop_run () > #11 0x0000000000120fe8 in main () > > #0 0x0000000000129c3c in maildir_uidlist_iter_deinit () > #1 0x000000000012a064 in maildir_uidlist_sync_get_full_filename () > #2 0x000000000012c380 in maildir_uidlist_sync_deinit () > #3 0x00000000001282ac in maildir_sync_notify () > #4 0x0000000000128574 in maildir_storage_sync_init () > #5 0x000000000016ec74 in mailbox_sync_init () > #6 0x000000000016ed10 in mailbox_sync () > #7 0x0000000000117484 in cmd_select_full () > #8 0x0000000000117610 in cmd_select () > #9 0x0000000000118c78 in client_send_command_error () > #10 0x0000000000118d60 in client_send_command_error () > #11 0x0000000000119430 in client_input () > #12 0x0000000000186d64 in io_loop_handler_run () > #13 0x0000000000186198 in io_loop_run () > #14 0x0000000000120fe8 in main ()could you add -g to the CFLAGS and rebuild it? that would ease debugging as it would add the line numbers to the gdb output. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
On Tue, 2007-10-23 at 21:32 +1300, Lloyd Parkes wrote:> #3 0x00000000001192a4 in client_destroy () > #4 0x00000000001196c8 in client_continue_pending_input () > #5 0x0000000000114ecc in cmd_fetch () > #6 0x000000000011515c in cmd_fetch () > #7 0x0000000000118828 in client_command_cancel () > #8 0x00000000001190c8 in client_destroy () > #9 0x0000000000186d64 in io_loop_handler_run () > #10 0x0000000000186198 in io_loop_run () > #11 0x0000000000120fe8 in main ()I think this was fixed by beta4: http://hg.dovecot.org/dovecot/rev/86e964111b1f> #0 0x0000000000129c3c in maildir_uidlist_iter_deinit () > #1 0x000000000012a064 in maildir_uidlist_sync_get_full_filename () > #2 0x000000000012c380 in maildir_uidlist_sync_deinit () > #3 0x00000000001282ac in maildir_sync_notify () > #4 0x0000000000128574 in maildir_storage_sync_init () > #5 0x000000000016ec74 in mailbox_sync_init () > #6 0x000000000016ed10 in mailbox_sync () > #7 0x0000000000117484 in cmd_select_full () > #8 0x0000000000117610 in cmd_select () > #9 0x0000000000118c78 in client_send_command_error () > #10 0x0000000000118d60 in client_send_command_error () > #11 0x0000000000119430 in client_input () > #12 0x0000000000186d64 in io_loop_handler_run () > #13 0x0000000000186198 in io_loop_run () > #14 0x0000000000120fe8 in main ()This looks somewhat corrupted so I'm not sure what it could mean. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20071027/f5d2563f/attachment-0002.bin>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 28, 2007, at 5:12 AM, Timo Sirainen wrote:> On Tue, 2007-10-23 at 21:32 +1300, Lloyd Parkes wrote: >> #3 0x00000000001192a4 in client_destroy () >> #4 0x00000000001196c8 in client_continue_pending_input () >> #5 0x0000000000114ecc in cmd_fetch () >> #6 0x000000000011515c in cmd_fetch () >> #7 0x0000000000118828 in client_command_cancel () >> #8 0x00000000001190c8 in client_destroy () >> #9 0x0000000000186d64 in io_loop_handler_run () >> #10 0x0000000000186198 in io_loop_run () >> #11 0x0000000000120fe8 in main () > > I think this was fixed by beta4: > http://hg.dovecot.org/dovecot/rev/86e964111b1fSo do I. beta4 was released just before I reported the bug, so when I rebuilt Dovecot with the -g flag, I used beta4 instead of beta3 and I haven't had any problems since then. The Apple Mail client pushes the server very hard sometimes, and one of these dumps happened when I started Apple Mail on a computer that I hadn't used for a few weeks, so it did a lot of work to synchronise the local and server mail account. Cheers -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHJDg7fQuP2WY5lYkRAlF9AKChY0d8fqUvL7DmEBQHcZhSIYXCawCfcEYP e/LP8FNOH8vMHB4ylyq/SRo=47QN -----END PGP SIGNATURE-----