Crash in [@ js::jit::JitScript::MonitorBytecodeType]
Categories
(Core :: JavaScript Engine: JIT, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr68 | --- | unaffected |
| firefox72 | --- | wontfix |
| firefox73 | --- | affected |
| firefox74 | --- | affected |
People
(Reporter: pascalc, Unassigned)
Details
(Keywords: crash)
Crash Data
This bug is for crash report bp-23531e05-1d20-4214-a20a-5551f0200205.
Top 3 frames of crashing thread:
0 XUL js::jit::JitScript::MonitorBytecodeType js/src/vm/TypeInference-inl.h:624
1 XUL js::jit::DoTypeMonitorFallback js/src/jit/BaselineIC.cpp:1298
2 XUL js::jit::tailCallVMFunctions
Medium crasher on all channels except ESR.
|
Reporter | |
Updated•5 years ago
|
|
||
Comment 1•5 years ago
|
||
This issue started to spike in release starting after Firefox 69 release.
I do not think the stack trace is going to be of any help, but maybe we did some modification of TI or monitoring code in the 69 cycle? (or uplifts during 70 cycle)
https://wiki.mozilla.org/Release_Management/Calendar
|
|
||
Updated•5 years ago
|
|
||
Comment 2•5 years ago
|
||
The crash reasons & stacks are all over the place (and often corrupt) so there's a high chance that this is just users with flaky hardware. There might be something actionable in there but I can't see it just by eyeballing the crashes.
|
||
Comment 3•5 years ago
|
||
MonitorBytecodeType and related functions is where we typically crash when a corrupt Value is returned somewhere. Without STR or a clear pattern it's impossible to say more, but it's very unlikely the bug is in code close to where we crash.
|
||
Comment 4•4 years ago
|
||
Old, TI related bug. No longer valid with Warp.
Description
•