GNOME Bugzilla – Bug 378823
Current CVS (0.120) Lockup @ 100% CPU on attempt to reply, message-ID escaping bug?
Last modified: 2006-11-27 18:51:44 UTC
Marked critical due to freeze at 100% CPU. I was trying to reply to a message, only every time I tried, pan would lockup using 100% (of one) CPU without display of the compose window, and I'd have to kill it and restart and reenter the group to try again. Immediate thought is (going present tense) that the cached copy is corrupt, altho pan displays it fine, so I open pan and load the message again, displaying headers, as to get the message-ID. Then I go try to find it in the cache. IT'S NOT THERE!! Despite the fact that pan continues to display it as downloaded and continues to display the message itself when I click it, there's NO MESSAGE IN THE CACHE WITH THAT M-ID! OK, don't panic, try to use tab completion, as it /does/ have a couple strange characters (like $) in the m-id. NO GO, even just trying to tab-complete on the first character (a %). That's strange! Well, first character /is/ a bit odd, so let's see what a wildcard search on a string in the middle of the filename comes up with? SUCCESS! The on-disk version has a couple extra characters in its name than the message-id header displays. That may be our problem. Still loading it in a text editor, it's not corrupt that I can see, so what's going on, besides the possible problem with the message-id? With the cached file copy to play with, I back it up and play with the message a bit to see if anything there seems to cause a problem. I can't get it to a state where I can reply to it, tho after removing just about everything and still having it freeze, I try removing the message-id header and after that pan will crash when trying to reply, rather than freeze. OK, it doesn't seem to be the content. That strange message-id that has extra characters as in the cache-file-name as opposed to the displayed message-id header seems to be the trigger. As displayed in pan and as in the header in the file content in cache: Message-ID: <%iz9h.2092$%_2.783@newsfe19.lga> The filename in cache: %25iz9h.2092\$%25_2.783@newsfe19.lga.msg Of course, the $ is (shell) escaped. That %25 occurring twice, where it's only % in the message-id? That appears to be a pan escaped %, assuming % is pan's escape char. Is it possible pan is escaping it when caching it, and then when retrieving for display, but doing something different when I try to followup that causes it to freeze? That's my best guess, but not being a coder I can't easily if at all decypher the actual source. Anyway, I'll attach the complete file as it appears in cache, in case the message-id stuff is fine and it's elsewhere. I'm not sure if I can provide a good gdb backtrace of the frozen reply attempt without specific step-by-step but I can try. Keep in mind I'm on amd64, so there's the possibility of size issues.
Created attachment 77097 [details] message as it appears in cache GRR! Something about the encoding between my browser (konqueror), the filesystem, and the bugzilla server, I can't get the file to attach as named in cache, bugzy keeps saying it's empty, so I'll have to rename it! The original name is in the report.
Created attachment 77098 [details] gdb session, such as it is gdb session, such as it is. Simply ran pan, entered group, selected trouble message, tried replying, got the freeze, hit ^c in gdb and got a backtrace. If you need me to recompile pan with -g or the like in CXXFLAGS and try again, let me know exactly what you need, and I'll try it again.
Please apply this debugging patch, re-run, and add a comment to this ticket saying what the app's output was. Index: post-ui.cc =================================================================== RCS file: /cvs/gnome/pan2/pan/gui/post-ui.cc,v retrieving revision 1.6 diff -u -r1.6 post-ui.cc --- post-ui.cc 7 Nov 2006 16:35:31 -0000 1.6 +++ post-ui.cc 27 Nov 2006 17:38:51 -0000 @@ -1528,6 +1528,11 @@ const StringView & from, std::string& attrib) { + std::cerr << LINE_ID << " attrib [" << attrib << ']' + << " mid [" << mid << ']' + << " date [" << date << ']' + << " from [" << from << ']' << std::endl; + std::string::size_type pos;
You can disregard comment #3... I've already fixed this in CVS.
Just as well as I was having a tough time getting the patch to apply, working thru my pan-cvs ebuild script (the first time I'd try to apply a patch since I started using my adapted to CVS ebuild). I finally got it to see the file to patch, only to get a reject, but maybe that was your fix already in place. =8^)
Fix confirmed. =8^)