Core dumps when opening an IMAP folder (Was: Re: [Dovecot] 1.0-test70)

[Tero Ripattila]

Hei Timo,

Saturday, May 14, 2005, 8:49:02 PM, you [TS] wrote:

TS> mmap_disable=yes seems to be finally working pretty well. There should
TS> be no more cache file related errors with it enabled.

Dovecot started to do core dumps when I try to open some particular IMAP
folders, please see the following:

$ ls -l imap.core
-rw-------  1 5303  wheel  20448104 May 22 18:56 imap.core

$ gdb /usr/local/libexec/dovecot/imap /tmp/imap.core
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd3.6"...
Core was generated by `imap'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libc.so.34.2...done.
Loaded symbols for /usr/lib/libc.so.34.2
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so
#0  0x1c0518e9 in pool_alloconly_clear (pool=0x3c02fe10)
    at mempool-alloconly.c:281
281                     free(block);
(gdb) bt full
#0  0x1c0518e9 in pool_alloconly_clear (pool=0x3c02fe10)
    at mempool-alloconly.c:281
        avail_size = 1006829072
#1  0x1c051678 in pool_alloconly_destroy (apool=0x3c02fe10)
    at mempool-alloconly.c:109
        block = (void *) 0x0
#2  0x1c02b794 in index_header_lookup_deinit (_ctx=0x0)
    at index-mail-headers.c:681
No locals.
#3  0x1c04106f in mailbox_header_lookup_deinit (ctx=0x0) at mail-storage.c:381
No locals.
#4  0x1c029ee4 in index_mail_get_special (_mail=0x3c02fa40, field=0)
    at index-mail.c:617
        data = (struct index_mail_data *) 0x3c02faa4
        cache_fields = (struct mail_cache_field *) 0x3c01f500
        str = (string_t *) 0x5f
        ext_data = (const void *) 0x5f
#5  0x1c01c526 in maildir_mail_get_special (_mail=0x9, field=0)
    at maildir-mail.c:167
        mbox = (struct maildir_mailbox *) 0x1
        flags = 1006828096
        fname = 0x3c023088 ""
#6  0x1c040534 in mail_get_special (mail=0x0, field=MAIL_FETCH_IMAP_ENVELOPE)
    at mail.c:113
No locals.
#7  0x1c01199c in fetch_envelope (ctx=0x3c023088, mail=0x3c02fa40, context=0x0)
    at imap-fetch.c:411
        envelope = 0x3c023088 ""
#8  0x1c011572 in imap_fetch (ctx=0x3c023088) at imap-fetch.c:264
        handlers = (const struct imap_fetch_context_handler *) 0x3c0231a8
        size = 6
        ret = 1
#9  0x1c00d708 in cmd_fetch (cmd=0x3c020040) at cmd-fetch.c:165
        client = (struct client *) 0x3c020000
        ctx = (struct imap_fetch_context *) 0x3c023088
        args = (struct imap_arg *) 0x3c021048
        search_arg = (struct mail_search_arg *) 0x3c023050
        messageset = 0x9 ""
        ret = 0
#10 0x1c00fa7d in cmd_uid (cmd=0x3c020040) at cmd-uid.c:19
        cmd_name = 0x3c0210f8 "FETCH"
#11 0x1c01023b in client_handle_input (cmd=0x3c020040) at client.c:334
        client = (struct client *) 0x3c020000
#12 0x1c010369 in _client_input (context=0x3c020000) at client.c:383
        client = (struct client *) 0x3c020000
        cmd = (struct client_command_context *) 0x3c020040
#13 0x1c050a68 in io_loop_handler_run (ioloop=0x3c01d000) at ioloop-poll.c:184
        data = (struct ioloop_handler_data *) 0x3c0110a0
        pollfd = (struct pollfd *) 0x3c01e000
        tv = {tv_sec = 0, tv_usec = 572544}
        io = (struct io *) 0x3c0353c0
        t_id = 2
        msecs = 0
        ret = 0
        call = 1
#14 0x1c050505 in io_loop_run (ioloop=0x3c01d000) at ioloop.c:218
No locals.
#15 0x1c016d37 in main (argc=3, argv=0xcfbefd3c, envp=0xcfbefd4c) at main.c:228
No locals.
(gdb)

I'm currently trying to find out what's so special with these folders
that cannot be opened normally, but havent find anything in common
between them. They all contain something like 20-40k messages.

I have to seriously consider reverting back to -test69 now :-(

Thanks, Tero

-- 
Tero Ripattila