Christian Holler (:decoder) Reporter
	Description • 13 years ago

The following test asserts on mozilla-central 1962ca549264 with WIP1 patch from bug 716647 (options -m -n):


for ( var time = 0, year = 1969; year >= 0; year-- ) {}
var g = newGlobal('new-compartment');
g.debuggeeGlobal = this;
g.eval("(" + function () {
        dbg = new Debugger(debuggeeGlobal);
} + ")();");
eval("");

	Jason Orendorff [:jorendorff] Assignee
	Comment 1 • 13 years ago

Thanks. I'm not sure what to make of this. Shorter:

for (var i = 0; i < 100; i++) {}
var g = newGlobal('new-compartment');
g.debuggeeGlobal = this;
g.eval("dbg = new Debugger(debuggeeGlobal);");
print();

There are two compartments here: the main compartment, and g's compartment. When the Debugger is created, we turn on debug mode for the main compartment. There isn't even any JIT code on the stack, so there's nothing for mjit::ClearAllFrames to do.

JSCompartment::updateForDebugMode walks the heap and finds only 2 scripts.

Then we return from 'new Debugger()', and then from 'g.eval()', which is a cross-compartment call, to the main script.

At the JSOP_NAME opcode for 'print', we hit this:

#0  0x000000010028250e in CrashInJS () at jsutil.cpp:95
#1  0x000000010028259e in JS_Assert (s=0x10054817c "analysis->ranInference()", file=0x100547868 "/Users/jorendorff/dev/mi/js/src/jsinfer.cpp", ln=2263) at jsutil.cpp:115
#2  0x0000000100116fa0 in js::types::TypeCompartment::monitorBytecode (this=0x101049ae8, cx=0x100c151d0, script=0x100e07180, offset=94, returnOnly=true) at jsinfer.cpp:2263
#3  0x000000010010d748 in TypeConstraintCall::newType (this=0x100b85548, cx=0x100c151d0, source=0x100b85358, type={data = 4309700993}) at jsinfer.cpp:1169
#4  0x00000001000e16c4 in js::types::TypeCompartment::resolvePending (this=0x101049ae8, cx=0x100c151d0) at jsinferinlines.h:750
#5  0x00000001003f195d in js::types::TypeSet::addType (this=0x100c17860, cx=0x100c151d0, type={data = 4309700993}) at jsinferinlines.h:1038
#6  0x000000010011bbf8 in js::types::TypeMonitorResult (cx=0x100c151d0, script=0x100e07180, pc=0x100c17d08 "?", rval=@0x7fff5fbfe120) at jsinfer.cpp:5149
#7  0x000000010016650c in js::types::TypeScript::Monitor (cx=0x100c151d0, script=0x100e07180, pc=0x100c17d08 "?", rval=@0x7fff5fbfe120) at jsinferinlines.h:571
#8  0x00000001001523af in js::Interpret (cx=0x100c151d0, entryFrame=0x101800030, interpMode=js::JSINTERP_NORMAL) at jsinterp.cpp:3118

When TypeMonitorResult is called, script->analysis() at that point is non-null, script->types is non-null, but script->analysis()->ranInference() is false.

	Jason Orendorff [:jorendorff] Assignee
	Comment 2 • 13 years ago

bhackett pointed out that JSCompartment::updateForDebugMode throws away code and analysis, but not type constraints. There are two fixes:

1. Make all analysis independent of debug mode, so we don't have to throw away analysis when debug mode is turned on. This is the Right Thing and bhcakett may be able to pursue it as early as next week.

2. Just call JS_GC() from updateForDebugMode, that flushes everything.

I'm doing fix 2 for now. It works (locally). I'll mark this RESO FIXED when the updated patch in bug 716647; can't do it just this instant, but soon, certainly today.