[Dovecot] assertion failed and debugging dovecot
I'm getting this error on a particular message in my Maildir:
Oct 11 21:59:48 aurora dovecot: IMAP(doug): file ostream-file.c: line 646 (_send_istream): assertion failed: (instream->v_offset <= in_size)
To me, more import than the question "why is this happening" is "how can I debug this?" Attaching gdb to the running imap process doesn't give me access to the proper function names to set up breakpoints and get a stack trace.
Can someone with the experience give a quick how-to on debugging functions deep in dovecot?
Thanks,
Doug
On 12.10.2004, at 08:17, Doug Luce wrote:
I'm getting this error on a particular message in my Maildir:
Oct 11 21:59:48 aurora dovecot: IMAP(doug): file ostream-file.c: line 646 (_send_istream): assertion failed: (instream->v_offset <= in_size)
I heard about the same problem today from someone else. Apparently this can be reproduced every time with some mail. Still waiting for that mail :)
To me, more import than the question "why is this happening" is "how can I debug this?" Attaching gdb to the running imap process doesn't give me access to the proper function names to set up breakpoints and get a stack trace.
Can someone with the experience give a quick how-to on debugging functions deep in dovecot?
You should be able to attach gdb normally into it, as long as the binary isn't stripped, ie.:
gdb /usr/local/libexec/dovecot/imap pid
It's not stripped, but I think I need additional clues. Why does the "where" fail to tell me where I am?
Thanks,
Doug
My session:
aurora# ps ax | grep imap 83842 ?? S 0:00.06 imap-login 83849 ?? S 0:00.24 imap aurora# gdb /usr/local/dovecot-nightly/libexec/dovecot/imap 83849 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 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 "alpha-unknown-freebsd"... Attaching to program: /usr/local/dovecot-nightly/libexec/dovecot/imap, process 83849 0x130234c60 in ?? () (gdb) where #0 0x130234c60 in ?? () #1 0x12006e3a8 in _read (stream=0x1200aa080) at istream-mmap.c:91 #2 0x12006e3a8 in _read (stream=0x0) at istream-mmap.c:91 Error accessing memory address 0x40: Bad address. (gdb) cont Continuing. [[ Then it bombs with the log message I posted earlier ]]
Program received signal SIGABRT, Aborted. warning: Hit heuristic-fence-post without finding warning: enclosing function for address 0x130235908 This warning occurs if you are debugging a function without any symbols (for example, in a stripped executable). In that case, you may wish to increase the size of the search with the `set heuristic-fence-post' command.
Otherwise, you told GDB there was a function where there isn't one, or (more likely) you have encountered a bug in GDB. 0x130235908 in ?? () (gdb) where #0 0x130235908 in ?? () warning: Hit heuristic-fence-post without finding warning: enclosing function for address 0x130226e18 (gdb) c Continuing.
Program terminated with signal SIGABRT, Aborted. The program no longer exists. (gdb)
On Wed, 13 Oct 2004, Timo Sirainen wrote:
On 12.10.2004, at 08:17, Doug Luce wrote:
I'm getting this error on a particular message in my Maildir:
Oct 11 21:59:48 aurora dovecot: IMAP(doug): file ostream-file.c: line 646 (_send_istream): assertion failed: (instream->v_offset <= in_size)
I heard about the same problem today from someone else. Apparently this can be reproduced every time with some mail. Still waiting for that mail :)
To me, more import than the question "why is this happening" is "how can I debug this?" Attaching gdb to the running imap process doesn't give me access to the proper function names to set up breakpoints and get a stack trace.
Can someone with the experience give a quick how-to on debugging functions deep in dovecot?
You should be able to attach gdb normally into it, as long as the binary isn't stripped, ie.:
gdb /usr/local/libexec/dovecot/imap pid
On 13.10.2004, at 23:50, Doug Luce wrote:
It's not stripped, but I think I need additional clues. Why does the "where" fail to tell me where I am?
aurora# gdb /usr/local/dovecot-nightly/libexec/dovecot/imap 83849 .. 0x130234c60 in ?? () (gdb) where #0 0x130234c60 in ?? () #1 0x12006e3a8 in _read (stream=0x1200aa080) at istream-mmap.c:91 #2 0x12006e3a8 in _read (stream=0x0) at istream-mmap.c:91 Error accessing memory address 0x40: Bad address.
That's entirely corrupted.. It should usually be waiting in poll(). Only time I've seen that is when debugged binary doesn't match the process that is running. But I guess that's not the case, so I have no idea. I don't think Dovecot is doing anything special to break debugging.
participants (2)
-
Doug Luce
-
Timo Sirainen