286216 - tracing a for-in-loop in interactive mode crashes jsshell

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Philipp Vogt]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1

the following code crashes the jsshell.exe in _interactive-mode_ (in the current
cvs-version from the 15.03.05):

tracing(true);
var mytest = 3;
var dut = { 'x' : mytest };
var ob = [];
for (ob[0] in dut) {
	print(dut[ob[0]]);
}

After the last time forelem is called, it crashes on dumping the output on the
stack (sp[-4]). It calls jsopcode.c(2832) sn = js_GetSrcNote(script, pc); which
returns sn = 0. The fallback tries to convert in a string and fails.

IMPORTANT: if you put the example in a test.js-file and execute it via
jsshell.exe test.js then it runs fine!

Reproducible: Always

Steps to Reproduce:
1. start jsshell.exe
2. turn on tracing
3. enter for-in-loop
4. crash on print-stack-output

Actual Results:  
send bugs to microsoft :-)

Expected Results:  
printed the output of sp[-4] on the stack?

 	js32.dll!js_ValueToString(JSContext * cx=0x00322508, long v=4423624)  Line
2687 + 0x13	C
 	js32.dll!js_DecompileValueGenerator(JSContext * cx=0x00322508, int
spindex=-11, long v=4423624, JSString * fallback=0x00000000)  Line 2915 + 0x1b	C
 	js32.dll!js_Interpret(JSContext * cx=0x00322508, unsigned char *
pc=0x00437fb6, long * result=0x0012ee2c)  Line 5270 + 0x1f	C
 	js32.dll!js_Execute(JSContext * cx=0x00322508, JSObject * chain=0x003297a8,
JSScript * script=0x00437f80, JSStackFrame * down=0x00000000, unsigned int
flags=0, long * result=0x0012fecc)  Line 1523 + 0x13	C
>	js32.dll!JS_ExecuteScript(JSContext * cx=0x00322508, JSObject *
obj=0x003297a8, JSScript * script=0x00437f80, long * rval=0x0012fecc)  Line
3630 + 0x19	C

Comment 1

[Brendan Eich [:brendan]]

Thanks for finding this.  The change to match ECMA that introduced JSOP_ENUMELEM
modified JSOP_FORELEM to have a variable number of stack results (jsopcode.tbl,
the ndefs column).

There's no jsopcode.tbl encoding for this case, and it is not needed for the
code generation and other uses of ndefs, which work by analyzing code as if it
were straight-line, no branches or jumps (in general -- try/catch/finally
requires extra effort resetting the stack budget).

So having ndefs be 4 is fine, and we just need an ad-hoc adjustment in the
runtime tracing code in js_Interpret, because it sees all iterations, including
the last one where only 3 stack operands are pushed.

I checked in a fix just now.  Thanks for the bug and testcase!

/be

Comment 2

[Bob Clary [:bc] (inactive)]

Checking in regress-286216.js;
/cvsroot/mozilla/js/tests/js1_5/Regress/regress-286216.js,v  <--  regress-286216.js
initial revision: 1.1
done

Comment 3

[Bob Clary [:bc] (inactive)]

verified fixed.