Assertion failure: !needsArgsAnalysis(), at vm/JSScript.h:2076 with oom on async function
Categories
(Core :: JavaScript Engine, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox85 | --- | unaffected |
firefox86 | --- | unaffected |
firefox87 | --- | verified |
People
(Reporter: decoder, Assigned: tcampbell)
References
(Regression)
Details
(Keywords: assertion, regression, testcase, Whiteboard: [bugmon:update,bisected,confirmed])
Attachments
(2 files)
The following testcase crashes on mozilla-central revision 20210128-37557864a684 (debug build, run with --fuzzing-safe --no-threads):
oomTest(async function(y){
await y;
arguments();
})
relazifyFunctions();
Backtrace:
received signal SIGSEGV, Segmentation fault.
#0 0x0000555556d9dd9c in js::AbstractGeneratorObject::resume(JSContext*, js::InterpreterActivation&, JS::Handle<js::AbstractGeneratorObject*>, JS::Handle<JS::Value>, JS::Handle<JS::Value>) ()
#1 0x0000555556b92bf6 in Interpret(JSContext*, js::RunState&) ()
#2 0x0000555556b82088 in js::RunScript(JSContext*, js::RunState&) ()
#3 0x0000555556b96b01 in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) ()
#4 0x0000555556b97e81 in InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason) ()
#5 0x0000555556b980a0 in js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) ()
#6 0x0000555556f689e0 in js::CallSelfHostedFunction(JSContext*, JS::Handle<js::PropertyName*>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>) ()
#7 0x0000555556d065ef in AsyncFunctionResume(JSContext*, JS::Handle<js::AsyncFunctionGeneratorObject*>, ResumeKind, JS::Handle<JS::Value>) ()
#8 0x0000555556ddf952 in PromiseReactionJob(JSContext*, unsigned int, JS::Value*) ()
#9 0x0000555556b972e2 in CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) ()
#10 0x0000555556b96b62 in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) ()
#11 0x0000555556b97e81 in InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason) ()
#12 0x0000555556b980a0 in js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) ()
#13 0x0000555557198a40 in JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) ()
#14 0x0000555556e700bf in js::InternalJobQueue::runJobs(JSContext*) ()
#15 0x0000555556e6fbd6 in js::RunJobs(JSContext*) ()
#16 0x0000555556a1f2a8 in RunShellJobs(JSContext*) ()
#17 0x0000555556a07c72 in Shell(JSContext*, js::cli::OptionParser*, char**) ()
#18 0x0000555556a008cf in main ()
rax 0x5555557b0678 93824994707064
rbx 0x7ffff5a0d0d8 140737314345176
rcx 0x555557fdc6e8 93825036830440
rdx 0x0 0
rsi 0x7ffff7105770 140737338431344
rdi 0x7ffff7104540 140737338426688
rbp 0x7fffffffb780 140737488336768
rsp 0x7fffffffb6e0 140737488336608
r8 0x7ffff7105770 140737338431344
r9 0x7ffff7f998c0 140737353717952
r10 0x58 88
r11 0x7ffff6dac7a0 140737334921120
r12 0x7fffffffb800 140737488336896
r13 0x7fffffffb710 140737488336656
r14 0x7fffffffba70 140737488337520
r15 0x7fffffffb720 140737488336672
rip 0x555556d9dd9c <js::AbstractGeneratorObject::resume(JSContext*, js::InterpreterActivation&, JS::Handle<js::AbstractGeneratorObject*>, JS::Handle<JS::Value>, JS::Handle<JS::Value>)+2268>
=> 0x555556d9dd9c <_ZN2js23AbstractGeneratorObject6resumeEP9JSContextRNS_21InterpreterActivationEN2JS6HandleIPS0_EENS6_INS5_5ValueEEESA_+2268>: movl $0x81c,0x0
0x555556d9dda7 <_ZN2js23AbstractGeneratorObject6resumeEP9JSContextRNS_21InterpreterActivationEN2JS6HandleIPS0_EENS6_INS5_5ValueEEESA_+2279>: callq 0x555556a8cd70 <abort>
Marking s-s until investigated because the impact is not clear to me.
Reporter | ||
Comment 1•4 years ago
|
||
Comment 2•4 years ago
|
||
Ted, Matthew, could this be related to Stencil changes in relation to generator usage?
Assignee | ||
Comment 3•4 years ago
|
||
Almost certainly Bug 1627111. Thanks, I'll take a look today.
Updated•4 years ago
|
Assignee | ||
Comment 4•4 years ago
|
||
In opt builds the code does the right thing anyways. In debug, a consistency check assertion fails. The fix is to not call resetArgsUsageAnalysis
more than once to avoid losing the cached result. This is simpler code in the end and avoids redundant calls to the arguments analysis.
Assignee | ||
Comment 5•4 years ago
|
||
The arguments analysis is deterministic and BaseScript::immutableFlags are
now immutable, so we can simply reset the state flags in the BaseScript
constructor. This also avoids running the analysis again after relazification
since the result will be unchanged. Some over-sensitive debug asserts were
also being tripped up by this.
Comment 6•4 years ago
|
||
Bugmon Analysis:
Verified bug as reproducible on mozilla-central 20210128094617-37557864a684.
The bug appears to have been introduced in the following build range:
Start: 6547f3014615aece2b3b5ca34493711e022935bc (20210127133643)
End: 28e150b3df5987707a0d6e81fd362c6c1e1b7302 (20210127133841)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6547f3014615aece2b3b5ca34493711e022935bc&tochange=28e150b3df5987707a0d6e81fd362c6c1e1b7302
Comment 8•4 years ago
|
||
bugherder |
Comment 9•4 years ago
|
||
Set release status flags based on info from the regressing bug 1627111
Comment 10•4 years ago
|
||
Bugmon Analysis:
Verified bug as fixed on rev mozilla-central 20210129095132-2610d2d33a73.
Removing bugmon keyword as no further action possible.
Please review the bug and re-add the keyword for further analysis.
Description
•