On 6.10.2004, at 00:56, dovecot@spam.turbolink.net wrote:
#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
fr 9 p client->cmd
It looks like some command isn't being deinitialized properly. I found one possible reason, but I don't think it should happen at least often..
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.
I think mbox code in CVS works again. Please try and see if it fixes even the first problem.
#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;
(gdb) p cache $5 = (struct mail_cache *) 0x6e6ca9a0 (gdb) p cache->fields Cannot access memory at address 0x6e6ca9dc
Either corrupted backtrace or Dovecot somehow corrupted the stack while running. I added several asserts in CVS to catch all possible mistakes here.