Re: [Mutt] #2935: Occasional segfault when IMAP inbox updates
#2935: Occasional segfault when IMAP inbox updates
---------------------+------------------------------------------------------
Reporter: skunk | Owner: brendan
Type: defect | Status: started
Priority: major | Milestone: 1.6
Component: IMAP | Version: 1.5.19
Resolution: | Keywords: duplicate 2902
---------------------+------------------------------------------------------
Old description:
> Version: mutt-20070709[[BR]]
> 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.
New description:
Version: mutt-20070709[[BR]]
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.
--
Comment(by brendan):
Ok, from Vegard's muttdebug, I think I've found the problem:
{{{
4> a2520 FETCH 98488:98488 (UID FLAGS INTERNALDATE RFC822.SIZE
BODY.PEEK[HEADER.FIELDS (DATE FR
OM SUBJECT TO CC MESSAGE-ID REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION
IN-REPLY-TO REPLY-TO LI
NES LIST-POST X-LABEL)])
4< * 98488 FETCH (UID 190458 RFC822.SIZE 11310 FLAGS (NonJunk)
INTERNALDATE "01-Apr-2009 12:11:
29 +0000" BODY[HEADER.FIELDS (Date From Subject To Cc Message-Id
References Content-Type Conten
t-Description In-Reply-To Reply-To Lines List-Post X-Label)] {570}
imap_read_literal: reading 570 bytes
4< )
parse_parameters: `charset=iso-8859-1'
parse_parameter: `charset' = `iso-8859-1'
4< * 98488 FETCH (UID 190458 FLAGS (NonJunk))
Message UID 190458 updated
Only handle FLAGS updates
parse_parameters: `charset=iso-8859-1'
parse_parameter: `charset' = `iso-8859-1'
4< a2520 OK done
}}}
We're receiving two separate updates for message 98488, and it's confusing
imap_read_headers. That's why new_messages in mx_update_context is 2 when
only one new message has arrived. I think this should be fairly
straightforward to fix.
--
Ticket URL: <http://dev.mutt.org/trac/ticket/2935#comment:>
Mutt <http://www.mutt.org/>
The Mutt mail user agent