Closed
Bug 470492
Opened 16 years ago
Closed 16 years ago
TM: Firefox 3.1b2 crash [@ nanojit::LIns::targetAddr() ]
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: chofmann, Assigned: dmandelin)
Details
(Keywords: topcrash, verified1.9.1)
Crash Data
Attachments
(1 file)
3.16 KB,
patch
|
gal
:
review+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Updated•16 years ago
|
Flags: blocking1.9.1?
Updated•16 years ago
|
Severity: normal → critical
Summary: Firefox 3.1b2 crash [@ nanojit::LIns::targetAddr() → TM: Firefox 3.1b2 crash [@ nanojit::LIns::targetAddr() ]
Assignee | ||
Comment 1•16 years ago
|
||
The source line of stack frame 0 is: while ((ref=i->ref()) != 0 && ref->isTramp()) and of stack frame 1: targetCurrentPoint(to_next); 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?
Assignee | ||
Comment 2•16 years ago
|
||
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 3•16 years ago
|
||
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+
Comment 4•16 years ago
|
||
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? /be
Assignee | ||
Comment 5•16 years ago
|
||
Pushed to TM as 97c230b44f4a.
Updated•16 years ago
|
Flags: blocking1.9.1? → blocking1.9.1+
Updated•16 years ago
|
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 6•16 years ago
|
||
should this go to trunk and 1.9.1 now, or wait for more refinements or different approach?
Comment 7•15 years ago
|
||
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]
Assignee | ||
Comment 8•15 years ago
|
||
AFAIK it should go to 1.9.1.
Updated•15 years ago
|
Flags: in-testsuite-
Flags: in-litmus-
Comment 9•15 years ago
|
||
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a73c123918ba
Keywords: fixed1.9.1
Whiteboard: [needs 1.9.1 landing]
Comment 10•15 years ago
|
||
pushed awhile back http://hg.mozilla.org/mozilla-central/rev/97c230b44f4a 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!
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
Updated•13 years ago
|
Crash Signature: [@ nanojit::LIns::targetAddr() ]
You need to log in
before you can comment on or make changes to this bug.
Description
•