Package: mutt
Version: 1.5.9-1
Severity: important

I have a big inbox with over 6000 mails and mutt segfaults when it tries
to fetch the message headers from the IMAP server.  The imap server that
I am using is ...

$ telnet my.imap.server 143
Trying 10.72.128.60...
Connected to my.imap.server
Escape character is '^]'.
* OK Microsoft Exchange 2000 IMAP4rev1 server version 6.0.6603.0 
(my.imap.server) ready.
^]q

telnet> q

I've looked at around 6 or so bugs that have reported mutt segfaults but
they seem to be about changing the locale settings, using different IMAP
servers, thread editing etc.  This bug looks different from those, and
hence, a few points based on the reports that I looked at:

- I am using the header cache feature
- I did not set the $charset variable in the configuration
- The only difference from when it was working fine and started dumping
  core was an increase in the number of mails in the inbox.  The message
  at which the segmentation fault happens is the same always.

Some backtrace information:  (I compiled apt-gotten source and removed
the dh_strip directive from the debian/rules file)

Fetching message headers... [5844/6504]
Program received signal SIGSEGV, Segmentation fault.
cmd_parse_fetch (idata=0x81a33a8,
    s=0x81a4242 "5844 FETCH (UID 38726 FLAGS (\\Seen) INTERNALDATE \" 
9-May-2005 15:01:26 +0530\" RFC822.SIZE 7967 BODY[HEADER.FIELDS (DATE FROM 
SUBJECT TO CC MESSAGE-ID REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION 
IN-REP"...) at command.c:481
481           if (h->active && h->index+1 == msgno)
(gdb) bt
#0  cmd_parse_fetch (idata=0x81a33a8,
    s=0x81a4242 "5844 FETCH (UID 38726 FLAGS (\\Seen) INTERNALDATE \" 
9-May-2005 15:01:26 +0530\" RFC822.SIZE 7967 BODY[HEADER.FIELDS (DATE FROM 
SUBJECT TO CC MESSAGE-ID REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION 
IN-REP"...) at command.c:481
#1  0x080c8baf in cmd_handle_untagged (idata=0x81a33a8) at command.c:361
#2  0x080c8338 in imap_cmd_step (idata=0x81a33a8) at command.c:144
#3  0x080cc27b in imap_read_headers (idata=0x81a33a8, msgbegin=0, msgend=6503) 
at message.c:241
#4  0x080ca1a6 in imap_open_mailbox (ctx=0x81232a8) at imap.c:741
#5  0x080861b9 in mx_open_mailbox (path=0x5 <Address 0x5 out of bounds>, 
flags=0, pctx=0x0) at mx.c:718
#6  0x0807c5e8 in main (argc=3, argv=0xbffffc64) at main.c:944
(gdb) f 0
#0  cmd_parse_fetch (idata=0x81a33a8,
    s=0x81a4242 "5844 FETCH (UID 38726 FLAGS (\\Seen) INTERNALDATE \" 
9-May-2005 15:01:26 +0530\" RFC822.SIZE 7967 BODY[HEADER.FIELDS (DATE FROM 
SUBJECT TO CC MESSAGE-ID REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION 
IN-REP"...) at command.c:481
481           if (h->active && h->index+1 == msgno)
(gdb) p h
$1 = (HEADER *) 0x0

So the reason for SIGSEGV was because we were trying to access h->active
when h NULL.

