The following test crashes on mozilla-central 7edc6c4cf83d with WIP2 patch from bug 716647 (options -m -n -a): evaluate("\ const libdir = '/srv/repos/mozilla-central/js/src/jit-test/lib/';\ var g = newGlobal('new-compartment');\ g.debuggeeGlobal = this;\ g.eval('(' + function () {\ var dbg = Debugger(debuggeeGlobal);\ dbg.onDebuggerStatement = function (frame) {\ if (frame.callee === null) { }\ };\ } + ')();');\ function main() {\ try { } catch(e) { }\ }\ setThrowHook(\"'success'\");\ "); evaluate("\ var g = newGlobal('new-compartment');\ Debugger(g).onDebuggerStatement = function (frame) {};\ assertEq(f.live, false);\ "); Crash backtrace: Program received signal SIGSEGV, Segmentation fault. 0x082a313b in js::TokenStream::TokenBuf::getRawChar (this=0xffffa61c) at ../frontend/TokenStream.h:714 714 return *ptr++; /* this will NULL-crash if poisoned */ (gdb) bt #0 0x082a313b in js::TokenStream::TokenBuf::getRawChar (this=0xffffa61c) at ../frontend/TokenStream.h:714 #1 0x082a00c7 in js::TokenStream::getTokenInternal (this=0xffffa584) at /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/frontend/TokenStream.cpp:1424 #2 0x082569eb in js::TokenStream::peekToken (this=0xffffa584) at ../frontend/TokenStream.h:611 #3 0x08256a3a in js::TokenStream::peekToken (this=0xffffa584, withFlags=8) at ../frontend/TokenStream.h:618 #4 0x082555dd in js::frontend::CompileScript (cx=0x8566570, scopeChain=0xf7703040, callerFrame=0xf79b8088, principals=0x0, originPrincipals=0x0, tcflags=1073750016, chars=0xdadadada, length=229485997, filename=0x856b061 "@evaluate", lineno=0, version=JSVERSION_ECMA_5, source=0x0, staticLevel=16) at /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/frontend/BytecodeCompiler.cpp:272 #5 0x0823dca8 in js::EvaluateInEnv (cx=0x8566570, env=0xf7703040, fp=0xf79b8088, chars=0xdadadada, length=229485997, filename=0x856b061 "@evaluate", lineno=0, rval=0xffffb038) at /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/vm/Debugger.cpp:2799 #6 0x080cf24d in JS_EvaluateUCInStackFrame (cx=0x8566570, fpArg=0xf79b8088, chars=0xdadadada, length=229485997, filename=0x856b061 "@evaluate", lineno=0, rval=0xffffb038) at /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/jsdbgapi.cpp:765 #7 0x0804f5e2 in TrapHandler (cx=0x8566570, pc=0x856a93a "\232", rval=0xffffb038, closure=...) at /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/shell/js.cpp:1673 #8 0x0804f89b in DebuggerAndThrowHandler (cx=0x8566570, script=0xf77064b8, pc=0x856a93a "\232", rval=0xffffb038, closure=0xf7813d20) at /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/shell/js.cpp:1728 #9 0x0814705f in js::Interpret (cx=0x8566570, entryFrame=0xf79b8088, interpMode=js::JSINTERP_NORMAL) at /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/jsinterp.cpp:4760 #10 0x082b0c92 in js::mjit::EnterMethodJIT (cx=0x8566570, fp=0xf79b8088, code=0x414d68, stackLimit=0xf7d98000, partial=false) at /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/methodjit/MethodJIT.cpp:1079 [ ... more frames here due to evaluate() ] (gdb) x /2i $pc => 0x82a313b <js::TokenStream::TokenBuf::getRawChar()+9>: movzwl (%eax),%edx 0x82a313e <js::TokenStream::TokenBuf::getRawChar()+12>: lea 0x2(%eax),%ecx (gdb) info register eax edx eax 0xdadadada -623191334 edx 0xdadadada -623191334 Jason, I think this is exactly one of the problems you were looking for. Without the patch I get: "uncaught exception: Error: can't start debugging: a debuggee script is on the stack" which sounds related to me :D

Thanks for finding this. Sorry to disappoint, but it's not related to bug 716647. This simplified example crashes for me with -d: evaluate("setThrowHook(\"'success'\");"); gc(); gc(); throw 0; The bug is simply that setThrowHook puts a JSString pointer someplace that's never marked during GC.

This is a bug in the shell, not a bug in the engine and certainly not a bug with JSD2. I see two nice ways to fix it: - add a reserved slot on the global and use that instead of the "closure" argument to JS_SetThrowHook to store the string - delete setThrowHook and one egregious hack: - conservatively scan the runtime-wide debug hooks during GC I can't take this bug right now. I suggest not fuzzing with setThrowHook until it's fixed.

JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.

(In reply to Jason Orendorff [:jorendorff] from comment #1) > evaluate("setThrowHook(\"'success'\");"); > gc(); > gc(); > throw 0; > > The bug is simply that setThrowHook puts a JSString pointer someplace that's > never marked during GC. setThrowHook is long gone. Let's close this.