Closed Bug 1692861 Opened 3 years ago Closed 3 years ago

Assertion failure: !builder_->inlineCallInfo(), at jit/WarpCacheIRTranspiler.cpp:4210

Categories

(Core :: JavaScript Engine: JIT, defect)

x86_64
Linux
defect

Tracking

()

VERIFIED FIXED
87 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox86 --- unaffected
firefox87 --- verified

People

(Reporter: decoder, Assigned: iain)

References

(Regression)

Details

(Keywords: assertion, regression, testcase, Whiteboard: [bugmon:update,bisected,confirmed])

Attachments

(2 files)

The following testcase crashes on mozilla-central revision 20210214-0abd3454600d (debug build, run with --fuzzing-safe --cpu-count=2 --ion-offthread-compile=off):

function foo(t, g) {
  return bar(arguments);
}
function bar(x30) {
  return foo.apply({}, x30) 
}
foo(1,2);

Backtrace:

received signal SIGSEGV, Segmentation fault.
0x000055555791bc1f in WarpCacheIRTranspiler::emitFunApplyArgsObj(js::jit::WrappedFunction*, js::jit::CallFlags) ()
#0  0x000055555791bc1f in WarpCacheIRTranspiler::emitFunApplyArgsObj(js::jit::WrappedFunction*, js::jit::CallFlags) ()
#1  0x00005555578f4f2d in WarpCacheIRTranspiler::emitCallScriptedFunction(js::jit::CacheIRReader&) ()
#2  0x00005555578f0133 in WarpCacheIRTranspiler::transpile(std::initializer_list<js::jit::MDefinition*>) ()
#3  0x00005555578ea01f in js::jit::TranspileCacheIRToMIR(js::jit::WarpBuilder*, js::BytecodeLocation, js::jit::WarpCacheIR const*, std::initializer_list<js::jit::MDefinition*>, js::jit::CallInfo*) ()
#4  0x00005555578ea646 in js::jit::WarpBuilder::buildCallOp(js::BytecodeLocation) ()
#5  0x00005555578d0e5e in js::jit::WarpBuilder::buildBody() ()
#6  0x00005555578eb5a5 in js::jit::WarpBuilder::buildInlinedCall(js::BytecodeLocation, js::jit::WarpInlinedCall const*, js::jit::CallInfo&) ()
#7  0x00005555578ea565 in js::jit::WarpBuilder::buildCallOp(js::BytecodeLocation) ()
#8  0x00005555578d0e5e in js::jit::WarpBuilder::buildBody() ()
#9  0x00005555578d039d in js::jit::WarpBuilder::build() ()
#10 0x000055555789983e in js::jit::CompileBackEnd(js::jit::MIRGenerator*, js::jit::WarpSnapshot*) ()
#11 0x000055555789b23b in js::jit::Compile(JSContext*, JS::Handle<JSScript*>, js::jit::BaselineFrame*, unsigned char*) ()
#12 0x000055555789be2d in IonCompileScriptForBaseline(JSContext*, js::jit::BaselineFrame*, unsigned char*) ()
#13 0x0000303c57719be5 in ?? ()
[...]
#127 0x0000054c81737e10 in ?? ()
rax	0x555555755cf6	93824994335990
rbx	0x0	0
rcx	0x555557fe4d68	93825036864872
rdx	0x0	0
rsi	0x7ffff7105770	140737338431344
rdi	0x7ffff7104540	140737338426688
rbp	0x7ffffff59d40	140737487674688
rsp	0x7ffffff59d00	140737487674624
r8	0x7ffff7105770	140737338431344
r9	0x7ffff7f99840	140737353717824
r10	0x58	88
r11	0x7ffff6dac7a0	140737334921120
r12	0x55555762b940	93825026668864
r13	0x5555558e579c	93824995973020
r14	0x7ffffff59e00	140737487674880
r15	0x2	2
rip	0x55555791bc1f <WarpCacheIRTranspiler::emitFunApplyArgsObj(js::jit::WrappedFunction*, js::jit::CallFlags)+399>
=> 0x55555791bc1f <_ZN21WarpCacheIRTranspiler19emitFunApplyArgsObjEPN2js3jit15WrappedFunctionENS1_9CallFlagsE+399>:	movl   $0x1072,0x0
   0x55555791bc2a <_ZN21WarpCacheIRTranspiler19emitFunApplyArgsObjEPN2js3jit15WrappedFunctionENS1_9CallFlagsE+410>:	callq  0x555556a7dcfc <abort>

Marking s-s until investigated due to JIT-related assertion.

Attached file Testcase

Iain, this sounds like another follow-up to the recent change on arguments object compilation.

Flags: needinfo?(iireland)

Bugmon Analysis:
Verified bug as reproducible on mozilla-central 20210215093120-ffed7ebd405a.
The bug appears to have been introduced in the following build range:

Start: cfffb092a39f8a76a485e8e2399d91c24a1c9810 (20210212202418)
End: 776c08d542f8f27bbbdb7594e8baf4c0bdbc3b19 (20210212203140)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=cfffb092a39f8a76a485e8e2399d91c24a1c9810&tochange=776c08d542f8f27bbbdb7594e8baf4c0bdbc3b19

Whiteboard: [bugmon:update,bisect] → [bugmon:update,bisected,confirmed]
Has Regression Range: --- → yes

Not security-sensitive. In fact, the fix is just to delete this assertion: I absent-mindedly copied it from emitFunApplyMagicArgs when I wrote emitFunApplyArgsObj, but there's no reason that we can't support ApplyArgsObj in an inlined function. (Scalar replacement of arguments just works out of the box, even.)

Group: javascript-core-security
Flags: needinfo?(iireland)

I absent-mindedly copied this assertion from emitFunApplyMagicArgs, but there's no reason for it.

With the assertion removed, we can even scalar-replace arguments in this testcase after inlining bar into foo, and it Just Works.

Assignee: nobody → iireland
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 87 Branch

Bugmon Analysis:
Verified bug as fixed on rev mozilla-central 20210218092411-d1b7430e5ebb.
Removing bugmon keyword as no further action possible.
Please review the bug and re-add the keyword for further analysis.

Status: RESOLVED → VERIFIED
Keywords: bugmon
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: