204935 - trunk topcrash [@ nsXULDocument::OnStreamComplete]

Status: RESOLVED FIXED

(Core :: XUL, defect, P1)

Description

[Jan Carpenter]

nsXULDocument::OnStreamComplete   6 
Crash data range: 2003-05-02 to 2003-05-07
Build ID range: 2003050104 to 2003050708

Stack Trace: 

	 nsXULDocument::OnStreamComplete
[c:/builds/seamonkey/mozilla/content/xul/document/src/nsXULDocument.cpp  line 3341]
	 nsStreamLoader::OnStopRequest
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsStreamLoader.cpp  line 144]
	 nsJARChannel::OnStopRequest
[c:/builds/seamonkey/mozilla/netwerk/protocol/jar/src/nsJARChannel.cpp  line 653]
	 nsCOMPtr_base::assign_with_AddRef
[c:/builds/seamonkey/mozilla/xpcom/glue/nsCOMPtr.cpp  line 71]
	 nsInputStreamPump::OnStateStop
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsInputStreamPump.cpp  line 484]
	 nsInputStreamPump::OnInputStreamReady
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsInputStreamPump.cpp  line 325]
	 nsInputStreamReadyEvent::EventHandler
[c:/builds/seamonkey/mozilla/xpcom/io/nsStreamUtils.cpp  line 117]
	 PL_HandleEvent	[c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c  line 660]
	 PL_ProcessPendingEvents	[c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c 
line 596]
	 _md_EventReceiverProc	[c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c 
line 1396]
	 USER32.dll + 0x4455 (0x77d14455)
	 USER32.dll + 0x95d5 (0x77d195d5)
	 nsAppShellService::Run
[c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp  line 479]
	 main1	[c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp  line 1284]
	 main	[c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp  line 1650]
	 WinMain	[c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp  line 1672]
	 WinMainCRTStartup()
	 kernel32.dll + 0x214c7 (0x77e614c7)
 
 	Source File :
c:/builds/seamonkey/mozilla/content/xul/document/src/nsXULDocument.cpp line : 3341
     (19733496)	URL: www.thomson.com

Comment 1

[Greg K.]

Any relation to bug 107362?

Comment 2

[Philip K. Warren]

I was able to reproduce this behavior on AIX in some instances, and found that
the following section of code was the culprit:

http://makeashorterlink.com/?R21112BB4

In some cases mScriptGlobalObject can be null, so the following call causes a crash:

mScriptGlobalObject->GetContext(getter_AddRefs(scriptContext));

I am not familiar enough with the overall code to know if mScriptGlobalObject
should ever be null - but all other usage of this variable in nsXULDocument.cpp
is surrounded by a null-check.

Comment 3

[Brendan Eich [:brendan]]

This is mine, I think (although ben can help).

/be

Comment 4

[Brendan Eich [:brendan]]

Attachment: proposed fix

When I optimized to avoid seeks that dump the underlying stream's buffer, I
used the wrong global object to serialize out-of-line overlay scripts.	The old
code always serialized in nsXULPrototypeScript::Compile, using the
nsXULPDGlobalObject associated with the protodoc.  My bad change grabbed the
nearest global, which was nsXULDocument::mScriptGlobalObject.  But that's not a
proto-doc global, it is a real chrome window global.  And that member will be
null early, set only from the content viewer, so there's a race.

/be

Comment 5

[Johnny Stenback (:jst)]

Comment on attachment 124500 [details] [diff] [review]
proposed fix

sr=jst

Comment 6

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 124500 [details] [diff] [review]
proposed fix

r=[e-mail]

Comment 7

[Asa Dotzler [:asa]]

Comment on attachment 124500 [details] [diff] [review]
proposed fix

a=asa (on behalf of drivers) for checkin to the 1.4 branch.

Comment 8

[Brendan Eich [:brendan]]

Fixed in trunk and branch.

/be