Closed Bug 589093 Opened 14 years ago Closed 14 years ago

TM: Crash [@ js::Interpret] or "Assertion failure: script->main <= target && target < script->code + script->length,"

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME
Tracking Status
blocking2.0 --- betaN+
status1.9.2 --- unaffected
status1.9.1 --- unaffected

People

(Reporter: gkw, Assigned: gal)

References

Details

(4 keywords, Whiteboard: [ccbr][sg:critical?])

Crash Data

x = (w for (x in [])) for (w in [0, 0, 0, 0]) { (function() { [c for (z in x)] })() } crashes js opt shell on TM changeset b22e82ce2364 with -j at js::Interpret and asserts js debug shell at Assertion failure: script->main <= target && target < script->code + script->length, at ../jsopcode.cpp:5501 s-s because the opt shell seems to be accessing 0x8c, a scary address. Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 0x0005d5ae in js::Interpret () (gdb) bt #0 0x0005d5ae in js::Interpret () #1 0x0006ccf4 in js::Execute () #2 0x00013d48 in JS_ExecuteScript () #3 0x0000580c in Process () #4 0x00009427 in shell () #5 0x00009947 in main () (gdb) x/i $eip 0x5d5ae <_ZN2js9InterpretEP9JSContext+10286>: cmp %eax,0x4(%edx) (gdb) x/b $eax 0x1e1a40 <js_IteratorClass>: 0x8c Debug backtrace: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 0x00163384 in JS_Assert (s=0x22b3e0 "script->main <= target && target < script->code + script->length", file=0x22b174 "../jsopcode.cpp", ln=5501) at ../jsutil.cpp:80 80 *((int *) NULL) = 0; /* To continue from here in GDB: "return" then "continue". */ (gdb) bt #0 0x00163384 in JS_Assert (s=0x22b3e0 "script->main <= target && target < script->code + script->length", file=0x22b174 "../jsopcode.cpp", ln=5501) at ../jsutil.cpp:80 #1 0x000e6f4e in ReconstructPCStack (cx=0x50a3b0, script=0x50d310, target=0x50d607 ":", pcstack=0x0) at ../jsopcode.cpp:5501 #2 0x000e7221 in js_ReconstructStackDepth (cx=0x50a3b0, script=0x50d310, pc=0x50d607 ":") at ../jsopcode.cpp:5333 #3 0x0019215b in js::SynthesizeFrame (cx=0x50a3b0, fi=@0x850244, callee=0x706af8) at ../jstracer.cpp:5667 #4 0x00192ea3 in js::LeaveTree (tm=0x823a2c, state=@0xbfffe538, lr=0x8593fc) at ../jstracer.cpp:7003 #5 0x0019433e in js::ExecuteTree (cx=0x50a3b0, f=0x850044, inlineCallCount=@0xbfffedb4, innermostNestedGuardp=0xbfffe614, lrp=0xbfffe618) at ../jstracer.cpp:6764 #6 0x001a5c8a in js::MonitorLoopEdge (cx=0x50a3b0, inlineCallCount=@0xbfffedb4, reason=js::Record_Branch) at ../jstracer.cpp:7265 #7 0x00096ca2 in js::Interpret (cx=0x50a3b0) at ../jsinterp.cpp:2892 #8 0x000b9eb4 in js::Execute (cx=0x50a3b0, chain=0x702000, script=0x50d590, down=0x0, flags=0, result=0xbffff730) at jsinterp.cpp:883 #9 0x000168ea in JS_ExecuteScript (cx=0x50a3b0, obj=0x702000, script=0x50d590, rval=0xbffff730) at ../jsapi.cpp:4744 #10 0x0000c181 in Process (cx=0x50a3b0, obj=0x702000, filename=0x0, forceTTY=0) at ../../shell/js.cpp:534 #11 0x0000cb59 in ProcessArgs (cx=0x50a3b0, obj=0x702000, argv=0xbffff8fc, argc=1) at ../../shell/js.cpp:855 #12 0x0000cc72 in shell (cx=0x50a3b0, argc=1, argv=0xbffff8fc, envp=0xbffff904) at ../../shell/js.cpp:5059 #13 0x0000cd96 in main (argc=1, argv=0xbffff8fc, envp=0xbffff904) at ../../shell/js.cpp:5146
autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: 41875:128e76615878 user: Andreas Gal date: Wed May 12 13:12:53 2010 -0700 summary: nit fix for bug 558754 and remove bogus spot-fix that didn't have review (r=brendan) (This should probably be double-checked..)
blocking2.0: --- → ?
(In reply to comment #1) > (This should probably be double-checked..) I'm quite sure that's the correct changeset..
Is this always near null? The asserted condition sounds scary, unless there's some path where target is always ok UNLESS is it null. Assuming the worst for now.
Whiteboard: [ccbr] → [ccbr][sg:critical?]
blocking2.0: ? → betaN+
Assignee: general → gal
WFM with TM tip. Debug shell macosx 64-bit. Gary, can you verify.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Would it be worth adding this testcase to the regression test suite anyway?
Flags: in-testsuite?
Group: core-security
Crash Signature: [@ js::Interpret]
Automatically extracted testcase for this bug was committed: https://hg.mozilla.org/mozilla-central/rev/efaf8960a929
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.