On Wed, 2008-01-23 at 15:29 +0100, Wolfram Schlich wrote:
I tried your patch and compiled dovecot with --enable-debug,
There's no need for --enable-debug. It's mainly useful for developers when developing new code.
/usr/libexec/dovecot/imap: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, not stripped
--8<-- uluru tmp # gdb /usr/libexec/dovecot/imap core.x\{imap\}.u\{30010\}.g\{30006\}.p\{20880\}.t\{1201094907\}
Looks ok..
(gdb) bt full #0 0x169917d5 in ?? () from /lib/ld-linux.so.2 No symbol table info available. #1 0x169bfba9 in ?? () No symbol table info available. #2 0xb146d6ff in ?? () No symbol table info available. #3 0x00000001 in ?? () No symbol table info available. #4 0x00000000 in ?? () No symbol table info available.
Unfortunately this is broken. Even those addresses are impossible (#4 shows that one call was from NULL pointer, #3 is 1). This just seems to happen sometimes for core dumps, possibly even repeatedly..
The one sure way to get a usable backtrace would be to attach gdb to a running imap process, but that would require you to be able to reproduce the bug at a specific time (so you can attach gdb, then make it crash)..
Or maybe if you have more core dumps, one of them shows something? The important thing is that if it only shows "??" it's broken. At the very least the last lines should contain something like:
#2 0x00000000004881cd in io_loop_run (ioloop=0x6c9d30) at ioloop.c:301 #3 0x0000000000424a62 in main (argc=<value optimized out>, argv=0x7fff1841b9b8, envp=0x7fff1841b9c8) at main.c:293