Stack Signature ValidateRealName 82df0444 Trigger Time 2002-03-05 13:07:03 Email Address firstname.lastname@example.org URL visited . Build ID 2002030508 Product ID MozillaTrunk Platform Operating System Win32 Module Trigger Reason Access violation User Comments AOL mail CONSISTENTLY crashes... Stack Trace ValidateRealName [mimemoz2.cpp, line 247] GenerateAttachmentData [mimemoz2.cpp, line 431] MimeGetAttachmentList [mimemoz2.cpp, line 557] mime_display_stream_complete [mimemoz2.cpp, line 925] nsStreamConverter::OnStopRequest [nsStreamConverter.cpp, line 1016] nsDocumentOpenInfo::OnStopRequest [nsURILoader.cpp, line 254] nsStreamListenerTee::OnStopRequest [nsStreamListenerTee.cpp, line 25] nsOnStopRequestEvent0::HandleEvent [nsAsyncStreamListener.cpp, line 321] nsStreamListenerEvent0::HandlePLEvent [nsAsyncStreamListener.cpp, line 122] PL_HandleEvent [plevent.c, line 591] _md_EventReceiverProc [plevent.c, line 1072] SETUPAPI.DLL + 0x30c24 (0x778b0c24)
This was just the movie trivia mail that Laura K sent out - it crashed twice, and now that the message has moved into my Old Mail folder, I can no longer reproduce this.
Keywords: crash, nsbeta1, regression
*** Bug 129139 has been marked as a duplicate of this bug. ***
Not specific to IMAP or AOL - changing scope, because of dup bug 129139.
Summary: Trying to read an AOL mail message crashes in [ @ ValidateRealName] → Crash in [ @ ValidateRealName] reading mail/nntp.
Would be nice if I could have a test message!
JFD - this isn't reproducible 100% - must be some race condition.
i was crashing while viewing news, and my trace info is the same. occurred on win2k, mac 10.1.3 and linux rh7.2. here is the recipe. 0. created a news account for news.mozilla.org, and subscribed to a couple of groups, npm.macosx and npm.accessibility. 1. went into npm.accessibility, clicked to view an (unread) article eg: the one from jsosic with the "???" subject. 2. tried to "delete" (cancel) the article by hitting the Delete key. i got a dlg saying that i couldn't cancel it since i wasn't the poster --so i clicked OK there. 3. clicked to view another article --one of those spam ones which made the throbber in the mailnews 3pane go on and on and on... a good article for this would be posted from email@example.com with the subject "PLLX: What's All The Buzz About?" 4. since the throbber on the article wouldn't stop, i hit the Stop button. results: crash. a good way to repro this is to add the npm.accessbility group and follow the recipe above...i noticed that step 2 is needed here, otherwise i don't get the throbber behavior for steps 3 and 4.
I can reproduce the problem with a debug build on Windows. Stephend, QA, can you test the branch build to see if it get the same problem. Tahnks
THis is very very strange, looks like some time (but this is not constant), the object's headers are null! I am not sure what could have caused that regression, the culprit could be the fix for bug 93439 but I odn't see how! Anyway, I need to check the headers pointer before accessing it. I am pretty sur the branch build has the same problem therefore setting target to 0.9.9
Status: NEW → ASSIGNED
Whiteboard: have fix, waiting review
Target Milestone: --- → mozilla0.9.9
*** Bug 129234 has been marked as a duplicate of this bug. ***
I am sorry for having made a duplicate ! But I did not find this one :-( I had crashes when trying to read expired article, and I uninstalled this build for an older one who did not had this bug ! I also downloaded the build from latest-0.9.9 folder ! Let's hope it doesn't have the same bug !
Some informations from the /war/ ! I downloaded a build from latest 0.9.9 and it had this *annoying* bug. Here is the build ID 2002030511 Let's hope this bug would be *killed* in the 0.9.9 milestone release !
Adding topcrash KW to track with talkback.
Summary: Crash in [ @ ValidateRealName] reading mail/nntp. → Trunk Crash in [ @ ValidateRealName] reading mail/nntp.
Comment on attachment 72736 [details] [diff] [review] Proposed fix, v1 r=varada. I guess we should also find out why that particular case leads to a null header.
Attachment #72736 - Flags: review+
Comment on attachment 72736 [details] [diff] [review] Proposed fix, v1 If the fact that aHdrs is null is such a shock, can you add an assertion? Other than that, sr=bienvenu
Attachment #72736 - Flags: superreview+
Yes I'll. Thanks
Whiteboard: have fix, waiting review → have fix, waiting for approval
Comment on attachment 72736 [details] [diff] [review] Proposed fix, v1 a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #72736 - Flags: approval+
oops, meant to say 0.9.9 branch too. Thanks.
*** Bug 129322 has been marked as a duplicate of this bug. ***
I am not totally satisfied by my patch. Sure it will prevent the crash but it doesn't explain while we get in that situation! I took a more close look at all the checking that append during Monday morning and Tuesday morning and the only potential culprit I found if the fix I made for bug 128887. When we have an inline message object and CountTotalMimeAttachments is 0, we use to return but since I test for this case and increment the count, we will continue to execute the function which lead to the crash. I was able to test this case when I read an AOL message from my INBOX which has been moved to the READ folder by the server. I will post a new patch which will increment the count only if it > 0.
Created attachment 72852 [details] [diff] [review] Proposed fix, v2
Attachment #72736 - Attachment is obsolete: true
Whiteboard: have fix, waiting for approval → have fix, waiting for reviews
Comment on attachment 72852 [details] [diff] [review] Proposed fix, v2 r=varada; This seems like a better fix.
Attachment #72852 - Flags: review+
Comment on attachment 72852 [details] [diff] [review] Proposed fix, v2 sr=bienvenu
Attachment #72852 - Flags: superreview+
Comment on attachment 72852 [details] [diff] [review] Proposed fix, v2 a=dbaron for 0.9.9 and trunk checkin
Attachment #72852 - Flags: approval+
Fix checked in the branch and the trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Whiteboard: have fix, waiting for reviews → Fixed in branch and trunk
I was hitting this crash frequently in my AOL account, just an update -- looks OK using mar7 commercial trunk build with win98. Will try other platforms ...
*** Bug 129433 has been marked as a duplicate of this bug. ***
17 years ago
QA Contact: esther → stephend
Another scenario that gives 100% reproducability: 0) Open two Mozilla's (for example, on two different machines) pointing to the same IMAP account (I am using Courier IMAP server that's OK with that): "A" and "B" 1) Open the same (folder (in the 3-pane win, withour selecting a particular message) on both A and B. 2) On A, delete some message(s) from the folder and compact. 3) On B, select a header of a message that was deleted on A. With BuildID 2002030616 on RedHat Linux 7.2, B does the following: - updates the message count in the folders pane - updates the headers view (removed the headers of deleted messages) - crashes. I am compiling a today's build, will verify if my scenario is fixed as well.
It seems that this fixed it in the wrong place. In my scenario (with two Mozillas accessing one IMAP server) BuildId 2002030908 currently does *none* of the things it used to do. And while no longer crashing is definitely a good thing, no longer updating message counter and no longer removing headers of the messages that are no longer there (Mozilla now happily shows me an empty message if I select one of those headers!) seems like a substantial regression.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Please file a new bug for the new problem, it's not anymore a mime issue but a mailnews front-end problem. This bug is about the crash only which has been fixed.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago → 17 years ago
Resolution: --- → FIXED
OK, filed a new bug 129876 "Mozilla silently shows an empty body for a message that is no longer there."
Sarah, thanks so much for the steps to reproduce! Verified on the *trunk* only at the moment, on builds: Mac OS 9.2 - 2002-03-13-08 RedHat 7.2 - 2002-03-13-08 Windows 2K - 2002-03-13-03 Now, onward to the branch I go.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311 Netscape6/6.2.1+ Mozilla/5.0 (Windows; U, Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020312 Netscape6/6.2.1+ Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US, rv:0.9.9) Gecko/20020310 Verified FIXED on both the trunk and the branch, now. (I also checked talkback)
Status: RESOLVED → VERIFIED
*** Bug 132843 has been marked as a duplicate of this bug. ***
Summary: Trunk Crash in [ @ ValidateRealName] reading mail/nntp. → Trunk Crash in [@ ValidateRealName] reading mail/nntp.
You need to log in before you can comment on or make changes to this bug.