720115 - Crash [@ js::TokenStream::TokenBuf::getRawChar] with setThrowHook

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

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

Comment 1

[Jason Orendorff [:jorendorff]]

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.

Comment 2

[Jason Orendorff [:jorendorff]]

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.

Comment 3

[Christian Holler (:decoder)]

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

Comment 4

[Jan de Mooij [:jandem]]

(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.