Closed Bug 235209 Opened 21 years ago Closed 20 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: 20 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: