<<< Date Index >>>     <<< Thread Index >>>

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