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)

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: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.