Assertion failure: !used(), at js/src/jit/Label.h:86
Categories
(Core :: JavaScript Engine, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox67 | --- | wontfix |
firefox68 | --- | fixed |
People
(Reporter: gkw, Assigned: lth)
References
(Regression)
Details
(4 keywords, Whiteboard: [jsbugmon:])
Attachments
(2 files)
The following testcase crashes on mozilla-central revision c7a9affeb604 (build with PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig 'CC="clang -m32 -msse2 -mfpmath=sse"' AR=ar 'CXX="clang++ -m32 -msse2 -mfpmath=sse"' sh ./configure --target=i686-pc-linux --enable-debug --enable-more-deterministic --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests --disable-cranelift, run with --fuzzing-safe --no-threads --no-baseline --no-ion w301-out.wrapper w301-out.wasm):
See attachment.
Backtrace:
#0 js::jit::Label::~Label (this=0xf43) at js/src/jit/Label.h:86
#1 GenerateImportJitExit (masm=..., fi=..., funcImportIndex=4, throwLabel=0xd30, offsets=0x6c0) at js/src/wasm/WasmStubs.cpp:1728
#2 js::wasm::GenerateStubs (env=..., imports=..., exports=..., code=0xf6b2e298) at js/src/wasm/WasmStubs.cpp:2218
#3 0x58466615 in js::wasm::ModuleGenerator::finishCodeTier (this=0xff833b50) at js/src/wasm/WasmGenerator.cpp:1023
#4 0x58467231 in js::wasm::ModuleGenerator::finishModule (this=0xff833b50, bytecode=..., maybeTier2Listener=0x0) at js/src/wasm/WasmGenerator.cpp:1121
/snip
For detailed crash information, see attachment.
Setting s-s as a start because a similar previously-filed bug 1535482 was also s-s.
![]() |
Reporter | |
Comment 1•6 years ago
|
||
![]() |
Reporter | |
Comment 2•6 years ago
|
||
I'm not sure why I can't attach the testcases here (b.m.o seems to error out), but I've sent them to Lars over email.
Assignee | ||
Comment 3•6 years ago
|
||
The previous error was specific to the ARM assembler and it's more likely that this is an improperly handled exception, since it's x86 only.
![]() |
Reporter | |
Comment 4•6 years ago
|
||
autobisectjs shows this is probably related to the following changeset:
The first bad revision is:
changeset: https://hg.mozilla.org/mozilla-central/rev/01a5d9506bb4
user: Nicolas B. Pierron
date: Mon Jul 16 18:13:51 2018 +0000
summary: Bug 1473289 - Work around page table fragmentation caused by mprotect / VirtualProtect using LifoAlloc r=tcampbell
Nicolas, is bug 1473289 a likely regressor?
Comment 5•6 years ago
|
||
(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #4)
autobisectjs shows this is probably related to the following changeset:
The first bad revision is:
changeset: https://hg.mozilla.org/mozilla-central/rev/01a5d9506bb4
user: Nicolas B. Pierron
date: Mon Jul 16 18:13:51 2018 +0000
summary: Bug 1473289 - Work around page table fragmentation caused by mprotect / VirtualProtect using LifoAlloc r=tcampbellNicolas, is bug 1473289 a likely regressor?
This is sounds unlikely. However this patch changes a mechanism meant to protect LifoAlloc buffer against corruption.
However, I would not expect this patch to highlight new failure but to remove interpreter crashes due to the abuse of mprotect.
I know WASM is using LifoAllocScope-like mechanism, and it might be a use-after-free of what remain in the LifoAlloc chunks.
![]() |
Reporter | |
Comment 6•6 years ago
|
||
(In reply to Nicolas B. Pierron [:nbp] from comment #5)
I know WASM is using LifoAllocScope-like mechanism, and it might be a use-after-free of what remain in the LifoAlloc chunks.
I guess the ball is now back in wasm's court?
Assignee | ||
Comment 8•6 years ago
|
||
It's just a lost OOM in the assembler buffer that triggers the assert. The buffer would exceed 2^27-1 in length. The error return is not lost, it's just not recorded properly. No cause for alarm.
I'll see if I can use the same mechanism as I used on ARM to handle this.
Assignee | ||
Comment 9•6 years ago
|
||
This copies the mechanism that was introduced for ARM into the x86 code: it
uses a flag on the jitcontext, if present, to propagate the OOM flag so that
we won't assert in ~Label.
If including Ion.h into this header file is not good then I can move
oomDetected() into the .cpp file.
Updated•6 years ago
|
Updated•6 years ago
|
Comment 10•6 years ago
|
||
Comment 11•6 years ago
|
||
bugherder |
Updated•6 years ago
|
Updated•6 years ago
|
Description
•