1345453 - Assertion failure: !cx->isExceptionPending(), at js/src/frontend/BytecodeCompiler.cpp:400 with Debugger

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision b7e42143bbbc (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-stdcxx-compat --disable-profiling --enable-debug --enable-optimize, run with --fuzzing-safe --ion-offthread-compile=off):

var g = newGlobal();
var lfCodeBuffer = `
var dbg = new Debugger(g);
dbg.onNewScript = function of (script, global) {};
g.eval("" + function f() {
  eval(\`
    $=function() { assertEq(obj.foo, 1); }
  \`);
});
`;
loadFile(lfCodeBuffer);
function loadFile(lfVarx) {
  oomTest(new Function(lfVarx));
}



Backtrace:

 received signal SIGSEGV, Segmentation fault.
0x0000000000a959ce in BytecodeCompiler::compileScript (this=this@entry=0x7fffffffa880, environment=environment@entry=..., sc=sc@entry=0x7fffffffa820) at js/src/frontend/BytecodeCompiler.cpp:400
#0  0x0000000000a959ce in BytecodeCompiler::compileScript (this=this@entry=0x7fffffffa880, environment=environment@entry=..., sc=sc@entry=0x7fffffffa820) at js/src/frontend/BytecodeCompiler.cpp:400
#1  0x0000000000a95ca5 in BytecodeCompiler::compileEvalScript (enclosingScope=..., environment=..., this=0x7fffffffa880) at js/src/frontend/BytecodeCompiler.cpp:417
#2  js::frontend::CompileEvalScript (cx=cx@entry=0x7ffff6948000, alloc=..., environment=environment@entry=..., enclosingScope=..., options=..., srcBuf=..., extraSct=0x0, sourceObjectOut=0x0) at js/src/frontend/BytecodeCompiler.cpp:617
#3  0x000000000056d1ee in EvalKernel (cx=cx@entry=0x7ffff6948000, v=..., evalType=evalType@entry=INDIRECT_EVAL, caller=..., env=..., pc=pc@entry=0x0, vp=...) at js/src/builtin/Eval.cpp:318
#4  0x000000000056d774 in js::IndirectEval (cx=0x7ffff6948000, argc=<optimized out>, vp=<optimized out>) at js/src/builtin/Eval.cpp:421
#5  0x0000000000540e30 in js::CallJSNative (cx=cx@entry=0x7ffff6948000, native=0x56d6b0 <js::IndirectEval(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:282
#6  0x000000000053663a in js::InternalCallOrConstruct (cx=cx@entry=0x7ffff6948000, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:448
#7  0x0000000000536a46 in InternalCall (cx=cx@entry=0x7ffff6948000, args=...) at js/src/vm/Interpreter.cpp:493
#8  0x0000000000536b9e in js::Call (cx=cx@entry=0x7ffff6948000, fval=..., fval@entry=..., thisv=..., args=..., rval=...) at js/src/vm/Interpreter.cpp:512
#9  0x0000000000a4c81c in js::Wrapper::call (this=this@entry=0x1e65e50 <js::CrossCompartmentWrapper::singleton>, cx=cx@entry=0x7ffff6948000, proxy=..., proxy@entry=..., args=...) at js/src/proxy/Wrapper.cpp:165
#10 0x0000000000a35fca in js::CrossCompartmentWrapper::call (this=0x1e65e50 <js::CrossCompartmentWrapper::singleton>, cx=0x7ffff6948000, wrapper=..., args=...) at js/src/proxy/CrossCompartmentWrapper.cpp:353
#11 0x0000000000a4453b in js::Proxy::call (cx=cx@entry=0x7ffff6948000, proxy=proxy@entry=..., args=...) at js/src/proxy/Proxy.cpp:464
#12 0x0000000000a44626 in js::proxy_Call (cx=0x7ffff6948000, argc=<optimized out>, vp=<optimized out>) at js/src/proxy/Proxy.cpp:716
#13 0x0000000000540e30 in js::CallJSNative (cx=cx@entry=0x7ffff6948000, native=0xa445b0 <js::proxy_Call(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:282
#14 0x000000000053695f in js::InternalCallOrConstruct (cx=cx@entry=0x7ffff6948000, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:436
#15 0x0000000000536a46 in InternalCall (cx=cx@entry=0x7ffff6948000, args=...) at js/src/vm/Interpreter.cpp:493
#16 0x0000000000536b6a in js::CallFromStack (cx=cx@entry=0x7ffff6948000, args=...) at js/src/vm/Interpreter.cpp:499
#17 0x000000000060a2e9 in js::jit::DoCallFallback (cx=0x7ffff6948000, frame=0x7fffffffc258, stub_=<optimized out>, argc=<optimized out>, vp=0x7fffffffc208, res=...) at js/src/jit/BaselineIC.cpp:2340
#18 0x000021810d8092e4 in ?? ()
[...]
#39 0xfffe7ffff468c120 in ?? ()
#40 0x0000000000a51d43 in js::CheckThreadLocal::check (this=0xfffe7ffff4702bb0) at js/src/threading/ProtectedData.cpp:47
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
rax	0x0	0
rbx	0x7fffffffa510	140737488332048
rcx	0x7ffff6c28a2d	140737333332525
rdx	0x0	0
rsi	0x7ffff6ef7770	140737336276848
rdi	0x7ffff6ef6540	140737336272192
rbp	0x7fffffffa810	140737488332816
rsp	0x7fffffffa4f0	140737488332016
r8	0x7ffff6ef7770	140737336276848
r9	0x7ffff7fe4740	140737354024768
r10	0x58	88
r11	0x7ffff6b9f750	140737332770640
r12	0x7fffffffa820	140737488332832
r13	0x7fffffffb8a0	140737488337056
r14	0x7fffffffae78	140737488334456
r15	0x7fffffffa880	140737488332928
rip	0xa959ce <BytecodeCompiler::compileScript(JS::Handle<JSObject*>, js::frontend::SharedContext*)+1342>
=> 0xa959ce <BytecodeCompiler::compileScript(JS::Handle<JSObject*>, js::frontend::SharedContext*)+1342>:	movl   $0x0,0x0
   0xa959d9 <BytecodeCompiler::compileScript(JS::Handle<JSObject*>, js::frontend::SharedContext*)+1353>:	ud2

