[Dovecot] Out of memory [repost as a new thread]
Timo Sirainen
tss at iki.fi
Wed Jan 23 17:45:28 EET 2008
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20080123/d8ba0b70/attachment.bin
More information about the dovecot
mailing list