mutt.core Segfault 11

[shep]

I have had a persistent problem since I started using mail/mutt in OpenBSD 5.4. It continues in -current

My mutt setup does more than read the /var/spool/user directory. I call getmail/fetchmail and run the message through /usr/local/libexec/rcvstore to get a mh mailbox format. The overall intent is to have a mailbox setup that can also be access via mail/sylpheed and mail/claws-mail.

I've set a macro in my muttrc to call fetchmail and once mail retrival is finished, hitting a key to continue usually results in a core dump. Calling fetchmail manually and then opening mutt works without a problem.

I also do not get the core dumps with the same configuration files in FreeBSD, NetBSD or Debian. I've tried getmail and opening mutt in an xterm rather than rxvt-unicode and it still cores. If no new mails are retrieved it does not core.

My debug output:

oBear$ gdb mutt mutt.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 "amd64-unknown-openbsd5.8"...
(no debugging symbols found)

Core was generated by `mutt'.
Program terminated with signal 11, Segmentation fault.
(no debugging symbols found)
Loaded symbols for /usr/local/bin/mutt
Reading symbols from /usr/lib/libncurses.so.14.0...done.
Loaded symbols for /usr/lib/libncurses.so.14.0
Reading symbols from /usr/lib/libssl.so.35.0...done.
Loaded symbols for /usr/lib/libssl.so.35.0
Reading symbols from /usr/lib/libcrypto.so.35.0...done.
Loaded symbols for /usr/lib/libcrypto.so.35.0
Reading symbols from /usr/lib/libz.so.5.0...done.
Loaded symbols for /usr/lib/libz.so.5.0
Reading symbols from /usr/local/lib/libsasl2.so.3.0...done.
Loaded symbols for /usr/local/lib/libsasl2.so.3.0
Reading symbols from /usr/local/lib/libqdbm.so.14.14...done.
Loaded symbols for /usr/local/lib/libqdbm.so.14.14
Reading symbols from /usr/local/lib/libintl.so.6.0...done.
Loaded symbols for /usr/local/lib/libintl.so.6.0
Reading symbols from /usr/local/lib/libiconv.so.6.0...done.
Loaded symbols for /usr/local/lib/libiconv.so.6.0
Reading symbols from /usr/local/lib/libidn.so.17.2...done.
Loaded symbols for /usr/local/lib/libidn.so.17.2
Reading symbols from /usr/lib/libc.so.80.1...done.
Loaded symbols for /usr/lib/libc.so.80.1
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so
#0  strcmp () at /usr/src/lib/libc/arch/amd64/string/strcmp.S:46
46              movq    8(%rsi),%rdx
(gdb) bt
#0  strcmp () at /usr/src/lib/libc/arch/amd64/string/strcmp.S:46
#1  0x00000cce3da43b15 in index_make_entry () from /usr/local/bin/mutt
#2  0x00000cce3da52460 in mutt_parse_hook () from /usr/local/bin/mutt
#3  0x00000cce3da2e643 in index_color () from /usr/local/bin/mutt
#4  0x00000cce3da4a82f in mutt_parse_hook () from /usr/local/bin/mutt
#5  0x00000cce3da17571 in ?? () from /usr/local/bin/mutt
#6  0x0000000000000000 in ?? ()
Current language:  auto; currently asm

Any suggestions as to where to go next?

[jggimi]

How are you at reading source code of 3rd party ports, and slogging through gdb?

If you wish, you can build the mutt port with debugging symbols (DEBUG=-g) and package an unstripped binary (INSTALL_STRIP= ). You'll get a slightly more detailed stack trace at your next failure, and have tools to step through by source code line, set breakpoints, watch variables, etc.

As you may have noticed, libraries are built with debugging symbols, however applications aren't built with symbols by default.

[shep]

With some guidance, I rebuilt with debugging symbols and submitted to sthen@ (the maintainer). He thinks it is an upstream bug:

... really looking like a Mutt bug rather than something OS-specific, and I don't think it's related to the number of file handles. It's possible that some of the hardening which is enabled by default in OpenBSD is causing it to reliably fail on something which is silently causing corruption on other OS (this can happen with our malloc hardening, amongst other things).

I just submitted a ticket to http://dev.mutt.org/trac.

[jggimi]

Excellent job.