Crash [@ JS::GetExecutionGlobalFromJSMicroTask(JSObject*)]
Categories
(Core :: JavaScript Engine, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr115 | --- | unaffected |
| firefox-esr140 | --- | unaffected |
| firefox145 | --- | disabled |
| firefox146 | --- | disabled |
| firefox147 | --- | verified |
People
(Reporter: decoder, Assigned: arai)
References
(Regression)
Details
(4 keywords, Whiteboard: [bugmon:update,bisected,confirmed][fuzzblocker])
Crash Data
Attachments
(6 files)
The following testcase crashes on mozilla-central revision 20251116-69c8e4489245 (opt build, run with --fuzzing-safe --ion-offthread-compile=off --more-compartments test-indirect.js):
newGlobal().Promise.resolve().then(() => {})
nukeAllCCWs()
Backtrace:
received signal SIGSEGV, Segmentation fault.
#0 0x0000be8c9c89038c in JS::GetExecutionGlobalFromJSMicroTask(JSObject*) ()
#1 0x0000be8c9c875450 in js::InternalJobQueue::runJobs(JSContext*) ()
#2 0x0000be8c9c796150 in RunShellJobs(JSContext*) ()
#3 0x0000be8c9c769104 in main ()
x0 0x715012d8 38274354647768
x1 0x9d0d1db8 209511139581368
x2 0x3 3
x3 0x1 1
x4 0x9d0d4d58 209511139593560
x5 0x17f 383
x6 0x0 0
x7 0x0 0
x8 0x0 0
x9 0x1e67 7783
x10 0x9ba55917 209511116003607
x11 0x0 0
x12 0x0 0
x13 0x0 0
x14 0xfc000 1032192
x15 0x0 0
x16 0x1 1
x17 0x4a784fb0 256402207035312
x18 0x0 0
x19 0xa423a00 256401129748992
x20 0xa434100 256401129816320
x21 0xfdfe5330 281474943046448
x22 0xfdfe5300 281474943046400
x23 0x0 0
x24 0xa51e1f0 256401130775024
x25 0x0 -1829587348619264
x26 0xa434168 256401129816424
x27 0xa434118 256401129816344
x28 0xfdfe5308 281474943046408
x29 0xfdfe52c0 281474943046336
x30 0x9c875450 209511130813520
sp 0xfdfe52b0 281474943046320
pc 0xbe8c9c89038c <JS::GetExecutionGlobalFromJSMicroTask(JSObject*)+604>
cpsr [ EL=0 BTYPE=0 SSBS C ]
fpcsr void
fpcr 0x0 0
=> 0xbe8c9c89038c <_ZN2JS33GetExecutionGlobalFromJSMicroTaskEP8JSObject+604>: str x9, [x8]
0xbe8c9c890390 <_ZN2JS33GetExecutionGlobalFromJSMicroTaskEP8JSObject+608>: bl 0xbe8c9c01b118 <abort>
Fuzzblocker, marking s-s until checked out.
| Reporter | ||
Comment 1•9 months ago
|
||
| Reporter | ||
Comment 2•9 months ago
|
||
Comment 3•9 months ago
|
||
Verified bug as reproducible on mozilla-central 20251117095036-338a6e3364af.
The bug appears to have been introduced in the following build range:
Start: 0ecf73d86765a2f666eb6731435e2cd7867e750f (20251113150613)
End: 2053be8ca52cb59d95eebef913b26254ab61995c (20251113164320)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0ecf73d86765a2f666eb6731435e2cd7867e750f&tochange=2053be8ca52cb59d95eebef913b26254ab61995c
Comment 4•9 months ago
|
||
With the old microtask queue, this testcase throws an exception ("TypeError: can't access dead object").
I think it's a missing check for dead wrappers here. I don't think this is security-sensitive: if we reach this code with a dead wrapper, we will always MOZ_CRASH.
It's slightly tricky to fix because this code doesn't have a JSContext available to report errors. Its callers generally seem to expect it to be infallible
Arai, you reviewed this code for Matt (who is currently travelling). Do you remember enough of the context to be able to propose a fix, or should we wait for Matt to be back?
| Assignee | ||
Comment 5•9 months ago
|
||
Good find!
So, the new microtask code's assumption around dead-wrapper-ness is mostly based on the gecko's case, where entering the microtask checkpoint would already guarantee the global being alive.
But indeed, directly nuking the CCWs with the test API will break it.
And I think having a dead wrapper check everywhere won't so much hurt the performance, and also it's safer in long term.
so I'm leaning toward adding dead wrapper checks to those APIs and consumers.
I'll look into it.
| Assignee | ||
Comment 6•9 months ago
|
||
Updated•9 months ago
|
| Assignee | ||
Comment 7•9 months ago
|
||
| Assignee | ||
Comment 8•9 months ago
|
||
| Assignee | ||
Comment 9•9 months ago
|
||
| Assignee | ||
Updated•9 months ago
|
Comment 10•9 months ago
|
||
Based on comment #3, this bug contains a bisection range found by bugmon. However, the Regressed by field is still not filled.
:arai, if possible, could you fill the Regressed by field and investigate this regression?
For more information, please visit BugBot documentation.
Updated•9 months ago
|
Comment 11•9 months ago
|
||
Set release status flags based on info from the regressing bug 1997192
| Assignee | ||
Comment 12•9 months ago
|
||
Given this has been behind a pref, and it's enabled in bug 1997192 from 147, this is effectively nightly only.
I'll land the patches without sec approval requests.
Comment 13•9 months ago
|
||
Comment 14•9 months ago
|
||
https://hg.mozilla.org/mozilla-central/rev/3e2732ac2163
https://hg.mozilla.org/mozilla-central/rev/c22f0a10f4a4
https://hg.mozilla.org/mozilla-central/rev/a731d229f5d8
https://hg.mozilla.org/mozilla-central/rev/ff2693108be0
https://hg.mozilla.org/mozilla-central/rev/70ed77e4e228
Comment 15•9 months ago
|
||
Verified bug as fixed on rev mozilla-central 20251119215322-e4b3aaadb10a.
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.
Updated•3 months ago
|
Description
•