On Tue, 5 Oct 2004, Timo Sirainen wrote:
On 5.10.2004, at 23:20, dovecot@spam.turbolink.net wrote:
file mbox-lock.c: line 493 (mbox_lock): assertion failed: (lock_type == F_RDLCK ||ibox->mbox_lock_type != F_RDLCK)
Could you get backtrace of this? I can't really figure out when this could happen.
Yep I can, I thought I posted one already but I might have forgotten to paste it in:
(gdb) bt #0 0x4004bc31 in kill () from /lib/libc.so.6 #1 0x4004b8b8 in raise () from /lib/libc.so.6 #2 0x4004d17c in abort () from /lib/libc.so.6 #3 0x0807f184 in i_internal_panic_handler (fmt=0x8088e40 "file %s: line %d (%s): assertion failed: (%s)", args=0xbffff9a4 "\231\b\b\001") at failures.c:374 #4 0x0807ed5f in i_panic (format=0x8088e40 "file %s: line %d (%s): assertion failed: (%s)") at failures.c:173 #5 0x0805c653 in mbox_lock (ibox=0x40151300, lock_type=1, lock_id_r=0xbffffa0c) at mbox-lock.c:500 #6 0x080604bf in mbox_sync (ibox=0x809d108, flags=MBOX_SYNC_REWRITE) at mbox-sync.c:1249 #7 0x0805ac2d in mbox_storage_close (box=0x809d108) at mbox-storage.c:805 #8 0x08074fcd in mailbox_close (box=0x0) at mail-storage.c:296 #9 0x080528f1 in client_destroy (client=0x809cc88) at client.c:190 #10 0x080854fb in stream_send_io (context=0x809cd38) at ostream-file.c:343 #11 0x08082dc0 in io_loop_handler_run (ioloop=0x809b0e0) at ioloop-poll.c:184 #12 0x08082505 in io_loop_run (ioloop=0x809b0e0) at ioloop.c:218 #13 0x08053fba in main (argc=2, argv=0xbffffc14, envp=0xbffffc20) at main.c:189 #14 0x40037bb4 in __libc_start_main () from /lib/libc.so.6
And lots more of this one with IMAP users only:
file mbox-sync-rewrite.c: line 460 (mbox_sync_rewrite): assertion failed: (mails[idx].space > 0)
Yep, this happened with me too. CVS has much more understandable (and better working and slightly faster) mbox rewriting code. But it has some other new syncing problems that I haven't yet fixed.
ok. I'm starting to understand more of the dovecot source so I'll check it out.
#0 0x0807d63f in mail_cache_merge_bitmask (cache=0x6e6ca9a0, buffer=0x80b6b58, field=0, data=0x4027ebf8, data_size=4) at mail-cache-compress.c:29 29 buf_data_size = cache->fields[buf_field].field.field_size;
What about:
p cache->fields p cache->fields_count p buf_field p pos p buf_size
(gdb) p cache $5 = (struct mail_cache *) 0x6e6ca9a0 (gdb) p cache->fields Cannot access memory at address 0x6e6ca9dc (gdb) p cache->fields_count Cannot access memory at address 0x6e6ca9e4 (gdb) p buf_field $1 = 1936942413 (gdb) p pos $2 = 32 (gdb) p buf_size $3 = 372
Not sure why gdb can't access the other 2 variables, wasn't included in the core file for some reason??
- Mike