Occasional segfault when IMAP inbox updates

[skunk]

Version: mutt-20070709
Platform: Debian/etch on amd64

I have an IMAP inbox that is updated asynchronously on a remote server. Sometimes, when new messages come in, and Mutt has uncommitted changes to the inbox, it segfaults.

This is what it looks like in GDB:

Fetching message headers... 1899/1900
Program received signal SIGSEGV, Segmentation fault.
0x000000000044f25e in mx_update_context (ctx=0x7b15d0, new_messages=4)
    at mx.c:1566
1566          h->security = crypt_query (h->content);
(gdb) p h->content
Cannot access memory at address 0x50
(gdb)

I have two core dumps saved from these crashes, and so can return additional telemetry upon request.

[brendan]

Do you have the mutt version? What patches, if any, are applied?

[berni]

Replying to brendan:

Do you have the mutt version? What patches, if any, are applied?

I can confirm this, Ubuntu 8.04 Hardy version on i386

Mutt 1.5.17+20080114 (2008-01-14)
Copyright (C) 1996-2007 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 2.6.24-16-generic (i686)
ncurses: ncurses 5.6.20071124 (compiled with 5.6)
libidn: 1.1 (compiled with 1.1)
hcache backend: GDBM version 1.8.3. 10/15/2002 (built Jun 15 2006 21:19:27)
Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE
+USE_FCNTL  -USE_FLOCK
+USE_POP  +USE_IMAP  +USE_SMTP  -USE_GSS  -USE_SSL_OPENSSL  +USE_SSL_GNUTLS  +USE_SASL  +HAVE_GETADDRINFO
+HAVE_REGCOMP  -USE_GNU_REGEX
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  -CRYPT_BACKEND_GPGME
-EXACT_ADDRESS  -SUN_ATTACHMENT
+ENABLE_NLS  -LOCALES_HACK  +COMPRESSED  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET  +HAVE_LANGINFO_YESEXPR
+HAVE_ICONV  -ICONV_NONTRANS  +HAVE_LIBIDN  +HAVE_GETSID  +USE_HCACHE
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"
MIXMASTER="mixmaster"
To contact the developers, please mail to <mutt-dev@mutt.org>.
To report a bug, please visit http://bugs.mutt.org/.

patch-1.5.13.cd.ifdef.2
patch-1.5.13.cd.purge_message.3.4
patch-1.5.13.nt+ab.xtitles.4
patch-1.5.4.vk.pgp_verbose_mime
patch-1.5.6.dw.maildir-mtime.1
patch-1.5.8.hr.sensible_browser_position.3

gdb backtrace looks like this

#0  mx_update_context (ctx=0x817fd28, new_messages=3) at ../mx.c:1664
        h = (HEADER *) 0x0
        msgno = 308
#1  0x080e2f71 in imap_read_headers (idata=0x81a2580, msgbegin=306, msgend=307) at ../../imap/message.c:346
        ctx = (CONTEXT *) 0x817fd28
        buf = "FETCH 307:308 (UID FLAGS INTERNALDATE RFC822.SIZE BODY.PEEK[HEADER.FIELDS (DATE FROM SUBJECT TO CC MESSAGE-ID REFERENCES C
ONTENT-TYPE CONTENT-DESCRIPTION IN-REPLY-TO REPLY-TO LINES LIST-POST X-LABEL)]"...
        hdrreq = "BODY.PEEK[HEADER.FIELDS (DATE FROM SUBJECT TO CC MESSAGE-ID REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION IN-REPLY-TO REP
LY-TO LINES LIST-POST X-LABEL)]", '\0' <repeats 14 times>, "�qη�qη�k��\034%/\b���\020)/\bPqη�k���mٷ\020l��"...
        fp = (FILE *) 0x82ee1c8
        tempfile = "/tmp/mutt-lxbsc01-1000-14756-18\000\000\000\000�8\000\000\000diɷ\000\000\000\0008\b)\bhj���L�;�\020\b ��\000\000\000\
000\t\000\000\000���\000\000\000\000p}\020\b\210j��\020\002�\000\000\000\000�\200Է1m�tj��\000\000\000\000\030k���Z�hk��<3;H\024\v\n\000\0
20\002�\001\000\000\000�j��hk��\006o�\001\000\000\000�j���k��\000\000\000\000@k��#�ηLk���k��\200\000\000\000�\n�\001Tk��"...
        msgno = 308
        h = {sid = 308, data = 0x82ee358, received = 1211839279, content_length = 646}
        status = <value optimized out>
        rc = -1209998992
        mfhrc = 307
        oldmsgcount = 306
        fetchlast = 308
        maxuid = 69032
        progress = {inc = 10, flags = 2, msg = 0xb7ac2004 <Address 0xb7ac2004 out of bounds>, pos = 307, size = 308, timestamp = 0,
  sizestr = "308", '\0' <repeats 124 times>}
        uid_validity = (unsigned int *) 0x0
        uidnext = (unsigned int *) 0x0
        evalhc = 0
#2  0x080da7be in imap_cmd_finish (idata=0x81a2580) at ../../imap/command.c:308
No locals.
#3  0x080dcab8 in imap_check_mailbox (ctx=0x817fd28, index_hint=0xbfb66d8c, force=0) at ../../imap/imap.c:1393
        idata = (IMAP_DATA *) 0x81a2580
        result = 0

Mailbox is open with Thunderbird in parallel.

Looks like a duplicate to #2985 and #2570

[berni]

okay, did some more research, I'm not a C coder by any chance but I found some weird things

first of all, imap_read_headers is called

imap_read_headers (idata=0x81a2580, msgbegin=306, msgend=307) at ../../imap/message.c:346

for msg 306-307 (so two messages). However, in the end msgcount is 308 and mx_update_context is called for three new messages

#0 mx_update_context (ctx=0x817fd28, new_messages=3) at ../mx.c:1664

the pointer to the headers for messages 306 and 307 are fine, but for 308 the address is 0x0 and a segfault occurs when accessing h->security

(gdb) p ctx->hdrs[306]
$7 = (HEADER *) 0x82ee590
(gdb) p ctx->hdrs[307]
$8 = (HEADER *) 0x8308d90
(gdb) p ctx->hdrs[308]
$9 = (HEADER *) 0x0

Could this be related to IMAP IDLE? I'm running dovecot on the server side (happens with both Dovecot 1.0 and 1.1), which is mentioned in the manpage for causing connection stalls.

I'll try with imap_idle=no now, unfortunately this bug is not easy to reproduce.