Bug 602925

Summary: mutt crashes on more than a few emails
Product: [Fedora] Fedora Reporter: Ken Dreyer <ktdreyer>
Component: muttAssignee: Honza Horak <hhorak>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: mlichvar, pertusus
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-03-28 15:59:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
backtrace of crash
none
.muttdebug0
none
backtrace from abrt for mutt-1.5.21-1.fc13 none

Description Ken Dreyer 2010-06-11 02:52:05 UTC 
Created attachment 423117 [details]
backtrace of crash

I use imaps with mutt. Upon upgrading to F13, mutt segfaults every time I have more than a few emails in my Inbox folder. The limit seems to be around 20 or 40 emails in my Inbox folder.


$ mutt
Fetching message headers... 40/43 (93%)Segmentation fault (core dumped)

It always happens when "Fetching headers" reaches approximately 80 or 90%. I tried building with and without hcache.

I rebuilt the RPM with debug and optflags at -O0. backtrace is attached.

For what it's worth, the backtrace looks extremely similar to http://bugs.debian.org/584138 .
Comment 1 Ken Dreyer 2010-06-11 02:54:04 UTC 
Created attachment 423118 [details]
.muttdebug0
Comment 2 Miroslav Lichvar 2010-10-05 14:30:15 UTC 
Is this still happening with mutt-1.5.21-1.fc13?
Comment 3 Ken Dreyer 2010-10-05 15:45:19 UTC 
Created attachment 451702 [details]
backtrace from abrt for mutt-1.5.21-1.fc13

I confirmed that this still crashes mutt-1.5.21-1.fc13.i686.
Comment 4 Fedora Admin XMLRPC Client 2011-02-25 11:01:31 UTC 
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 5 Honza Horak 2011-03-28 15:59:43 UTC 
I'm sure that this bug has the same reason as bug #676074.

*** This bug has been marked as a duplicate of bug 676074 ***