abrt version: 1.1.14 architecture: i686 Attached file: backtrace cmdline: mutt comment: This happens from time to time and is not reproducible on demand. Typically seems to correspond with changes to my INBOX from another IMAP or Exchange client (I am connecting via IMAP to Exchange). component: mutt crash_function: mx_update_context executable: /usr/bin/mutt kernel: 2.6.34.7-66.fc13.i686 package: mutt-5:1.5.21-1.fc13 rating: 4 reason: Process /usr/bin/mutt was killed by signal 11 (SIGSEGV) release: Fedora release 13 (Goddard) time: 1297190584 uid: 580345 How to reproduce ----- 1. Started mutt 2. Read an email. 3. Exited from reading message back to INBOX view.
Created attachment 477666 [details] File: backtrace
http://dev.mutt.org/trac/ticket/3288 http://dev.mutt.org/trac/ticket/3482
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
*** Bug 603078 has been marked as a duplicate of this bug. ***
I'm seeing the same on F14 (mutt-1.5.21-1.fc14.1.x86_64). Details are same as the upstream mutt bug mentioned in Comment #2. (gdb) bt #0 mx_update_context (ctx=0x971990, new_messages=<value optimized out>) at mx.c:1542 #1 0x0000000000494f3c in imap_read_headers (idata=0x983210, msgbegin=<value optimized out>, msgend=290559) at message.c:376 #2 0x0000000000492733 in imap_open_mailbox (ctx=0x971990) at imap.c:756 #3 0x00000000004431a7 in mx_open_mailbox (path=<value optimized out>, flags=0, pctx=0x0) at mx.c:661 #4 0x00000000004396a4 in main (argc=1, argv=<value optimized out>) at main.c:1017 (gdb) list 1537 h = ctx->hdrs[msgno]; 1538 1539 if (WithCrypto) 1540 { 1541 /* NOTE: this _must_ be done before the check for mailcap! */ 1542 h->security = crypt_query (h->content); 1543 } 1544 1545 if (!ctx->pattern) 1546 { (gdb) p *ctx $1 = {path = 0x981170 "imaps://my.imap.server/INBOX", fp = 0x0, mtime = 0, size = 3303852241, vsize = 0, pattern = 0x0, limit_pattern = 0x0, hdrs = 0x7ffff0ead010, last_tag = 0x0, tree = 0x0, id_hash = 0x0, subj_hash = 0x0, thread_hash = 0x0, v2r = 0x7ffff0d91010, hdrmax = 290585, msgcount = 290560, vcount = 111661, tagged = 0, new = 0, unread = 96911, deleted = 0, flagged = 0, msgnotreadyet = -1, magic = 5, rights = "\337\a", locked = 0, changed = 0, readonly = 0, dontwrite = 0, append = 0, quiet = 0, collapsed = 0, closing = 0, data = 0x983210, mx_close = 0x48fe10 <imap_close_mailbox>} (gdb) p msgno $2 = 111661 (gdb) p ctx->hdrs[msgno] $3 = (HEADER *) 0x0 (gdb) p ctx->hdrs[msgno-1] $4 = (HEADER *) 0x91ab760
I'm able to reproduce this failure with the following steps (but the proposed upstream patch doesn't work for me): 1. disable header caching and configure mutt to use IMAP folder 2. open mutt in first terminal, choose a folder with many messages and wait until it download message headers 3. open mutt in second terminal, choose the same folder as previously, start downloading message headers 4. delete a message from the folder (better a message from the end of the list) in the first mutt terminal 5. sync mbox by "$" in the first mutt terminal 6. the deletion has to proceed until mutt in the second terminal finishes downloading message headers 7. the second terminal crashes with SIGSEG
Created attachment 488144 [details] proposed patch to handle recently deleted messages The problem is that message headers are stored in ctx->hdrs array under index which follows their order. If we delete one message with ID 1000 from 2000 messages, there will be NULL on ctx->hdrs[999]. This NULL in this array is not handled in code, so mutt crashes with segmentation fault. Note: Maybe there can be another race conditions, that leads to the same result. I've prepared a patch, that doesn't use massage's id to retrieve position in the array (they are sorted anyway) and decreases msgend (messages count) when empty header is received. I see no more segmentation faults and no other issues using this patch. However, mutt is very complicated, so I will discuss the patch with upstream before applying.
*** Bug 602925 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > Created attachment 488144 [details] > proposed patch to handle recently deleted messages > > The problem is that message headers are stored in ctx->hdrs array under index > which follows their order. If we delete one message with ID 1000 from 2000 > messages, there will be NULL on ctx->hdrs[999]. This NULL in this array is not > handled in code, so mutt crashes with segmentation fault. > > Note: Maybe there can be another race conditions, that leads to the same > result. > > I've prepared a patch, that doesn't use massage's id to retrieve position in > the array (they are sorted anyway) and decreases msgend (messages count) when > empty header is received. > > I see no more segmentation faults and no other issues using this patch. > However, mutt is very complicated, so I will discuss the patch with upstream > before applying. Any test RPM's available for those of us too lazy to merge your patch ourselves? :)
(In reply to comment #9) > Any test RPM's available for those of us too lazy to merge your patch > ourselves? :) Sure, you can find it here: http://koji.fedoraproject.org/koji/taskinfo?taskID=2956369
Thanks. FYI, built some Fedora 13 packages as well here: http://koji.fedoraproject.org/koji/taskinfo?taskID=2957860 Will try to break things. :)
Note that this has been stable for me thus far with the slight "regression" (?) that I now get "New message in mailbox" messages, but cannot get them to actually appear in my view -- even via $ or imap-fetch-mail binding. In the past new messages would show up in my listing automatically -- sometimes. Not a big deal, I can just exit and return.
Thanks Ray, I see the regression too. Here is my another try, it seems new messages are shown properly this time. Rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=2966271 F13: http://koji.fedoraproject.org/koji/taskinfo?taskID=2966332
Created attachment 489736 [details] proposed patch to handle recently deleted messages (2nd try) This is a patch without the regression from comment #12. It's been applied in Rawhide.
*** Bug 695764 has been marked as a duplicate of this bug. ***
This has been working for me flawlessly over the last couple of weeks FYI.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
mutt-1.5.21-5.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/mutt-1.5.21-5.fc15
mutt-1.5.21-5.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/mutt-1.5.21-5.fc14
mutt-1.5.21-5.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/mutt-1.5.21-5.fc13
*** Bug 596578 has been marked as a duplicate of this bug. ***
mutt-1.5.21-5.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
mutt-1.5.21-5.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
mutt-1.5.21-5.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #19) > mutt-1.5.21-5.fc14 has been submitted as an update for Fedora 14. > https://admin.fedoraproject.org/updates/mutt-1.5.21-5.fc14 I am running mutt on Fedora 14: Name : mutt Arch : i686 Epoch : 5 Version : 1.5.21 Release : 5.fc14 I am seeing the same crash as described by Chris in comment 5. Here's my gdb log which details the error: (gdb) bt #0 mx_update_context (ctx=0x8cae580, new_messages=2545) at mx.c:1542 #1 0x080e3ed4 in imap_read_headers (idata=0x8c84060, msgbegin=2544, msgend=2545) at message.c:377 #2 0x080e1343 in imap_open_mailbox (ctx=0x8cae580) at imap.c:756 #3 0x0808dca4 in mx_open_mailbox (path=0xbf9b7e4c "imap://salexc3.pace.internal/Archive", flags=0, pctx=0x0) at mx.c:661 #4 0x080686ce in mutt_index_menu () at curs_main.c:1161 #5 0x08082e6d in main (argc=1, argv=0xbf9b8ba4) at main.c:1020 (gdb) l 1537 h = ctx->hdrs[msgno]; 1538 1539 if (WithCrypto) 1540 { 1541 /* NOTE: this _must_ be done before the check for mailcap! */ 1542 h->security = crypt_query (h->content); 1543 } 1544 1545 if (!ctx->pattern) 1546 { (gdb) p *ctx $1 = {path = 0x8c4a448 "imap://salexc3.pace.internal/Archive", fp = 0x0, mtime = 0, size = 158284467, vsize = 0, pattern = 0x0, limit_pattern = 0x0, hdrs = 0x8c51670, last_tag = 0x0, tree = 0x0, id_hash = 0x0, subj_hash = 0x0, thread_hash = 0x0, v2r = 0x8c3f9b0, hdrmax = 2571, msgcount = 2545, vcount = 2544, tagged = 0, new = 386, unread = 386, deleted = 0, flagged = 0, msgnotreadyet = -1, magic = 5, rights = "\177\001", locked = 0, changed = 0, readonly = 0, dontwrite = 0, append = 0, quiet = 0, collapsed = 0, closing = 0, data = 0x8c84060, mx_close = 0x80de940 <imap_close_mailbox>} (gdb) p msgno $2 = 2544 (gdb) p ctx->hdrs[msgno] $3 = (HEADER *) 0x0 (gdb) p ctx->hdrs[msgno-1] $4 = (HEADER *) 0x9102820 (gdb) My IMAP server is an exchange server, FWIW.
To elaborate slightly on my usage pattern which causes this bug. I'm using message and header caches. I have a folder in my inbox called "Archive" where I stash mail I've read but wish to retain for reference. Within "Archive", the current year's archived mail is stored in the root, while older mail lives in per-year subdirs: Archive/message_1 # Archive/message_2 # ... messages 1, 2 and 3 are from 2011 Archive/message_3 # Archive/2010/message_4 # Archive/2010/message_4 # ... message 4 and 5 are from 2010 To provoke the segfault, I move an email into Archive, then change pager view into the Archive folder (via. "c=Archive"). I then typically (but not always) get a segfault. If I restart mutt I can change pager view into Archive with no issues until the next time I move an email into Archive, at which point I trip over the segfault again. Having seen a fair few of these crashes it seems to be the case that the segfault occurs toward the end of the process of fetching message headers. I usually see something like this on the console: Fetching message headers... 2616/2617 (99%)Segmentation fault (core dumped)
One more observation... If I run mutt under gdb, I can work around this bug by hacking the values of new_messages and ctx->msgcount at runtime. Taking an example run, let's say I have 2 mails in INBOX and 2619 in Archive. If I were to copy one mail from INBOX to Archive then change pager view to Archive at this point I would normally get a segfault. Here's the hackery I can use to avoid the crash: 1. Set a breakpoint in mx_update_context 2. Copy one mail from INBOX to Archive 3. c=Archive to change pager view 4. gdb traps in mx_update_context: new_messages=2620 and ctx->msgcount=2620 5. modify both new_message and ctx->msgcount to 2619 6. tell gdb to continue 7. no crash occurs, but my newly copied mail is not present in the pager view, unsurprisingly 8. c=Archive to change pager view 9. gdb traps in mx_update_context: new_messages=2620 and ctx->msgcount=2620 10. /don't/ modify data, just allow gdb to continue 11. no crash occurs So it seems that the header pointer is only invalid the first time I change the pager view. The second time it appears to be correct.
(In reply to comment #25) > I am seeing the same crash as described by Chris in comment 5. That could be the same issue as in http://dev.mutt.org/trac/ticket/3288#comment:26. I've prepared a scratch build for F14, can you please test it if it fixes your issue? http://koji.fedoraproject.org/koji/taskinfo?taskID=3168770
Thanks Jan, I've just installed your scratch build and subjected it to the test procedure outlined in comment 26 above. I've run through the process three times, and observed no segfaults so far. I would have expected to see a crash by now if I was running the previous build. So far it looks like your changes fix this bug for me :-) I'll keep monitoring over the next few days. If I see the crash again, I'll repost here.
(In reply to comment #29) > Thanks Jan, I've just installed your scratch build and subjected it to the > test procedure outlined in comment 26 above. I've run through the process > three times, and observed no segfaults so far. I would have expected to see a > crash by now if I was running the previous build. > > So far it looks like your changes fix this bug for me :-) > > I'll keep monitoring over the next few days. If I see the crash again, I'll > repost here. That's great, thanks for collaboration.
(In reply to comment #29) > Thanks Jan, I've just installed your scratch build <snip> > So far it looks like your changes fix this bug for me :-) > > I'll keep monitoring over the next few days. If I see the crash again, I'll > repost here. Just to follow up, I've been running your scratch build since 29/06 and I've not run into a segfault once in that time. It fixes things for me. Many thanks.