#3797: mutt.core Signal 11 Segmentation Fault OpenBSD 5.4 -> Current
------------------------+----------------------
Reporter: shepper | Owner: mutt-dev
Type: defect | Status: new
Priority: major | Milestone:
Component: maildir/mh | Version: 1.5.24
Keywords: |
------------------------+----------------------
Since I started using Mutt --sasl in OpenBSD, it will often core dump when
using a macro to fetchmail/getmail. The emails are downloaded and are
readable when mutt is re-opened.
I use the same configuration files, adjusted for rcvstore path, in Debian,
FreeBSD and NetBSD without issue. The problem persists in OpenBSD current
with the 1.5.24 release.
I submitted debug output to the OpenBSD maintainer who replied:
"Thanks - that is what I'm looking for, but it's 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)."
Here is a link to DaemonForums describing my setup
http://daemonforums.org/showthread.php?t=9538
and the debug output:
> >Please build mutt with debug symbols and get a backtrace with line
numbers:
> >
> >make clean; FLAVOR=whatever make DEBUG="-O0 -g" repackage &&
FLAVOR=whatever make reinstall
> >
> PooBear$ ls *.core
> mutt.core
> PooBear$ 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"...
> Core was generated by `mutt'.
> Program terminated with signal 11, Segmentation fault.
> 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) thread apply all backtrace
>
> Thread 1 (process 24325):
> #0 strcmp () at /usr/src/lib/libc/arch/amd64/string/strcmp.S:46
> #1 0x0000083f93cac9f2 in mutt_strcmp (a=0x841da7b2a20 "2731",
> b=0x8426ccb5d40 <Address 0x8426ccb5d40 out of bounds>) at lib.c:874
> #2 0x0000083f93c56571 in hash_find_hash (table=0x84197eac780, hash=184,
> key=0x841da7b2a20 "2731") at hash.c:124
> #3 0x0000083f93c6c712 in mh_check_mailbox (ctx=0x841c4c91e00,
> index_hint=0x7f7fffff079c) at mh.c:2115
> #4 0x0000083f93c70818 in mx_check_mailbox (ctx=0x841c4c91e00,
> index_hint=0x7f7fffff079c, lock=0) at mx.c:1389
> #5 0x0000083f93c37239 in mutt_index_menu () at curs_main.c:478
> #6 0x0000083f93c5fe25 in main (argc=1, argv=0x7f7fffff18d8) at
> main.c:1050
> Current language: auto; currently asm
> (gdb)
If I can supply any additional info/test let me know -
Mutt does Suck Less
Thanks
Scott H.
--
Ticket URL: <http://dev.mutt.org/trac/ticket/3797>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
