Closed Bug 470492 Opened 13 years ago Closed 13 years ago

TM: Firefox 3.1b2 crash [@ nanojit::LIns::targetAddr() ]


(Core :: JavaScript Engine, defect)

Not set





(Reporter: chofmann, Assigned: dmandelin)


(Keywords: topcrash, verified1.9.1)

Crash Data


(1 file)

currently #5 topcrash on 3.1b2

stack looks like

0  	js3250.dll  	nanojit::LIns::targetAddr  	js/src/nanojit/LIR.cpp:644
1 	js3250.dll 	RegExpNativeCompiler::compileAnchoring 	js/src/jsregexp.cpp:2137
2 	js3250.dll 	RegExpNativeCompiler::compile 	js/src/jsregexp.cpp:2193
3 	js3250.dll 	js_NewRegExp 	js/src/jsregexp.cpp:2307
4 	js3250.dll 	js_NewRegExpOpt 	js/src/jsregexp.cpp:2381
5 	js3250.dll 	regexp_compile_sub 	js/src/jsregexp.cpp:4501
6 	js3250.dll 	RegExp 	js/src/jsregexp.cpp:4675
7 	js3250.dll 	js_Invoke 	js/src/jsinterp.cpp:1313
8 	js3250.dll 	js_InvokeConstructor 	js/src/jsinterp.cpp:1789
9 	js3250.dll 	js_Interpret 	js/src/jsinterp.cpp:4791
10 	js3250.dll 	js_Execute 	js/src/jsinterp.cpp:1559
11 	js3250.dll 	JS_EvaluateUCScriptForPrincipals 	js/src/jsapi.cpp:5187
12 	xul.dll 	nsJSContext::EvaluateString 	dom/src/base/nsJSEnvironment.cpp:1586
13 	xul.dll 	nsScriptLoader::EvaluateScript 	content/base/src/nsScriptLoader.cpp:665
14 	xul.dll 	nsScriptLoader::ProcessRequest 	content/base/src/nsScriptLoader.cpp:579
15 	xul.dll 	nsCOMArray_base::RemoveObject 	obj-firefox/xpcom/build/nsCOMArray.cpp:129
16 	xul.dll 	nsScriptLoader::ProcessPendingRequests 	content/base/src/nsScriptLoader.cpp:718 

not many comments

* it crashed as i was downloading

* hu goai pa
Flags: blocking1.9.1?
Severity: normal → critical
Summary: Firefox 3.1b2 crash [@ nanojit::LIns::targetAddr() → TM: Firefox 3.1b2 crash [@ nanojit::LIns::targetAddr() ]
The source line of stack frame 0 is:

        while ((ref=i->ref()) != 0 && ref->isTramp())

and of stack frame 1:


My first guess would be that the regexp fragment went OOM somewhere before this point and corrupted the lirbuf, causing an invalid memory ref in LIns::targetAddr.

Andreas, do you agree? Is there an easy way to replicate that condition for testing purposes? And does this mean I need an OOM check before every call to targetAddr?
Attached patch Possible fixSplinter Review
This should fix it if the cause in comment 1 is correct. I couldn't duplicate the bug, so I really don't know. But we can try it and see if the reports stop coming in. It shouldn't harm anything, anyway.
Assignee: general → dmandelin
Attachment #354875 - Flags: review?(gal)
Comment on attachment 354875 [details] [diff] [review]
Possible fix

Ugly. Really ugly. I don't like it at all but it seems necessary until we figure out a better way (exceptions, longjmp?).
Attachment #354875 - Flags: review?(gal) → review+
Polling outOMem is kind of ugly (if it works, though, it wins for now)

Otherwise SpiderMonkey generally has to test for a failure code (false, null) and propagate. Is that so bad?

Pushed to TM as 97c230b44f4a.
Flags: blocking1.9.1? → blocking1.9.1+
Closed: 13 years ago
Resolution: --- → FIXED
should this go to trunk and 1.9.1 now, or wait for more refinements or different approach?
This landed on m-c after a merge, but hasn't made it to 1.9.1 yet. Should it?
Whiteboard: [needs 1.9.1 landing]
AFAIK it should go to 1.9.1.
Flags: in-testsuite-
Flags: in-litmus-
Keywords: fixed1.9.1
Whiteboard: [needs 1.9.1 landing]
pushed awhile back

A 3-month search over crash-stats on 1.9.1-.2 and trunk as well as shiretoko queries (3.5b4pre & 3.1b3pre) results in no crash reports logged over this stack signature after patch landed.

so verified FIXED!
Crash Signature: [@ nanojit::LIns::targetAddr() ]
You need to log in before you can comment on or make changes to this bug.