Closed Bug 235209 Opened 21 years ago Closed 21 years ago

nymets.com page crash when pop-up created

Categories

(SeaMonkey :: General, defect)

x86
Windows 2000
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: franklin, Assigned: jst)

References

()

Details

(Keywords: crash)

Attachments

(3 files)

User-Agent: Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040221 Firefox/0.8.0+ Firefox crashes every time I visit nymets.com with pop-ups unblocked. The page starts to load, then a small pop-up is crated near the bottom right corner of the screen and firefox crashes. Confirmed in latest nightly. Reproducible: Always Steps to Reproduce: 1. Unblock popups generally, or just for nymets.com 2. Visit nymets.com 3. Actual Results: Firefox crashes Expected Results: Load Nymets.com with popups
Confirmed 20040220 PC/WinXP Mozilla 1.6 does not show the same problem.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
The popup window at nymets.com opens, does a bunch of stuff including checking for the RealPlayer plugin, then quickly closes itself. The crash is happening because the window quickly closes itself. I'll attach a stripped down testcase. That testcase, running on my own hard drive (this crash may be timing related) reliably crashes my Firefox 20040223 build. It also crashes my Seamonkey 20040223 build, but not as reliably. Keep trying. It'll go. (So I've changed this bug's Product field to be more general.) The crash happens here, at the line marked with ****s. |context| has been deleted. Apparently it was destroyed during execution of the previous line, context->EvaluateString. at end of method nsScriptLoader::EvaluateScript : ... context->SetProcessingScriptTag(PR_TRUE); PRBool isUndefined; context->EvaluateString(aScript, nsnull, principal, url.get(), aRequest->mLineNo, aRequest->mJSVersion, ret, &isUndefined); context->SetProcessingScriptTag(PR_FALSE); ************ return rv; } nsScriptLoader::EvaluateScript(nsScriptLoadRequest * 0x03618dd8, const nsString & {...}) line 657 + 16 bytes nsScriptLoader::ProcessRequest(nsScriptLoadRequest * 0x03618dd8) line 573 + 22 bytes nsScriptLoader::ProcessScriptElement(nsScriptLoader * const 0x03a0bd08, nsIDOMHTMLScriptElement * 0x0365db88, nsIScriptLoaderObserver * 0x0365db8c) line 519 + 20 bytes nsHTMLScriptElement::MaybeProcessScript() line 646 + 118 bytes nsHTMLScriptElement::SetDocument(nsIDocument * 0x03af4280, int 0, int 1) line 471 nsGenericElement::AppendChildTo(nsIContent * 0x0365db68, int 0, int 0) line 2577 HTMLContentSink::ProcessSCRIPTTag(const nsIParserNode & {...}) line 4353 HTMLContentSink::AddLeaf(HTMLContentSink * const 0x03a0bbd0, const nsIParserNode & {...}) line 3210 + 15 bytes HTMLContentSink::AddHeadContent(HTMLContentSink * const 0x03a0bbd0, const nsIParserNode & {...}) line 3163 + 19 bytes CNavDTD::AddHeadLeaf(nsIParserNode * 0x036519c0) line 3839 + 31 bytes CNavDTD::HandleStartToken(CToken * 0x035650f0) line 1832 + 12 bytes CNavDTD::HandleToken(CNavDTD * const 0x036517b8, CToken * 0x00000000, nsIParser * 0x03721268) line 1019 + 12 bytes CNavDTD::BuildModel(CNavDTD * const 0x036517b8, nsIParser * 0x03721268, nsITokenizer * 0x036c4968, nsITokenObserver * 0x00000000, nsIContentSink * 0x03a0bbd0) line 511 + 20 bytes nsParser::BuildModel(nsParser * const 0x03721268) line 1894 + 34 bytes nsParser::ResumeParse(int 1, int 0, int 1) line 1761 + 12 bytes nsParser::OnDataAvailable(nsParser * const 0x0372126c, nsIRequest * 0x03a0a138, nsISupports * 0x00000000, nsIInputStream * 0x035c7edc, unsigned int 0, unsigned int 175) line 2426 + 21 bytes nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x03b82a60, nsIRequest * 0x03a0a138, nsISupports * 0x00000000, nsIInputStream * 0x035c7edc, unsigned int 0, unsigned int 175) line 335 + 46 bytes nsFileChannel::OnDataAvailable(nsFileChannel * const 0x03a0a140, nsIRequest * 0x036fce60, nsISupports * 0x00000000, nsIInputStream * 0x035c7edc, unsigned int 0, unsigned int 175) line 595 nsInputStreamPump::OnStateTransfer() line 433 + 65 bytes nsInputStreamPump::OnInputStreamReady(nsInputStreamPump * const 0x036fce64, nsIAsyncInputStream * 0x035c7edc) line 336 + 11 bytes nsInputStreamReadyEvent::EventHandler(PLEvent * 0x03b70254) line 119 PL_HandleEvent(PLEvent * 0x03b70254) line 671 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00c54d10) line 606 + 9 bytes I'm guessing Johnny wants this. Feel free of course to reassign, but not to me!
Assignee: firefox → jst
Component: General → Browser-General
Product: Firefox → Browser
Version: unspecified → Trunk
Yup. Seamonkey crashed the third time I tried the above testcase, in bugzilla situ.
Attached patch Fix.Splinter Review
While I haven't been able to reproduce this crash, it's fairly clear from looking at the code and the stacktrace that this is the right fix.
Attachment #142179 - Flags: superreview?(bryner)
Attachment #142179 - Flags: review?(danm-moz)
Comment on attachment 142179 [details] [diff] [review] Fix. Yup. Simpler than I thought. This fixes both my simplified testcase, and this bug's original complaint. Allow me to express a concern that this subtle bug exemplifies. I'm afraid deCOMtamination is going to open up a can of dark ages stability whoop-ass on Mozilla.
Attachment #142179 - Flags: review?(danm-moz) → review+
Yeah, there's for sure risks involved in deCOMtamination, especially when dealing with interfaces to objects like the ones I touched in the bug that caused this. Scary (which is why I made that change in an alpha cycle), but IMO still very worth while.
Status: NEW → ASSIGNED
Comment on attachment 142179 [details] [diff] [review] Fix. sr=bzbarsky
Attachment #142179 - Flags: superreview?(bryner) → superreview+
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: