[Dovecot] Quota crashing w/ gdb backtrace
Hi,
I'm still running into consistent crashing when moving files between folders when dirsize quotas are enabled. This is running Dovecot1.0rc19.
Please let me know if I'm posting this to the wrong list.
Here is the gdb backtrace:
#0 0x377fc in mbox_file_seek (mbox=0xc8560, view=0xc94c0, seq=1, deleted_r=0xffbef157) at mbox-file.c:167 167 if (data == NULL) { (gdb) bt #0 0x377fc in mbox_file_seek (mbox=0xc8560, view=0xc94c0, seq=1, deleted_r=0xffbef157) at mbox-file.c:167 #1 0x39684 in mbox_mail_seek (mail=0xc73a8) at mbox-mail.c:69 #2 0x398f0 in mbox_mail_get_physical_size (_mail=0xc73a8) at mbox-mail.c:163 #3 0x6b880 in mail_get_physical_size (mail=0xc73a8) at mail.c:75 #4 0x7f933a74 in quota_default_try_alloc (ctx=0xc9a58, mail=0xc73a8, too_large_r=0xffbef397) at quota.c:434 #5 0x7f933654 in quota_try_alloc (ctx=0x0, mail=0xc73a8, too_large_r=0xffbef397) at quota.c:301 #6 0x7f9370c8 in quota_check (t=0xc57f0, mail=0xc73a8) at quota-storage.c:120 #7 0x7f9374d0 in quota_save_finish (ctx=0xc7790, dest_mail=0xc73a8) at quota-storage.c:222 #8 0x6cb64 in mailbox_save_finish (_ctx=0xffbef504, dest_mail=0xc73a8) at mail-storage.c:538 #9 0x6ba2c in mail_storage_copy (t=0xc57f0, mail=0xc5c00, flags=MAIL_SEEN, keywords=0x0, dest_mail=0xc73a8) at mail-copy.c:38 #10 0x7f9371e4 in quota_copy (t=0xc57f0, mail=0xc5c00, flags=MAIL_SEEN, keywords=0x0, dest_mail=0x0) at quota-storage.c:148 #11 0x6cbbc in mailbox_copy (t=0xc57f0, mail=0xc5c00, flags=MAIL_SEEN, keywords=0x0, dest_mail=0x0) at mail-storage.c:553 #12 0x1e6b0 in fetch_and_copy (t=0xc57f0, srcbox=0xc57f0, search_args=0x8) at cmd-copy.c:34 #13 0x1e804 in cmd_copy (cmd=0xba6c4) at cmd-copy.c:95 #14 0x21eec in cmd_uid (cmd=0xba6c4) at cmd-uid.c:19 #15 0x22ab8 in client_handle_input (cmd=0xba6c4) at client.c:331 #16 0x22a3c in client_handle_input (cmd=0xba6c4) at client.c:388 #17 0x22bb0 in _client_input (context=0xba680) at client.c:428 #18 0x80e88 in io_loop_handler_run (ioloop=0xb7de8) at ioloop-poll.c:199 #19 0x80794 in io_loop_run (ioloop=0xb7de8) at ioloop.c:281 #20 0x2b3d0 in main (argc=0, argv=0xffbefa7c, envp=0xffbefa8c) at main.c:280
The "data" variable defined as:
(gdb) print data $1 = (void *) 0xd9354
(gdb) print &data $3 = (void **) 0xffbef0dc
I've noticed that the copy (during a move) *does* complete correctly. However, the original files never gets deleted, so I assume that this crash is occuring during the deletion in the original folder.
-- Dean Brooks dean@iglou.com
On Wed, Jan 31, 2007 at 11:32:02AM -0500, Dean Brooks wrote:
I'm still running into consistent crashing when moving files between folders when dirsize quotas are enabled. This is running Dovecot1.0rc19.
Please let me know if I'm posting this to the wrong list.
Ok, turning off GCC '-O2' optimization made this crash go away. If I had to venture a guess, it must be related to the "const" definition of the "data" variable and its modification by reference. Who knows.
Still, this might be a concern for other people.
Regards,
Dean Brooks dean@iglou.com
On Wed, 2007-01-31 at 11:32 -0500, Dean Brooks wrote:
#0 0x377fc in mbox_file_seek (mbox=0xc8560, view=0xc94c0, seq=1, deleted_r=0xffbef157) at mbox-file.c:167 167 if (data == NULL) { .. (gdb) print data $1 = (void *) 0xd9354
Are you using some non-x86 CPU? It appears to crash because it's dereferencing data as 64bit integer, but the data isn't 64bit aligned in the memory. I thought I had already fixed all these problems..
Could you try http://dovecot.org/tools/idxview.c, run it against the mailbox's dovecot.index file and show me the headers that it outputs?
On Fri, Feb 02, 2007 at 01:27:01PM +0200, Timo Sirainen wrote:
On Wed, 2007-01-31 at 11:32 -0500, Dean Brooks wrote:
#0 0x377fc in mbox_file_seek (mbox=0xc8560, view=0xc94c0, seq=1, deleted_r=0xffbef157) at mbox-file.c:167 167 if (data == NULL) { .. (gdb) print data $1 = (void *) 0xd9354
Are you using some non-x86 CPU? It appears to crash because it's dereferencing data as 64bit integer, but the data isn't 64bit aligned in the memory. I thought I had already fixed all these problems..
Actually, I meant to post to the list about this. We are indeed running on 64-bit Sparc hardware (Solaris 8) with Dovecot1.0RC19.
Disabling -O2 optimization on gcc fixed the problem completely.
For what its worth though, here is the output of the idxview dump:
-- INDEX: /mail/indexes/dean/.imap/INBOX/dovecot.index version = 7.0 base header size = 120 header size = 200 record size = 40 compat flags = 0 index id = 1170310633 flags = 0 uid validity = 1169150002 next uid = 204 messages count = 6 recent messages count = 0 seen messages count = 6 deleted messages count = 0 first recent uid lowwater = 202 first unseen uid lowwater = 197 first deleted uid lowwater = 202 log file seq = 1 log file int offset = 1296 log file ext offset = 1296 sync size = 87754 sync stamp = 1170351425 day stamp = 1170306000 day first uid[0] = 169 day first uid[1] = 0 day first uid[2] = 0 day first uid[3] = 0 day first uid[4] = 0 day first uid[5] = 0 day first uid[6] = 0 day first uid[7] = 0 -- Extension 0 -- name: mbox hdr_size: 0 reset_id: 0 record_offset: 8 record_size: 8 record_align: 8 name_size: 4 -- Extension 1 -- name: cache hdr_size: 0 reset_id: 1170310633 record_offset: 16 record_size: 4 record_align: 4 name_size: 5 -- Extension 2 -- name: header-md5 hdr_size: 0 reset_id: 0 record_offset: 20 record_size: 16 record_align: 1 name_size: 10
RECORD: offset=240, seq=1, uid=169, flags=9
- ext mbox(0): 0 (0000000000000000)
- ext cache(1): 604 (0000025c)
- ext header-md5(2): (00000000000000000000000000000000) RECORD: offset=280, seq=2, uid=170, flags=8
- ext mbox(0): 4269 (00000000000010ad)
- ext cache(1): 828 (0000033c)
- ext header-md5(2): (f646c3246ddcf824f389b9b82f44014d) RECORD: offset=320, seq=3, uid=189, flags=9
- ext mbox(0): 23513 (0000000000005bd9)
- ext cache(1): 1080 (00000438)
- ext header-md5(2): (0cdd7281ad0cd1dd743f9546f26dbdf7) RECORD: offset=360, seq=4, uid=196, flags=8
- ext mbox(0): 72397 (0000000000011acd)
- ext cache(1): 1400 (00000578)
- ext header-md5(2): (c6a7ad234c5e09ba4e2cdcd25910280d) RECORD: offset=400, seq=5, uid=202, flags=8
- ext mbox(0): 75089 (0000000000012551)
- ext cache(1): 2552 (000009f8)
- ext header-md5(2): (f0d67eedac892b6a94d34b1aaaac2438) RECORD: offset=440, seq=6, uid=203, flags=8
- ext mbox(0): 75933 (000000000001289d)
- ext cache(1): 2768 (00000ad0)
- ext header-md5(2): (acd1a113f8432fbeff30499b0372dee5)
-- Dean Brooks dean@iglou.com
On Fri, 2007-02-02 at 11:01 -0500, Dean Brooks wrote:
#0 0x377fc in mbox_file_seek (mbox=0xc8560, view=0xc94c0, seq=1, deleted_r=0xffbef157) at mbox-file.c:167 167 if (data == NULL) { .. header size = 200 .. -- Extension 0 -- name: mbox hdr_size: 0 reset_id: 0 record_offset: 8 record_size: 8 record_align: 8 name_size: 4
Did the crash happen also with this index file? Because this looks correct, the mbox extension record seems to be 64bit aligned in the index file.
One possibility is that it's correct in index file, but broken in in-memory mappings. You could check that with:
gdb imap core p *view.map p ((struct mail_index_ext *)view.map.extensions.buffer.data)[0]
participants (2)
-
Dean Brooks
-
Timo Sirainen