492496 - reproducible crash [@ specializeTreesToMissingGlobals ] - js3250.dll@0x60b87 js3250.dll@0x60b7e

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect, P1)

Description

[chris hofmann]

only appears in beta4 top 100 at #96 but it does seem easily immediately reproducible if you visit

 http://www.danawa.com/elec/     js3250.dll@0x60b87

stack trace on 
Version	3.5b5pre  Build ID	20090508031530  Branch 1.9.1
OS	Mac OS X 10.5.6 9G55

looks like:

 Frame  	Module  	Signature [Expand]  	Source
0 	libmozjs.dylib 	specializeTreesToMissingGlobals 	js/src/jstracer.cpp:1223
1 	libmozjs.dylib 	specializeTreesToMissingGlobals 	js/src/jstracer.cpp:1224
2 	libmozjs.dylib 	TraceRecorder::findNestedCompatiblePeer 	js/src/jstracer.cpp:3985
3 	libmozjs.dylib 	js_RecordLoopEdge 	js/src/jstracer.cpp:3837
4 	libmozjs.dylib 	js_MonitorLoopEdge 	js/src/jstracer.cpp:4436
5 	libmozjs.dylib 	js_Interpret 	js/src/jsinterp.cpp:3835
6 	libmozjs.dylib 	js_Execute 	js/src/jsinterp.cpp:1599
7 	libmozjs.dylib 	JS_EvaluateUCScriptForPrincipals 	js/src/jsapi.cpp:5145
8 	XUL 	nsJSContext::EvaluateString 	dom/src/base/nsJSEnvironment.cpp:1603
9 	XUL 	nsScriptLoader::EvaluateScript 	content/base/src/nsScriptLoader.cpp:686
10 	XUL 	nsScriptLoader::ProcessRequest 	content/base/src/nsScriptLoader.cpp:600
11 	XUL 	nsScriptLoader::ProcessScriptElement 	content/base/src/nsScriptLoader.cpp:554
12 	XUL 	nsScriptElement::MaybeProcessScript 	content/base/src/nsScriptElement.cpp:193
13 	XUL 	nsHTMLScriptElement::MaybeProcessScript 	content/html/content/src/nsHTMLScriptElement.cpp:546
14 	XUL 	HTMLContentSink::ProcessSCRIPTEndTag 	content/html/document/src/nsHTMLContentSink.cpp:3142
15 	XUL 	SinkContext::CloseContainer 	content/html/document/src/nsHTMLContentSink.cpp:1022
16 	XUL 	HTMLContentSink::CloseContainer 	content/html/document/src/nsHTMLContentSink.cpp:2393
17 	XUL 	CNavDTD::CloseContainer 	parser/htmlparser/src/CNavDTD.cpp:2800
18 	XUL 	CNavDTD::HandleEndToken 	parser/htmlparser/src/CNavDTD.cpp:1679
19 	XUL 	CNavDTD::HandleToken 	parser/htmlparser/src/CNavDTD.cpp:760
20 	XUL 	CNavDTD::BuildModel 	parser/htmlparser/src/CNavDTD.cpp:332
21 	XUL 	nsParser::BuildModel 	parser/htmlparser/src/nsParser.cpp:2378
22 	XUL 	nsParser::ResumeParse 	parser/htmlparser/src/nsParser.cpp:2251
23 	XUL 	nsParser::ContinueInterruptedParsing 	parser/htmlparser/src/nsParser.cpp:1751
24 	XUL 	nsRunnableMethod<nsContentSink>::Run 	nsThreadUtils.h:264
25 	XUL 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:510
26 	XUL 	NS_ProcessPendingEvents_P 	nsThreadUtils.cpp:180
27 	XUL 	nsBaseAppShell::NativeEventCallback 	widget/src/xpwidgets/nsBaseAppShell.cpp:121
28 	XUL 	nsAppShell::ProcessGeckoEvents 	widget/src/cocoa/nsAppShell.mm:405
29 	CoreFoundation 	CoreFoundation@0x735f4 	
30 	CoreFoundation 	CoreFoundation@0x73cd7 	
31 	HIToolbox 	HIToolbox@0x302bf 	
32 	HIToolbox 	HIToolbox@0x30011 	
33 	HIToolbox 	HIToolbox@0x2ff4c 	
34 	AppKit 	AppKit@0x40d7c 	
35 	AppKit 	AppKit@0x4062f 	
36 	JavaEmbeddingPlugin 	JavaEmbeddingPlugin@0x12fc2 	
37 	AppKit 	AppKit@0x3966a 	
38 	XUL 	nsAppShell::Run 	widget/src/cocoa/nsAppShell.mm:716
39 	XUL 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:193
40 	XUL 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3298
41 	firefox-bin 	main 	browser/app/nsBrowserApp.cpp:156
42 	firefox-bin 	firefox-bin@0x1541 	
43 	firefox-bin 	firefox-bin@0x1468 	
44 		@0x0

Comment 1

[chris hofmann]

might also appear as signature js3250.dll@0x60b7e - http://www.danawa.com

Comment 2

[chris hofmann]

