Closed Bug 355660 Opened 18 years ago Closed 16 years ago

"Assertion failure: j < n" with [,,] as initial value in a "for [k,v] in" loop

Categories

(Core :: JavaScript Engine, defect)

PowerPC
macOS
defect
Not set
critical

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)
Brian, can I interest you in this bug? Destructuring for-in loop decompilation, what's not to love? ;-) /be
Assignee: general → crowder
Status: NEW → ASSIGNED
What exactly is this assertion asserting?
(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
> 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| ?
The assertion here has moved: js> for(var [[[]], x] = [,,] in {}) { } Assertion failure: *pc == JSOP_POPN, at jsopcode.c:2589
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
Igor, see last comment. /be
> What is v if its value is |0x8000001| ? JSVAL_VOID of course. /be
(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.
The testcase presented in comment #6 is actually a different bug, and should be split out. Igor will probably be interested in it...
Split out as bug 387994.
js> let ([[], [x]] = [1,,]) { } Assertion failure: j < n, at jsopcode.cpp:1246
WFM, TM branch.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.