471260 - [TM] Crash @ memcpy when we're JIT'ng content

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect, P2)

Description

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081227 Shiretoko/3.1b3pre ID:20081227034437

1. New profile, start firefox
2. Visit URL http://www.cdfreaks.com/news/13428-Doom9-finds-Ripit4Me--FixVTS-takedown-culprit.html
3. CRASH!

http://crash-stats.mozilla.com/report/index/4c9722bc-e4e0-4e28-bf2e-d504e2081227?p=1

Frame  	Module  	Signature [Expand]  	Source
0 	mozcrt19.dll 	memcpy 	memcpy.asm:407
1 	js3250.dll 	array_join_sub 	js/src/jsarray.cpp:1395
2 	js3250.dll 	array_join 	js/src/jsarray.cpp:1580
3 	js3250.dll 	js_Interpret 	js/src/jsinterp.cpp:5119
4 	js3250.dll 	js_Execute 	js/src/jsinterp.cpp:1559
5 	js3250.dll 	obj_eval 	js/src/jsobj.cpp:1345
6 	js3250.dll 	js_Invoke 	js/src/jsinterp.cpp:1313
7 	js3250.dll 	js_Interpret 	js/src/jsinterp.cpp:5136
8 	js3250.dll 	js_Execute 	js/src/jsinterp.cpp:1559
9 	js3250.dll 	JS_EvaluateUCScriptForPrincipals 	js/src/jsapi.cpp:5189
10 	xul.dll 	nsJSContext::EvaluateString 	dom/src/base/nsJSEnvironment.cpp:1588
11 	xul.dll 	nsScriptLoader::EvaluateScript 	content/base/src/nsScriptLoader.cpp:665
12 	xul.dll 	nsScriptLoader::ProcessRequest 	content/base/src/nsScriptLoader.cpp:579
13 	xul.dll 	nsScriptLoader::ProcessScriptElement 	content/base/src/nsScriptLoader.cpp:533
14 	xul.dll 	nsContentUtils::HasNonEmptyTextContent 	content/base/src/nsContentUtils.cpp:3721
15 	xul.dll 	nsScriptElement::MaybeProcessScript 	content/base/src/nsScriptElement.cpp:188

Crash goes away if I disable javascript.options.jit.content

Comment 1

[timeless]

bug 470607 was trunk

Comment 2

[Sander]

I've been trying to create a minimal testcase. So far this has been without success, as I haven't been able to reproduce this locally - however, I got as far as discovering that the trigger seems to be the way a gzipped (?) version of tinymce is loaded in an ajax request (and security restrictions thus frustrated the testcase creation), and I can reproduce what seems to be the same crash when I visit http://tinymce.moxiecode.com/examples/example_13.php and then click on the [Load TinyMCE] link underneath the textarea.
That should hopefully be a good starting point for a second attempt to create a testcase tomorrow, but perhaps it's already enough information for someone to continue from there.

Comment 3

[Rick Stockton]

NOT JUST ON WINDOWS, if I'm correct in seeing the same bug occur at: http://hubpages.com/hub/hijackedbrain 

(Analogous Crash with JIT enabled for Content in Linux-x86; doesn't happen with JIT disabled. I'm using an hourly build from this morning,

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090102 Shiretoko/3.1b3pre - Build ID: 20090102122651

Here's the top few frames of my crash stack, from
http://crash-stats.mozilla.com/report/index/01aa594c-9d94-49f7-862d-d43932090102

0  	libmozjs.so  	js_MinimizeDependentStrings  	js/src/jsstr.cpp:87
1 	libmozjs.so 	js_MinimizeDependentStrings 	js/src/jsstr.cpp:89
2 	libmozjs.so 	js_GetDependentStringChars 	js/src/jsstr.cpp:114
3 	libmozjs.so 	array_join_sub(JSContext*, JSObject*, ArrayToStringOp, JSString*, long*) 	js/src/jsarray.cpp:1395
4 	libmozjs.so 	array_join(JSContext*, unsigned int, long*) 	js/src/jsarray.cpp:1580
5 	libmozjs.so 	js_Interpret 	js/src/jsinterp.cpp:5119
6 	libmozjs.so 	js_Invoke 	js/src/jsinvoke.cpp:1331

Comment 4

[Jim Jeffery not reading bug-mail 1/2/11]

FYI, I don't crash on any of the above links using the latest nightly 'trunk' 

jit.content is set to 'true' 
jit.chrome is set to default 'false'

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090103 Minefield/3.2a1pre Firefox/3.0.4 ID:20090103114424

Comment 5

[Rick Stockton]

Yep The TRUNK bug https://bugzilla.mozilla.org/show_bug.cgi?id=470607 is Resolved/WFM, via some TM "merge" Update which has already been applied to Trunk. But comments in that bug don't show any attempt to identify exactly what part of the "merge" updates constituted the fix for this bug...

So someone way smarter than me about this stuff is going to choose, whether to (1) attempt bringing 3.1 "Branch" TM all the way up to current Trunk merge set; or (2) pick and choose specific fixes for a different "merge" set. (I'll SWAG it's the latter, but I'm a dummy about this.)

Comment 6

[Sander]

Attachment: testcase

Not quite a minimal testcase yet, but a long way there.

Comment 7

[Sander]

Attachment: minimal testcase

This is about as minimal as I can get the testcase.

Comment 8

[Steve England [:stevee]]

The URL crashes the 20081224 trunk build but doesn't crash the 20081226 build. Between these dates there was a TM merge so I'm guessing one of those patches fixed this crash.

Shaver suggested on IRC today that there will probably be a cherry-pick'd mini TM merge to the 1.9.1 branch before 3.1beta3, so this bug should get fixed by that.

Comment 9

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090107 Shiretoko/3.1b3pre ID:20090107042444

This now WFM after the TM merge to the 1.9.1 branch. Sander's testcase doesn't crash me either, and neither does Rick's URL from comment 3

--> WORKSFORME