Trunk Crash in [@ ValidateRealName] reading mail/nntp.

VERIFIED FIXED in mozilla0.9.9

Status

MailNews Core
MIME
P1
critical
VERIFIED FIXED
17 years ago
9 years ago

People

(Reporter: stephend@netscape.com (gone - use stephen.donner@gmail.com instead), Assigned: Jean-Francois Ducarroz)

Tracking

({crash, regression, topcrash})

Trunk
mozilla0.9.9
crash, regression, topcrash

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Fixed in branch and trunk, crash signature)

Attachments

(1 attachment, 1 obsolete attachment)

Stack Signature  ValidateRealName 82df0444
Trigger Time 2002-03-05 13:07:03
Email Address stephend@netscape.com
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.
(Assignee)

Comment 4

17 years ago
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 pllx6123@eudoramail.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.
OS: Windows 2000 → All
Hardware: PC → All
(Assignee)

Comment 7

17 years ago
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
(Assignee)

Comment 8

17 years ago
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
(Assignee)

Comment 9

17 years ago
Created attachment 72736 [details] [diff] [review]
Proposed fix, v1

Updated

17 years ago
Keywords: nsbeta1 → nsbeta1+
Priority: -- → P1
*** Bug 129234 has been marked as a duplicate of this bug. ***

Comment 11

17 years ago
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 !

Comment 12

17 years ago
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 !

Comment 13

17 years ago
Adding topcrash KW to track with talkback.
Keywords: topcrash
Summary: Crash in [ @ ValidateRealName] reading mail/nntp. → Trunk Crash in [ @ ValidateRealName] reading mail/nntp.

Comment 14

17 years ago
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 15

17 years ago
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+
(Assignee)

Comment 16

17 years ago
Yes I'll. Thanks
(Assignee)

Updated

17 years ago
Whiteboard: have fix, waiting review → have fix, waiting for approval

Comment 17

17 years ago
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+

Comment 18

17 years ago
oops, meant to say 0.9.9 branch too. Thanks.
(Assignee)

Comment 19

17 years ago
*** Bug 129322 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 20

17 years ago
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.
(Assignee)

Comment 21

17 years ago
Created attachment 72852 [details] [diff] [review]
Proposed fix, v2
Attachment #72736 - Attachment is obsolete: true
(Assignee)

Updated

17 years ago
Whiteboard: have fix, waiting for approval → have fix, waiting for reviews

Comment 22

17 years ago
Comment on attachment 72852 [details] [diff] [review]
Proposed fix, v2

r=varada; This seems like a better fix.
Attachment #72852 - Flags: review+

Comment 23

17 years ago
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+
(Assignee)

Comment 25

17 years ago
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

Comment 26

17 years ago
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 ...

Comment 27

17 years ago
*** Bug 129433 has been marked as a duplicate of this bug. ***
QA Contact: esther → stephend

Comment 28

17 years ago
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.

Comment 29

17 years ago
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 → ---
(Assignee)

Comment 30

17 years ago
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 ago17 years ago
Resolution: --- → FIXED

Comment 31

17 years ago
OK, filed a new bug 129876 "Mozilla silently shows an empty body for a message
that is no longer there."
(Assignee)

Comment 32

17 years ago
Thanks
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.
Keywords: vbranch
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
Keywords: vbranch

Comment 35

14 years ago
*** Bug 132843 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
Product: Core → MailNews Core

Updated

9 years ago
Summary: Trunk Crash in [ @ ValidateRealName] reading mail/nntp. → Trunk Crash in [@ ValidateRealName] reading mail/nntp.
Crash Signature: [@ ValidateRealName]
You need to log in before you can comment on or make changes to this bug.