Assertion failure: !builder_->inlineCallInfo(), at jit/WarpCacheIRTranspiler.cpp:4210
Categories
(Core :: JavaScript Engine: JIT, defect)
Tracking
()
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.
Reporter | ||
Comment 1•4 years ago
|
||
Comment 2•4 years ago
|
||
Iain, this sounds like another follow-up to the recent change on arguments object compilation.
Comment 3•4 years ago
|
||
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
Updated•4 years ago
|
Assignee | ||
Comment 4•4 years ago
|
||
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.)
Assignee | ||
Comment 5•4 years ago
|
||
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.
Updated•4 years ago
|
Comment 7•4 years ago
|
||
bugherder |
Comment 8•4 years ago
|
||
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.
Updated•4 years ago
|
Description
•