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)
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•18 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•18 years ago
|
||
The assertion here has moved:
js> for(var [[[]], x] = [,,] in {}) { }
Assertion failure: *pc == JSOP_POPN, at jsopcode.c:2589
Reporter | ||
Comment 6•18 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•18 years ago
|
||
Igor, see last comment.
/be
Comment 8•18 years ago
|
||
> What is v if its value is |0x8000001| ?
JSVAL_VOID of course.
/be
Comment 9•18 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•18 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•18 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•16 years ago
|
||
WFM, TM branch.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
![]() |
||
Updated•16 years ago
|
Flags: in-testsuite?
You need to log in
before you can comment on or make changes to this bug.
Description
•