[Dovecot] UIDL bug

[dovecot at spam.turbolink.net]

On Tue, 5 Oct 2004, Timo Sirainen wrote:

> On 5.10.2004, at 23:20, dovecot at 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