1205639 - Assertion failure: size() - offset.offset() == ToggledCallSize(nullptr), at js/src/jit/x64/Assembler-x64.h:780 with OOM

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 9ed17db42e3e (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug, run with --ion-eager):

var g = newGlobal();
var dbg = Debugger(g);
dbg.onEnterFrame = function(__FRST) {};
oomAfterAllocations(50);
assertEq(g.eval("'pass';"), "pass");


Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x00000000008d447c in toggledCall (enabled=<optimized out>, target=0x7ffff3f55940, this=0x7fffffffb698) at js/src/jit/x64/Assembler-x64.h:780
#0  0x00000000008d447c in toggledCall (enabled=<optimized out>, target=0x7ffff3f55940, this=0x7fffffffb698) at js/src/jit/x64/Assembler-x64.h:780
#1  js::jit::BaselineCompiler::emitDebugTrap (this=this@entry=0x7fffffffb680) at js/src/jit/BaselineCompiler.cpp:796
#2  0x00000000008fe350 in js::jit::BaselineCompiler::emitBody (this=this@entry=0x7fffffffb680) at js/src/jit/BaselineCompiler.cpp:968
#3  0x0000000000911e7c in js::jit::BaselineCompiler::compile (this=this@entry=0x7fffffffb680) at js/src/jit/BaselineCompiler.cpp:102
#4  0x00000000009131cd in js::jit::BaselineCompile (cx=cx@entry=0x7ffff6906800, script=0x7ffff3f83160, forceDebugInstrumentation=<optimized out>) at js/src/jit/BaselineJIT.cpp:264
#5  0x0000000000913939 in CanEnterBaselineJIT (cx=cx@entry=0x7ffff6906800, script=..., script@entry=..., osrFrame=osrFrame@entry=0x0) at js/src/jit/BaselineJIT.cpp:303
#6  0x0000000000913c41 in js::jit::CanEnterBaselineMethod (cx=cx@entry=0x7ffff6906800, state=...) at js/src/jit/BaselineJIT.cpp:371
#7  0x00000000009c4bfa in js::jit::CanEnter (cx=cx@entry=0x7ffff6906800, state=...) at js/src/jit/Ion.cpp:2438
#8  0x00000000006b79fd in js::RunScript (cx=cx@entry=0x7ffff6906800, state=...) at js/src/vm/Interpreter.cpp:680
#9  0x00000000006c2088 in js::ExecuteKernel (cx=cx@entry=0x7ffff6906800, script=..., script@entry=..., scopeChainArg=..., thisv=..., newTargetValue=..., type=type@entry=js::EXECUTE_INDIRECT_EVAL, evalInFrame=evalInFrame@entry=..., result=0x7fffffffcee8) at js/src/vm/Interpreter.cpp:978
#10 0x00000000005b7eed in EvalKernel (cx=cx@entry=0x7ffff6906800, args=..., evalType=evalType@entry=INDIRECT_EVAL, caller=..., scopeobj=..., scopeobj@entry=..., pc=pc@entry=0x0) at js/src/builtin/Eval.cpp:353
#11 0x00000000005b8715 in js::IndirectEval (cx=0x7ffff6906800, argc=<optimized out>, vp=<optimized out>) at js/src/builtin/Eval.cpp:457
#12 0x00000000006c7372 in js::CallJSNative (cx=0x7ffff6906800, native=0x5b8670 <js::IndirectEval(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:235
#13 0x00000000006b8120 in js::Invoke (cx=cx@entry=0x7ffff6906800, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:763
#14 0x00000000006ba0ad in js::Invoke (cx=cx@entry=0x7ffff6906800, thisv=..., fval=..., argc=<optimized out>, argv=0x7fffffffd3a8, rval=...) at js/src/vm/Interpreter.cpp:818
#15 0x0000000000bf31f4 in js::DirectProxyHandler::call (this=this@entry=0x1b70f80 <js::CrossCompartmentWrapper::singleton>, cx=cx@entry=0x7ffff6906800, proxy=..., proxy@entry=..., args=...) at js/src/proxy/DirectProxyHandler.cpp:77
#16 0x0000000000bfa942 in js::CrossCompartmentWrapper::call (this=0x1b70f80 <js::CrossCompartmentWrapper::singleton>, cx=0x7ffff6906800, wrapper=..., args=...) at js/src/proxy/CrossCompartmentWrapper.cpp:289
#17 0x0000000000c0a8a2 in js::Proxy::call (cx=cx@entry=0x7ffff6906800, proxy=proxy@entry=..., args=...) at js/src/proxy/Proxy.cpp:412
#18 0x0000000000c0a95e in js::proxy_Call (cx=0x7ffff6906800, argc=<optimized out>, vp=<optimized out>) at js/src/proxy/Proxy.cpp:718
#19 0x00000000006c7372 in js::CallJSNative (cx=0x7ffff6906800, native=0xc0a8c0 <js::proxy_Call(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:235
#20 0x00000000006b83d0 in js::Invoke (cx=cx@entry=0x7ffff6906800, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:751
#21 0x00000000006ba0ad in js::Invoke (cx=cx@entry=0x7ffff6906800, thisv=..., fval=..., argc=argc@entry=1, argv=argv@entry=0x7fffffffd848, rval=..., rval@entry=...) at js/src/vm/Interpreter.cpp:818
#22 0x0000000000910c8a in js::jit::DoCallFallback (cx=0x7ffff6906800, frame=0x7fffffffd898, stub_=<optimized out>, argc=<optimized out>, vp=0x7fffffffd838, res=...) at js/src/jit/BaselineIC.cpp:8899
#23 0x00007ffff7e54f9f in ?? ()
[...]
#46 0xfffc7ffff3f6cc40 in ?? ()
#47 0x00000000009c8b5d in allocateInfallible (bytes=24, this=<optimized out>) at js/src/jit/JitAllocPolicy.h:40
#48 operator new (alloc=..., nbytes=24) at js/src/jit/JitAllocPolicy.h:149
#49 js::jit::IonBuilder::bytecodeSite (this=0xfffc7ffff3f5f180, pc=0x8 <error: Cannot access memory at address 0x8>) at js/src/jit/IonBuilder.h:1095
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
rax	0x0	0
rbx	0x1	1
rcx	0x7ffff6ca588d	140737333844109
rdx	0x0	0
rsi	0x7ffff6f7a9d0	140737336814032
rdi	0x7ffff6f791c0	140737336807872
rbp	0x7fffffffb1f0	140737488335344
rsp	0x7fffffffb180	140737488335232
r8	0x7ffff7fe8780	140737354041216
r9	0x6372732f736a2f6c	7165916604736876396
r10	0x7fffffffaf40	140737488334656
r11	0x7ffff6c27ee0	140737333329632
r12	0x7fffffffb1b0	140737488335280
r13	0x7f2	2034
r14	0x7fffffffb968	140737488337256
r15	0x7fffffffb680	140737488336512
rip	0x8d447c <js::jit::BaselineCompiler::emitDebugTrap()+1228>
=> 0x8d447c <js::jit::BaselineCompiler::emitDebugTrap()+1228>:	movl   $0x30c,0x0
   0x8d4487 <js::jit::BaselineCompiler::emitDebugTrap()+1239>:	callq  0x49b340 <abort()>


