[Dovecot] Dovecot crashes on certain spam messages
Dovecot crashes. I think it's because of some message in my spam folder. It has happened once before, and that time I solved it by deleting that folder. It happens when I start gnus ("Checking messages in folder spam" or something like that), which makes gnus just stop, or when I try to enter that folder in mutt.
Jan 30 17:07:09 kalle imap(ke): file imap-bodystructure.c: line 278 (part_parse_headers): assertion failed: (part->physical_pos >= input->v_offset - start_offset)
Is there something I can do to determine which message it crashed on?
Maildir format, version 0.99.10.4.
--On Friday, January 30, 2004 5:22 PM +0100 Karl Eklund kalle-e@medelklassen.com wrote:
Is there something I can do to determine which message it crashed on?
My approach would be to add a line of code to log the message file name and rebuild. (I love having access to source code!)
On 30.1.2004, at 18:22, Karl Eklund wrote:
Jan 30 17:07:09 kalle imap(ke): file imap-bodystructure.c: line 278 (part_parse_headers): assertion failed: (part->physical_pos >= input->v_offset - start_offset)
Is there something I can do to determine which message it crashed on?
Maildir format, version 0.99.10.4.
gdb backtrace would be useful from that, it'd also tell which message triggered it. See core dumps section in http://dovecot.org/bugreport.html
Timo Sirainen wrote:
On 30.1.2004, at 18:22, Karl Eklund wrote:
Jan 30 17:07:09 kalle imap(ke): file imap-bodystructure.c: line 278 (part_parse_headers): assertion failed: (part->physical_pos >= input->v_offset - start_offset)
Is there something I can do to determine which message it crashed on?
Maildir format, version 0.99.10.4.
gdb backtrace would be useful from that, it'd also tell which message triggered it. See core dumps section in http://dovecot.org/bugreport.html
I don't get a core file if I set the drop privileges option that you describe there. Also I maybe should have mentioned the next line in the log file:
Jan 31 17:47:56 kalle imap(ke): file imap-bodystructure.c: line 279 (part_parse_headers): assertion failed: (part->physical_pos >= input->v_offset - start_offset) Jan 31 17:47:56 kalle dovecot: child 4912 (imap) killed with signal 6
So it seems that it's not a proper crash (not signal 11) but that it exits voluntarily from the i_assert macro. Maybe that's why no core file appears?
I also tried to figure out how to log some more info as Kenneth Porter suggested, but I can't manage to find out how to get the file name, or anything otherwise useful.
I'm not a programmer and I never looked at the dovecot code before. If I knew how to jump around between function definitions etc without having to search with grep, perhaps I could find it.
--On Saturday, January 31, 2004 4:56 PM +0000 Karl Eklund kalle-e@medelklassen.com wrote:
So it seems that it's not a proper crash (not signal 11) but that it exits voluntarily from the i_assert macro. Maybe that's why no core file appears?
Likely, but also check that "ulimit -c" allows the process to dump core. Use ulimit to set the max core dump size before launching dovecot.
Kenneth Porter wrote:
Likely, but also check that "ulimit -c" allows the process to dump core. Use ulimit to set the max core dump size before launching dovecot.
OK, I inserted "ulimit -c 50000" before /usr/local/sbin/dovecot in my startup script, but no core file appears. I think I would need some help with what you suggested, adding some more logging.
Karl Eklund wrote:
Kenneth Porter wrote:
Likely, but also check that "ulimit -c" allows the process to dump core. Use ulimit to set the max core dump size before launching dovecot.
OK, I inserted "ulimit -c 50000" before /usr/local/sbin/dovecot in my startup script, but no core file appears. I think I would need some help with what you suggested, adding some more logging.
Perhaps mounting the filesystem with something else than 0 as last but one item in fstab solves it?
- Jonas
Jonas Smedegaard wrote:
Perhaps mounting the filesystem with something else than 0 as last but one item in fstab solves it?
Why? The dump option seems to have something to do with a kind of backup system, according to man fstab. Also, it seems to be possible to get a core dump:
~ $ cat crash.c main() { char *s; while(1) { *s = "a"; ++s; } } ~ $ gcc -o crash crash.c crash.c: In function `main': crash.c:1: warning: assignment makes integer from pointer without a cast ~ $ ulimit -c 50000 ~ $ ./crash Segmentation fault (core dumped) ~ $ -rw------- 1 ke users 49152 Feb 2 22:19 core ~ $
On 2004.02.02 22:21, Karl Eklund wrote:
Jonas Smedegaard wrote:
Perhaps mounting the filesystem with something else than 0 as last but one item in fstab solves it?
Why? The dump option seems to have something to do with a kind of backup system, according to man fstab. Also, it seems to be possible to get a core dump:
~ $ cat crash.c main() { char *s; while(1) { *s = "a"; ++s; } } ~ $ gcc -o crash crash.c crash.c: In function `main': crash.c:1: warning: assignment makes integer from pointer without a cast ~ $ ulimit -c 50000 ~ $ ./crash Segmentation fault (core dumped) ~ $ -rw------- 1 ke users 49152 Feb 2 22:19 core
50000 is a bit small for a core file. They usually are tens of megabytes, as the internal memory and mapped files are dumped as well.
Use "ulimit -c unlimited" to enable coredumps instead.
Mike.
Miquel van Smoorenburg wrote:
50000 is a bit small for a core file. They usually are tens of megabytes, as the internal memory and mapped files are dumped as well.
Use "ulimit -c unlimited" to enable coredumps instead.
But my ulimit (which is built into bash) wants you to specify the size in kilobytes.
Anyway, I have also done strace on the "imap" process and found some of the problematic messages.
I attach the output from strace (don't know if it's useful?) and the messages (there seems to be more of them, but I don't know how many or how long it would take to find them all with strace).
Sorry about this confusion, I don't know what has happened but now I get the core file.
Operating system: Gentoo, dovecot version 0.99.10.4, not from Gentoo.
Syslog:
Feb 2 22:23:01 kalle imap-login: Login: ke [213.114.209.34] Feb 2 22:23:02 kalle imap(ke): file imap-bodystructure.c: line 279 (part_parse_headers): assertion failed: (part->physical_pos >= input->v_offset - start_offset) Feb 2 22:23:02 kalle dovecot: child 10144 (imap) killed with signal 6
/home/ke # gdb /usr/local/libexec/dovecot/imap core GNU gdb 5.3 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 "i686-pc-linux-gnu"... Core was generated by `imap'. Program terminated with signal 6, Aborted. Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x400562e1 in kill () from /lib/libc.so.6 (gdb) bt #0 0x400562e1 in kill () from /lib/libc.so.6 #1 0x40056085 in raise () from /lib/libc.so.6 #2 0x400575fb in abort () from /lib/libc.so.6 #3 0x08086935 in i_syslog_panic_handler (fmt=0x0, args=0x0) at failures.c:306 #4 0x08086749 in i_panic (format=0x0) at failures.c:198 #5 0x0807c5f8 in part_parse_headers (part=0x80ad7a0, input=0x80ab68c, start_offset=0, pool=0x80ad700) at imap-bodystructure.c:285 #6 0x0807c5ca in part_parse_headers (part=0x80ad758, input=0x80ab68c, start_offset=0, pool=0x80ad700) at imap-bodystructure.c:285 #7 0x0807cd43 in imap_part_get_bodystructure (pool=0x80ad700, part=0xbffff944, input=0x6, extended=0) at imap-bodystructure.c:500 #8 0x08075a67 in mail_index_update_headers (update=0xbffff944, input=0x80ad758, cache_fields=DATA_FIELD_BODY, header_cb=0, context=0x0) at mail-index-update.c:489 #9 0x08075c3a in cache_record (index=0x80ab048, rec=0x80ab708, cache_fields=DATA_FIELD_BODY) at mail-index-update-cache.c:26 #10 0x08075cde in mail_index_update_cache (index=0x80ab048) at mail-index-update-cache.c:48 #11 0x080742fd in index_open_and_fix (index=0x80ab048, flags=3) at mail-index-open.c:164 #12 0x0807491b in mail_index_open_index (index=0x80ab048, flags=3) at mail-index-open.c:384 #13 0x08074a7d in mail_index_open (index=0x3, flags=0) at mail-index-open.c:429 ---Type <return> to continue, or q <return> to quit--- #14 0x0806e922 in index_storage_mailbox_init (storage=0x80a5928, box=0x80ab048, index=0x80ab048, name=0x80a5cb0 "spam", readonly=0, fast=0) at index-storage.c:338 #15 0x0805b50f in maildir_open (storage=0x80a5928, name=0x80a5cb0 "spam", readonly=0, fast=0) at maildir-storage.c:313 #16 0x0805b625 in maildir_open_mailbox (storage=0x80a5928, name=0x80a5cb0 "spam", readonly=0, fast=0) at maildir-storage.c:346 #17 0x08053352 in _cmd_select_full (client=0x809cef8, readonly=1075145120) at cmd-select.c:23 #18 0x08053529 in cmd_select (client=0x0) at cmd-select.c:87 #19 0x08054a2c in client_handle_input (client=0x80a5cb0) at client.c:314 #20 0x08054ac8 in _client_input (context=0x80a59f0) at client.c:350 #21 0x0808ab23 in io_loop_handler_run (ioloop=0x80a5070) at ioloop-poll.c:214 #22 0x0808a4b8 in io_loop_run (ioloop=0x80a5070) at ioloop.c:258 #23 0x0805aab9 in main (argc=1, argv=0x0, envp=0x0) at main.c:179 #24 0x4004290c in __libc_start_main () from /lib/libc.so.6 (gdb)
I've tried to find the message 1075145120 (if that now is the message number), but there is no file in .maildir with that in the name. Some of them start with 107514, however.
participants (5)
-
Jonas Smedegaard
-
Karl Eklund
-
Kenneth Porter
-
Miquel van Smoorenburg
-
Timo Sirainen