Closed
Bug 453397
Opened 14 years ago
Closed 14 years ago
TM: fatal assert: script->main <= target && target < script->code + script->length, at jsopcode.cpp:5182
Categories
(Core :: JavaScript Engine, defect, P1)
Core
JavaScript Engine
Tracking
()
VERIFIED
FIXED
mozilla1.9.1b1
People
(Reporter: bzbarsky, Unassigned)
References
Details
(Keywords: verified1.9.1)
Attachments
(2 files, 2 obsolete files)
322 bytes,
text/plain
|
Details | |
8.37 KB,
patch
|
Details | Diff | Splinter Review |
BUILD: tracemonkey branch revision f4909cae663d STEPS TO REPRODUCE: run "js -j test.js" on the attached JS file. ACTUAL RESULTS: fatal assert with this stack: JS_Assert ReconstructPCStack js_ReconstructStackDepth js_ExecuteTree Assertion failure: script->main <= target && target < script->code + script->length, at jsopcode.cpp:5182 I ran into this while playing with the testcase in bug 451605, so this might be related to that issue. In any case, the behavior seems to definitely depend on having all the loops, and on having that one if statement, and on that if statement sometimes evaluating false and sometimes true. So if I change the 2 in that test to a 5 or make realStep smaller, the bug goes away. I've tried to reduce the number of iterations as much as I could. numRows and numCols can be increased to 5 (from 4) if desired; in that case the 2 can be changed to a 1, and realStep to something like 0.8. But with the loop sizes at 4, using 1 and 0.8 doesn't trigger the bug. In any case, the testcase seems to be about as small as I can make it.
Flags: blocking1.9.1?
![]() |
Reporter | |
Comment 1•14 years ago
|
||
Ok, somewhere between rev f4909cae663d and rev a2f22fccef27 I started hitting this bug every single time on the testcase for bug 451605.... I tried hg bisect to figure out when things broke, but so many of the intermediate changesets either don't build or crash in some totally different part of the code on the testcases that I didn't get far...
![]() |
Reporter | |
Comment 2•14 years ago
|
||
So I do hit the asserts about setting a bogus thisp that I added before I hit this bug. I just hit this bug before I hit the gc crash from the bogus thisp.
Updated•14 years ago
|
Priority: -- → P1
Target Milestone: --- → mozilla1.9.1b1
The control flow of this example is an outer, inner, and innermost nested tree. The inner has a call depth of 1, the others have a call depth of 0. What appears to be happening is that we're bailing out in the innermost tree as a BRANC_EXIT and not reconstructing the frames right because we don't process the exact guards that are chained together (i.e., we skip the inner nested guard with a calldepth of 1). Andreas has a patch in bug 454402 to fix this -- and in fact it seems to help, we get further in executing the program, but regress again with the same error when trying to extend the inner tree. Will report back when I find more.
Comment 4•14 years ago
|
||
Comment 5•14 years ago
|
||
Attachment #339542 -
Attachment is obsolete: true
Comment 6•14 years ago
|
||
Attachment #339543 -
Attachment is obsolete: true
Comment 7•14 years ago
|
||
Latest patch speeds up SS. Total score is now 1299 on my machine (improved by 70ms or so).
Pushed fix as changeset http://hg.mozilla.org/tracemonkey/rev/f657d39d36e8
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment 9•14 years ago
|
||
/cvsroot/mozilla/js/tests/js1_5/Regress/regress-453397.js,v <-- regress-453397.js initial revision: 1.1 http://hg.mozilla.org/mozilla-central/rev/aad88696e0f5
Flags: in-testsuite+
Flags: in-litmus-
Please see bug 456810 which still crashes with the same stack on trunk.
Hardware: PC → All
Version: unspecified → Trunk
Updated•14 years ago
|
Flags: blocking1.9.1? → blocking1.9.1+
Comment 11•14 years ago
|
||
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/f657d39d36e8
Keywords: fixed1.9.1
Comment 12•14 years ago
|
||
v 1.9.1, 1.9.2
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
You need to log in
before you can comment on or make changes to this bug.
Description
•