User Comments :- - Tried to close the window - Opening mail... cancelled the wizard setup. Tried to close the window - Closed the window before the page finished loading (http://pub9.ezboard.com/borange88079) - A pop up window had opened up and I was closing it. - Closed the browser and it crashed immediately after. - had been trying to invoke a java game - just had clicked on the link (www.come.to/mac.warez) - www.elkhart.lib.in.us Platform : Windows 98 4.10 build 67766446 Stack Trace : StyleSetImpl::CantRenderReplacedElement [d:\builds\seamonkey\mozilla\layout\base\src\nsStyleSet.cpp, line 1112] FrameManager::HandlePLEvent [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 774] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 576] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 539] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1032] KERNEL32.DLL + 0x363b (0xbff7363b) KERNEL32.DLL + 0x242e7 (0xbff942e7) 0x00688bda Code Around the Crash :- 1105 NS_IMETHODIMP 1106 StyleSetImpl::CantRenderReplacedElement(nsIPresContext* aPresContext, 1107 nsIFrame* aFrame) 1108 { 1109 hyatt 3.61 nsCOMPtr<nsIPresShell> shell; 1110 aPresContext->GetShell(getter_AddRefs(shell)); 1111 return mFrameConstructor->CantRenderReplacedElement(shell, aPresContext, aFrame); 1112 troy 3.32 }

Adding keywords topcrash, crash, nsbeta2.

can't do much with this bug as described. can anybody come up with a reproducable test case? namachi, is there any chance you can narrow this down somewhat?

could be a possible timing problem that becomes more appearant on a slow connection. I couldn't make any of these test urls fail on high speed connection in the office... tever, what is the proxy that simulates a dialup connection? could have also been fixed since beta 1. I was using 5/6 build when I just looked at the test urls above on win95. shiva, we might also dig some more to see if its platform/os version specific.

Reassigning to buster - Triaging Troy's bug list.

putting in M17 bucket, though without a reproducable test case I won't be able to do much.

unless we find a reproducable test case, this will get marked worksforme. Namachi, can you reproduce with a recent build?

USER COMMETS : http://www.altoids.com Just clicking around in altoids.com I was able to reproduce one time. Another User :- spawning successive new browser windows using the javascript onunload event I am anlaysing the Feedback Data for more easily re-producible case.

thank you for your help, namachi. if you can find better test cases, that will help a lot. in the meantime, I'll work with what you've added here.

More Information from Talkback Data:- - These crashes more happens 95/98 only. It is not experienced in NT(or other OS). - It may also be due to very slow network condition.

Steps to Re-produce the crash Launch Netscape6 fresh. Open another window(Ctrl + N or File->New) Load URL=http://www.planetquake.com/polycount/ Half the way in loading close the second window(loading window). Boom. It crashes. It is easily reproducible. At lease in my machine.

[nsbeta2+] if we really do have a reproducible case.

on 2 different machines (WinNT and Win98) I am 100% unable to reproduce this still. anybody else? chris? QA?

With the Mac and Windows May 26th builds, I can reproduce this problem. Closing the second window as the content is loading seems to be the major factor.

Crash closing the second window is easy to re-produce in the release version but very difficult to re-produce using debug build.

timing related? wonder what might happen if we found a way to slow down the optimized build shutdown???

building an optimized build with symbols. hopefully, that will give me a reproducable case where I can get a good stack trace.

ok, this one was tough to track down. with an optimized build with symbols on, I got it to reproduce one time. It seems that the static callback FrameManager::HandlePLEvent() could get called during FrameManager's destructor after frames had been destroyed but before the frame manager itself had completed its own destruction. That would lead to a valid FrameManager but an illegal value for the cached frame that the event was targeted at. I added a boolean value on the frame manager that must be checked before any processing of events is allowed to take place. This value is set to true in the constructor and set to false at the beginning of the destructor, so any events that occur during destruction are ignored. RickG, since you worked on a related bug, can you please code review? Patch already attached.

fix checked in r=rickg

This seems reasonable, but I couldn't reproduce the problem to test the code. My only concern is that there may be other issues of this sort lurking in the code. The changes proposed here do not appear to be risky; r=rickg.

Mr. Buster, YOU ROCK!

Following crashes seems to have happened afte you have checked in the code. I may or may not relate to the fix. Buster, can you verify ? Stack Trace : - Incident ID 11814511 StyleSetImpl::CantRenderReplacedElement [d:\builds\seamonkey\mozilla\layout\base\src\nsStyleSet.cpp, line 1174] FrameManager::HandlePLEvent [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 815] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 576] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 539] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1034] USER32.dll + 0x1820 (0x77e71820) StyleSetImpl::CantRenderReplacedElement http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/base/src/nsStyleSet.c pp line 1174 Build: 2000060421 CrashDate: 2000-06-05 UptimeMinutes: 6 Total: 124 OS: Windows NT 4.0 build 1381 URL: Comment: sending email message to alex Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=11833140 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/base/src/nsStyleSet.c pp line 1174 Build: 2000060421 CrashDate: 2000-06-05 UptimeMinutes: 63 Total: 63 OS: Windows NT 4.0 build 1381 URL: Comment: Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=11819365 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/base/src/nsStyleSet.c pp line 1174 Build: 2000060421 CrashDate: 2000-06-05 UptimeMinutes: 89 Total: 89 OS: Windows 98 4.10 build 67766446 URL: Comment: Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=11817047 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/base/src/nsStyleSet.c pp line 1174 Build: 2000060421 CrashDate: 2000-06-05 UptimeMinutes: 16 Total: 16 OS: Windows 98 4.10 build 67766446 URL: Comment: Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=11814701 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/base/src/nsStyleSet.c pp line 1174 Build: 2000060421 CrashDate: 2000-06-05 UptimeMinutes: 8 Total: 8 OS: Windows NT 4.0 build 1381 URL: Comment: Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=11814024 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/base/src/nsStyleSet.c pp line 1174 Build: 2000060421 CrashDate: 2000-06-05 UptimeMinutes: 7 Total: 129 OS: Windows 98 4.10 build 67766222 URL: Comment: Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=11810934 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/base/src/nsStyleSet.c pp line 1174 Build: 2000060421 CrashDate: 2000-06-05 UptimeMinutes: 6 Total: 6 OS: Windows NT 4.0 build 1381 URL: Comment: Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=11808391 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/base/src/nsStyleSet.c pp line 1174 Build: 2000060409 CrashDate: 2000-06-04 UptimeMinutes: 27 Total: 56 OS: Windows 98 4.10 build 67766222 URL: Comment: Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=11790324 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/base/src/nsStyleSet.c pp line 1174 Build: 2000060421 CrashDate: 2000-06-05 UptimeMinutes: 76 Total: 76 OS: Windows 98 4.10 build 67766222 URL: Comment: Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=11847105 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/base/src/nsStyleSet.c pp line 1174 Build: 2000060421 CrashDate: 2000-06-05 UptimeMinutes: 117 Total: 117 OS: Windows NT 4.0 build 1381 URL: Comment: Sending email message Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=11832730 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/base/src/nsStyleSet.c pp line 1174 Build: 2000060421 CrashDate: 2000-06-05 UptimeMinutes: 15 Total: 15 OS: Windows NT 4.0 build 1381 URL: Comment: Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=11814511

marking fixed again. please reopen if you see any reports with a build 6/5 or later, or if I've made a mistake in interpreting the data here. leaf, chofmann, can you help determine if my fix got into the builds in the logs mentioned below? maybe I've misunderstood the reports added here, or how to read the build identifiers. But all these crashes are with builds with identifier 2000060421 or 2000060409, which I'm guessing was created without my checkin: From bonsai: 06/04/2000 20:37 buster%netscape.com mozilla/ layout/ html/ base/ src/nsFrameManager.cpp 1.53 34/2 bug 38665 r=rickg a=rickg fixed an optimized-only crash that looks like a race condition where we send a message containing a pointer to a frame back to the frame manager after the frames have been deleted.

Fixed in the June 20th build.