Closed
Bug 355660
Opened 18 years ago
Closed 15 years ago
"Assertion failure: j < n" with [,,] as initial value in a "for [k,v] in" loop
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: jruderman, Assigned: crowderbt)
Details
(Keywords: crash, testcase)
js> for(var [[[]], x] = [,,] in {}) { } Assertion failure: j < n, at jsopcode.c:1133 (split from bug 355049 comment 1)
Comment 1•18 years ago
|
||
Brian, can I interest you in this bug? Destructuring for-in loop decompilation, what's not to love? ;-) /be
Assignee | ||
Updated•18 years ago
|
Assignee: general → crowder
Assignee | ||
Updated•18 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 2•18 years ago
|
||
What exactly is this assertion asserting?
Comment 3•18 years ago
|
||
(In reply to comment #2) > What exactly is this assertion asserting? That the block atom index j was not found in the n atoms mapped for the script being decompiled. This means that group assignment in the left-hand side of 'in' in a 'for/in' loop is not handled by the decompiler when called on a faulting pc. Note that it is handled when the entire script is decompiled: js> void(s = Script('for(var [[[]], x] = [,,] in {}) { }')) js> dis(s) main: 00000: push 00001: push 00002: getlocal 0 00005: dup 00006: zero 00007: getelem 00008: dup 00009: pop 00010: pop 00011: pop 00012: getlocal 1 00015: bindname "x" 00018: qnamepart "x" 00021: enumelem 00022: setsp 0 00025: startiter 00026: name "Object" 00029: pushobj 00030: newinit 00031: endinit 00032: foreachkeyval 00033: forelem 00034: ifeq 61 (27) 00037: dup 00038: zero 00039: getelem 00040: dup 00041: zero 00042: getelem 00043: dup 00044: pop 00045: pop 00046: pop 00047: dup 00048: one 00049: getelem 00050: bindname "x" 00053: qnamepart "x" 00056: enumelem 00057: pop 00058: goto 33 (-25) 00061: enditer 00062: stop Source notes: 0: 2 [ 2] pcdelta offset 0 2: 21 [ 19] xdelta 3: 21 [ 0] pcbase offset 6 5: 34 [ 13] xdelta 6: 34 [ 0] while offset 24 8: 37 [ 3] decl offset 0 10: 56 [ 19] xdelta 11: 56 [ 0] pcbase offset 6 js> s var [[[]], x] = [, , ]; for ([[[]], x] in {}) { } The last input line, s, is successfully evaluated to the Script object and then decompiled. More in a bit. /be
Assignee | ||
Comment 4•17 years ago
|
||
> More in a bit.
I wait with bated breath. I came back today to take another quick stab at this bug, and I'm pretty sure I'm missing something obvious.
Here's what the call-stack looks like during this assertion:
#0 JS_Assert (s=0xf509c "j < n", file=0xf4e7c "jsopcode.c", ln=1133) at jsutil.c:63
#1 0x0008bf88 in GetLocal (ss=0xbfffde94, i=0) at jsopcode.c:1133
#2 0x0009097c in Decompile (ss=0xbfffde94, pc=0x503382 "?", nb=3) at jsopcode.c:2432
#3 0x00098146 in js_DecompileCode (jp=0x5031f0, script=0x503350, pc=0x503382 "?", len=3, pcdepth=2) at jsopcode.c:4203
#4 0x00099888 in js_DecompileValueGenerator (cx=0x500180, spindex=1, v=-2147483647, fallback=0x0) at jsopcode.c:4759
#5 0x00088479 in js_ValueToNonNullObject (cx=0x500180, v=-2147483647) at jsobj.c:4555
#6 0x00067fec in js_Interpret (cx=0x500180, pc=0x503387 "7\fQQQ?", result=0xbfffe88c) at jsinterp.c:3733
#7 0x00058e2f in js_Execute (cx=0x500180, chain=0x1804ec0, script=0x503350, down=0x0, flags=0, result=0xbffff974) at jsinterp.c:1654
#8 0x00019e83 in JS_ExecuteScript (cx=0x500180, obj=0x1804ec0, script=0x503350, rval=0xbffff974) at jsapi.c:4193
#9 0x00001e12 in Process (cx=0x500180, obj=0x1804ec0, filename=0x0, forceTTY=0) at js.c:268
#10 0x0000277f in ProcessArgs (cx=0x500180, obj=0x1804ec0, argv=0xbffffaf0, argc=0) at js.c:489
#11 0x000073e1 in main (argc=0, argv=0xbffffaf0, envp=0xbffffaf4) at js.c:3167
What is v if its value is |0x8000001| ?
Assignee | ||
Comment 5•17 years ago
|
||
The assertion here has moved: js> for(var [[[]], x] = [,,] in {}) { } Assertion failure: *pc == JSOP_POPN, at jsopcode.c:2589
Reporter | ||
Comment 6•17 years ago
|
||
With the patch in bug 385729 ("Separated table to store script objects"), I get another assertion for some testcases: js> (function() { [, ({ x: x })] = [, , ] })() Assertion failure: script->objectsOffset != 0, at jsopcode.c:1265
Comment 7•17 years ago
|
||
Igor, see last comment. /be
Comment 8•17 years ago
|
||
> What is v if its value is |0x8000001| ?
JSVAL_VOID of course.
/be
Comment 9•17 years ago
|
||
(In reply to comment #6) > With the patch in bug 385729 ("Separated table to store script objects"), I get > another assertion for some testcases: > > js> (function() { [, ({ x: x })] = [, , ] })() > Assertion failure: script->objectsOffset != 0, at jsopcode.c:1265 > The bytecode for function f() { [, ({ x: x })] = [, , ] } is: js> dis(f) dis(f) main: 00000: push 00001: push 00002: getlocal 0 00005: pop 00006: getlocal 1 00009: dup 00010: getprop "x" 00013: bindname "x" 00016: qnamepart "x" 00019: enumelem 00020: pop 00021: popn 2 00024: stop Source notes: 0: 2 [ 2] pcdelta offset 3 2: 19 [ 17] xdelta 3: 19 [ 0] pcbase offset 6 With the patch from bug bug 385729 ("Separated table to store script objects") the assertion happens at the line: /* * We must be called from js_DecompileValueGenerator (via Decompile) when * dereferencing a local that's undefined or null. Search script->objects * for the block containing this local by its stack index, i. */ cx = ss->sprinter.context; script = ss->printer->script; LOCAL_ASSERT(script->objectsOffset != 0); That is, there is no object table to look for local blocks.
Assignee | ||
Comment 10•17 years ago
|
||
The testcase presented in comment #6 is actually a different bug, and should be split out. Igor will probably be interested in it...
Reporter | ||
Comment 11•17 years ago
|
||
Split out as bug 387994.
Reporter | ||
Comment 12•16 years ago
|
||
js> let ([[], [x]] = [1,,]) { } Assertion failure: j < n, at jsopcode.cpp:1246
Reporter | ||
Comment 13•15 years ago
|
||
WFM, TM branch.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Updated•15 years ago
|
Flags: in-testsuite?
You need to log in
before you can comment on or make changes to this bug.
Description
•