(gdb) l
476       /* see cmd_parse_expunge */
477         for (cur = 0; cur < idata->ctx->msgcount; cur++)
478         {
479           h = idata->ctx->hdrs[cur];
480
481           if (h->active && h->index+1 == msgno)
482           {
483             dprint (2, (debugfile, "Message UID %d updated\n", 
HEADER_DATA(h)->uid));
484             break;
485           }
(gdb) p cur
$2 = 5843

Consistently crashing at the same cur value.

(gdb) p idata->ctx->msgcount
$3 = 5892

I don't know the code, but I was wondering if this should have been
6504, the total number of messages present.  Or maybe that is the number
of messages that have headers fetched in the header cache file.  I dont
know how I could verify that, but I did not have more than 300 *new*
mails over the weekend, so idata->ctx->msgcount may not be that.

(gdb) p idata->ctx->hdrs[5842]
$4 = (HEADER *) 0x86d9ea8
(gdb) p *$4
$5 = {security = 0, mime = 0, flagged = 0, tagged = 0, deleted = 0, changed = 
0, attach_del = 0, old = 0, read = 1, expired = 0, superseded = 0,
  replied = 0, subject_changed = 0, threaded = 0, display_subject = 0, 
irt_changed = 0, refs_changed = 0, recip_valid = 0, active = 1, trash = 0,
  zhours = 7, zminutes = 0, zoccident = 1, searched = 0, matched = 0, collapsed 
= 0, limited = 0, num_hidden = 0, recipient = 0, pair = 0,
  date_sent = 1115629181, received = 1115629187, offset = 0, lines = 0, index = 
5842, msgno = 0, virtual = 0, score = 0, env = 0x86d9f08,
  content = 0x86da790, path = 0x0, tree = 0x0, thread = 0x0, new_env = 0x0, 
chain = 0x0, refno = 0, data = 0x86d9e98, maildir_flags = 0x0}
(gdb) p idata->ctx->hdrs[5843]
$6 = (HEADER *) 0x0
(gdb) p idata->ctx->hdrs[5844]
$7 = (HEADER *) 0x0
(gdb) p idata->ctx->hdrs[5845]
$8 = (HEADER *) 0x0
(gdb) p idata->ctx->hdrs[5841]
$9 = (HEADER *) 0x86da060
(gdb) p idata->ctx->hdrs[5840]
$10 = (HEADER *) 0x86d9678
(gdb)

So all the HEADER's upwards of message 5843 are NULL.

Going to the frame 1, as to how we got here ...

(gdb) f 1
#1  0x080c8baf in cmd_handle_untagged (idata=0x81a33a8) at command.c:361
361           cmd_parse_fetch (idata, pn);
(gdb) l
356         }
357         /* pn vs. s: need initial seqno */
358         else if (ascii_strncasecmp ("EXPUNGE", s, 7) == 0)
359           cmd_parse_expunge (idata, pn);
360         else if (ascii_strncasecmp ("FETCH", s, 5) == 0)
361           cmd_parse_fetch (idata, pn);
362       }
363       else if (ascii_strncasecmp ("CAPABILITY", s, 10) == 0)
364         cmd_parse_capabilities (idata, s);
365       else if (ascii_strncasecmp ("MYRIGHTS", s, 8) == 0)
(gdb) p s
$13 = 0x81a4247 "FETCH (UID 38726 FLAGS (\\Seen) INTERNALDATE \" 9-May-2005 
15:01:26 +0530\" RFC822.SIZE 7967 BODY[HEADER.FIELDS (DATE FROM SUBJECT TO CC 
MESSAGE-ID REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION IN-REPLY-TO"...
(gdb) p idata
$14 = (IMAP_DATA *) 0x81a33a8
(gdb) p pn
$15 = 0x81a4242 "5844 FETCH (UID 38726 FLAGS (\\Seen) INTERNALDATE \" 
9-May-2005 15:01:26 +0530\" RFC822.SIZE 7967 BODY[HEADER.FIELDS (DATE FROM 
SUBJECT TO CC MESSAGE-ID REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION IN-REP"...

Not many clues (atleast in the core as to why HEADER was NULL.  Same
with frame 2 and other frames that I looked at.

Please do let me know if there is any information that I can provide to
help nail this bug down.  I will add more information to this report
after doing some experiments with fresh header cache information etc.

Giridhar 

-- 
Y Giridhar Appaji Nag | http://www.appaji.net/

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.10-1-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages mutt depends on:
ii  exim [mail-transport-agent] 3.36-17      An MTA (Mail Transport Agent)
ii  libc6                       2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libdb4.1                    4.1.25-18    Berkeley v4.1 Database Libraries [
ii  libgnutls11                 1.0.16-13    GNU TLS library - runtime library
ii  libidn11                    0.5.13-1.0   GNU libidn library, implementation
ii  libncurses5                 5.4-4        Shared libraries for terminal hand
ii  libsasl2                    2.1.19-1.5   Authentication abstraction library

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to