Not marking s-s because it seems to require the Debugger.

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/a2f5fa870c8a
user:        Boris Zbarsky
date:        Fri Jul 04 01:24:54 2014 -0400
summary:     Bug 966452 part 1.  Refactor the js_ReportUncaughtException to produce a (message, JSErrorReport*) pair before reporting.  r=waldo and including the fix for bug 1034616 to fix JS tests to deal with this, r=jorendorff.  r=terrence on the AutoStableStringChars bits

This iteration took 0.840 seconds to run.

Comment 2

[Fuzzing Team]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 05a7ee49d40a).

Comment 3

[Nicolas B. Pierron [:nbp]]

I tried to checkout the specific revision mentioned in comment 0, I was able to reproduce a unhandlable oom, which does not seems to match the baseline issue that we see below.

Assertion failure: [unhandlable oom] Could not add to pending GC helpers list, at /home/nicolas/mozilla/oom-repo/js/src/jscntxt.cpp:1220

Comment 4

[Christian Holler (:decoder)]

I was able to make this work again on revision 67adec79eb8a, using this modified test (Build options and runtime options are the same as in comment 0):

var g = newGlobal();
var dbg = Debugger(g);
dbg.onEnterFrame = function(__FRST) {};
oomAfterAllocations(456);
assertEq(g.eval("'pass';"), "pass");

Comment 5

[Nicolas B. Pierron [:nbp]]

Attachment: Prevent assertions in MacroAssembler oom cases.

The problem being that the assertion is too greedy, and when the assembler
oom after recording the masm.call/masm.cmp_eax the offset is wrong and the
assertion triggers.

(with a MOZ_ASSERT_IF instead of MOZ_ASSERT)

Comment 6

[Jan de Mooij [:jandem]]

Comment on attachment 8670215 [details] [diff] [review]
Prevent assertions in MacroAssembler oom cases.

Review of attachment 8670215 [details] [diff] [review]:
-----------------------------------------------------------------

Actually there's a similar assert in toggledCall in Assembler-x86.h. Can you also check the other archs?

Comment 7

[Nicolas B. Pierron [:nbp]]

(In reply to Jan de Mooij [:jandem] from comment #6)
> Actually there's a similar assert in toggledCall in Assembler-x86.h. Can you
> also check the other archs?

Yes, and also in mips32, I made the patch in the oom branch, I will merge the patches and land them.

Comment 8

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/28e36be3f00b

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/28e36be3f00b