Comment 1

[Fuzzing Team]

JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/51901165b259
user:        Emanuel Hoogeveen
date:        Mon Jan 30 14:57:53 2017 +0100
summary:     Bug 1332594 - Part 2: Check AssemblerBuffer for corruption during realloc. r=jandem

This iteration took 261.317 seconds to run.

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Emanuel, is bug 1332594 a likely regressor? (Doesn't seem likely, does it?)

Comment 3

[Emanuel Hoogeveen [:ehoogeveen]]

I very much doubt this was *caused* by bug 1332594, but it may have revealed a preexisting bug. It also found a missing OOM check in TraceLogger that prevented it from landing for a while, and this looks like something similar. Nicolas, maybe you could have a look?

Comment 4

[Nicolas B. Pierron [:nbp]]

The problem is that we report an OOM under js::Debugger::slowPathOnNewScript, which ignores the returned value of the dispatchHook function, thus resume as a successful execution under BytecodeCompiler::compileScript

Shu might know better what is the expected behaviour, to either propagate this Debugger error, or to clean-up the pending exception when we return from the dispatchHook.

(rr) bt
#0  JSContext::setPendingException at jscntxtinlines.h:432
#1  0x000000000042ea0f in js::ReportOutOfMemory at jscntxt.cpp:351
#2  0x0000000000871b89 in js::TempAllocPolicy::checkSimulatedOOM at jsalloc.h:129
#3  mozilla::Vector<…>::maybeCheckSimulatedOOM) at mozilla/Vector.h:1080
#4  mozilla::Vector<…>::append<JS::Value> at mozilla/Vector.h:1389
#5  0x0000000000aa3de4 in JS::GCVector<…>::append<JS::Value> at …/GCVector.h:79
#6  js::MutableWrappedPtrOperations<JS::GCVector<…>>::append<JS::Value> at …/GCVector.h:213
#7  js::Debugger::dispatchHook<js::Debugger::slowPathOnNewScript at vm/Debugger.cpp:1914
#8  js::Debugger::slowPathOnNewScript at vm/Debugger.cpp:1948
#9  0x0000000000a40def in js::Debugger::onNewScript at vm/Debugger.h:1759
#10 js::frontend::BytecodeEmitter::tellDebuggerAboutCompiledScript at frontend/BytecodeEmitter.cpp:3571
#11 0x0000000000a5fb8a in js::frontend::BytecodeEmitter::emitScript at frontend/BytecodeEmitter.cpp:4926
#12 0x0000000000a5ffe7 in BytecodeCompiler::compileScript at frontend/BytecodeCompiler.cpp:380
#13 0x0000000000a603bb in BytecodeCompiler::compileEvalScript at frontend/BytecodeCompiler.cpp:417
#14 0x0000000000a604a4 in js::frontend::CompileEvalScript at frontend/BytecodeCompiler.cpp:617

Comment 5

[Shu-yu Guo [:shu]]

nbp, thanks for debugging this. We just need to clear the pending exception here, since the OOM isn't handlable at the callsite of onNewScript in the frontend.

Comment 6

[Shu-yu Guo [:shu]]

Attachment: Clear pending exceptions in unhandlable OOM cases in onNewScript and onNewWasmInstance in Debugger.

I don't know of a way to meaningfully land a test for this. When not crashing,
the attached fuzz test is way too slow (I ended up ^C-ing it).

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/d98072a1b492
Clear pending exceptions in unhandlable OOM cases in onNewScript and onNewWasmInstance in Debugger. (r=jimb)

Comment 8

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/d98072a1b492

Comment 9

[Ryan VanderMeulen [:RyanVM]]

AFAICT, this goes back as far as Fx50. Should we consider backporting this to any release branches or can it ride the trains?

Comment 10

[Shu-yu Guo [:shu]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #9)
> AFAICT, this goes back as far as Fx50. Should we consider backporting this
> to any release branches or can it ride the trains?

It should ride the trains.