also hit the crash at
clicking around on left hand menu at http://www.solarlog-home.de/gergal/ 
& follow up session restore of crash at http://www.solarlog-home.de/gergal/ 

other users have crashed there with stack signature js3250.dll@0x60b7e which ranks #33 for 3.5b4.

combining those two immediately reproducable crashes plus other possible js3250.dll signatures could move this much higher in the rankings

need to look at other possible 
js3250.dll@0x73075 crashes on wide number of facebook, ebay, & google map pages
to see if they might also be related.

Comment 3

[chris hofmann]

js3250.dll@0x73075 crashes have a much different stack.  following up to another bug.

Comment 4

[Andreas Gal :gal]

Can you capture the page to make sure we don't lose this one? If you can reproduce offline that would be great (I will start working on this immediately, but just to make sure it doesn't go away server side).

Comment 5

[Andreas Gal :gal]

I am a bit worried about the stacks I see. Making this private. Explanation to follow.

Comment 6

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: Sort-of reduced semi-local testcase

Comment 7

[Andreas Gal :gal]

Doesn't crash for me. The main page stopped crashing too.

Comment 8

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Should probably up the severity. Better reduced testcase to follow.

Comment 9

[Andreas Gal :gal]

Trashing: 0x193c2ee0
specializing: 0x193c3460
specializing: 0x193c47a0
specializing: 0x193c2ee0
specializing: 0x193c3460
specializing: 0x193c47a0
specializing: 0x193c47a0
specializing: 0x193c2ee0
specializing: 0x193c3460
specializing: 0x193c47a0
specializing: 0x193c47a0
specializing: 0x193c2ee0
specializing: 0x193c3460
specializing: 0x193c47a0
specializing: 0x193c47a0
specializing: 0x193c47a0
specializing: 0x193c2ee0

We trash a tree, and moments later we access it again trying to specialize it.

Comment 10

[Andreas Gal :gal]

Yeah, this is use after free and all sorts of exploitable.

Comment 11

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: 360-line fully local testcase

Sort-of crashable.

Comment 12

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to comment #11)
> Created an attachment (id=377226) [details]
> 360-line fully local testcase
> 
> Sort-of crashable.

Manually refresh this to crash latest Shiretoko - Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090513 Shiretoko/3.5b5pre

Comment 13

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Will wake up after sleep to get a fully reduced testcase.

Comment 14

[Andreas Gal :gal]

Ok, this is very odd:

Trashing: 0x17350e80, ti = 0x0
specializing linked: 0x173513f0
specializing linked: 0x173526f0
specializing dependent: 0x17350e80
specializing linked: 0x173513f0
specializing dependent: 0x173526f0
specializing linked: 0x173526f0
specializing dependent: 0x17350e80
specializing linked: 0x173513f0
specializing dependent: 0x173526f0
specializing linked: 0x173526f0
specializing dependent: 0x17350e80
specializing linked: 0x173513f0
specializing dependent: 0x173526f0
specializing linked: 0x173526f0
specializing dependent: 0x173526f0
specializing dependent: 0x17350e80

0x17350e80 is a dependent tree, but its tree info is NULL and hence the linked tree never got cleared

Comment 15

[Andreas Gal :gal]

Purging fragments for JSScript 0x1a490440.

and later on

Looking for type-compatible peer (http://www.danawa.com/js/common_func.js:165@262)
checking nested types 0x1a4910e0: capture global type global5: 0=O
specializing dependent: 0x1a4916f0
capture global type global5: 0=O
specializing dependent: 0x1a490440

I think dependent trees don't get cleared when we purge fragments from global scripts. Have to confer with graydon.

Comment 16

[Andreas Gal :gal]

Attachment: patch

When purging global scripts, we bypassed js_TrashTree, which left some dependent and linked trees in a stale state. Purge all tree roots with a matching ip using TrashTrees. The branches will be pruned automatically by doing so.

Comment 17

[Andreas Gal :gal]

Attachment: patch without debug junk

Comment 18

[Andreas Gal :gal]

chris, can you try to confirm that the patch fixes the problem?

Comment 19

[Andreas Gal :gal]

Attachment: list only contains tree roots, so assert that

Comment 20

[Graydon Hoare :graydon]

Comment on attachment 377246 [details] [diff] [review]
list only contains tree roots, so assert that

Oh dear. Sorry, yes, that's better.

Comment 21

[Andreas Gal :gal]

This bug exists on branch. I think its very hard to exploit in practice. We can probably open this up after rc1.

Comment 22

[Andreas Gal :gal]

http://hg.mozilla.org/tracemonkey/rev/3416e3d9c616

Comment 23

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: 33-line fully reduced non-shell testcase

Would welcome thoughts on how possible this is to turn into a shell testcase.

Comment 24

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/3416e3d9c616

Comment 25

[Robert Sayre]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d90e57b010f9

Comment 26

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verified fixed on trunk and 1.9.1 with:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090522 Minefield/3.6a1pre ID:20090522032716

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090521 Shiretoko/3.5pre ID:20090521135222

Comment 27

[Christian Holler (:decoder)]

Filter on qa-project-auto-change:

Bug in removed tracer code, setting in-testsuite- flag.