macOS Crash in [@ PLDHashTable::Iterator::Iterator | mozilla::a11y::DocAccessibleWrap::ProcessNewLiveRegions]
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr91 | --- | unaffected |
| firefox96 | --- | unaffected |
| firefox97 | + | fixed |
| firefox98 | + | fixed |
| firefox99 | + | fixed |
| firefox100 | + | fixed |
People
(Reporter: aryx, Assigned: eeejay)
References
(Regression)
Details
(Keywords: crash, regression)
Crash Data
Attachments
(1 file)
|
48 bytes,
text/x-phabricator-request
|
dmeehan
:
approval-mozilla-beta+
|
Details | Review |
8 crashes so far, oldest with Firefox 97.0a1 20220108220226, all on macOS 11 + 12. Based on the open site during crashes, this could involve forms.
Is this a regression from bug 1613634?
Crash report: https://crash-stats.mozilla.org/report/index/464c7b30-006a-4d43-a83f-2e4d80220109
Reason: EXC_BAD_ACCESS / KERN_INVALID_ADDRESS
Top 10 frames of crashing thread:
0 XUL PLDHashTable::Iterator::Iterator xpcom/ds/PLDHashTable.cpp:759
1 XUL mozilla::a11y::DocAccessibleWrap::ProcessNewLiveRegions accessible/mac/DocAccessibleWrap.mm:91
2 XUL mozilla::a11y::AccessibleWrap::HandleAccEvent accessible/mac/AccessibleWrap.mm:152
3 XUL nsEventShell::FireEvent accessible/base/nsEventShell.cpp:54
4 XUL mozilla::a11y::NotificationController::ProcessMutationEvents accessible/base/NotificationController.cpp:575
5 XUL mozilla::a11y::NotificationController::WillRefresh accessible/base/NotificationController.cpp:895
6 XUL nsRefreshDriver::Tick layout/base/nsRefreshDriver.cpp:2337
7 XUL mozilla::RefreshDriverTimer::TickRefreshDrivers layout/base/nsRefreshDriver.cpp:326
8 XUL mozilla::RefreshDriverTimer::Tick layout/base/nsRefreshDriver.cpp:342
9 XUL mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::TickRefreshDriver layout/base/nsRefreshDriver.cpp:703
|
||
Comment 1•3 years ago
|
||
Neia, could this be a regression from bug 1613634?
If you are unsure, please forward the needinfo to :Jamie, thanks!
|
||
Comment 2•3 years ago
|
||
80% sure that it is, and if so, I've likely identified the issue and can have a fix out today. Your choice whether we back out https://hg.mozilla.org/mozilla-central/rev/64ae8c433b04 and I resubmit with fixes, or I submit the fix only.
|
Reporter | |
Comment 3•3 years ago
|
||
A follow-up fix is fine, thank you.
|
|
||
Comment 4•3 years ago
|
||
Any additional context you can provide would be valuable. I had a reproduction case, but it appears that the site changed and I'm no longer able to reproduce. Right now it's looking like memory corruption with no obvious connection to the changeset in question, but I'm continuing to investigate.
|
|
Reporter | |
Comment 5•3 years ago
|
||
Needinfoing Eitan who tried to reproduce it at the end of last week.
|
||
Comment 6•3 years ago
|
||
The crash volume on Beta is pretty high and we're a bit over a week out from our first RC builds. What are your thoughts on backing out bug 1613634 from 97 while the investigation continues?
|
||
Updated•3 years ago
|
|
|
||
Comment 8•3 years ago
|
||
Fixed by backout for 97.0b6.
https://hg.mozilla.org/releases/mozilla-beta/rev/05fbafbb07a8
|
||
Comment 9•3 years ago
|
||
Could mDoc be null; i.e. the Accessible or even the entire document died? Of course, the question is why bug 1613634 would cause that. Is there some other event that CoalesceMutationEvents was previously coalescing away before coalescing the hide? Keep in mind that coalescing a hide can shut down the Accessible.
|
|
Reporter | |
Comment 10•3 years ago
|
||
This needs to be backed out once more from beta (or fixed). 52 crashes from 38 installations for 98.0b2 so far.
|
||
Comment 11•3 years ago
|
||
Fixed by backout for 98.0b3
https://hg.mozilla.org/releases/mozilla-beta/rev/94314208d19d1f990646ca3a67c8b17bdf2d88c4
|
|
||
Comment 12•3 years ago
|
||
Eitan, what do you think about just checking for defunct and returning early here? On one hand, this is arguably just wallpapering the issue. On the other hand, we do know that handling events can make Accessibles die; see the various null checks on document in NotificationController. Also, Windows AccessibleWrap early returns for defunct, maybe suggesting this is something we've had to deal with in the past.
|
Assignee | |
Comment 13•3 years ago
|
||
My initial instinct was to check if the doc was null or defunct inside the EVENT_SHOW block. But if there is precedent for it in windows, i think that seems like a low enough risk to do here too. I can take this.
|
|
Assignee | |
Updated•3 years ago
|
|
||
Comment 14•3 years ago
|
||
I've had this crash twice, no solid STR but it happens as I'm bookmarking a page and typing the keywords I want the bookmark to be filed with. On MacOS on Apple Silicon. Is there anything that I should try to reproduce it reliably?
|
|
Assignee | |
Comment 15•3 years ago
|
||
|
|
||
Updated•3 years ago
|
|
||
Comment 17•3 years ago
|
||
|
||
Comment 18•3 years ago
|
||
| bugherder | ||
|
||
Comment 19•3 years ago
|
||
The patch landed in nightly and beta is affected.
:eeejay, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.
For more information, please visit auto_nag documentation.
|
|
Assignee | |
Comment 20•3 years ago
|
||
Comment on attachment 9267464 [details]
Bug 1749633 - Return early if event target is defunct. r?morgan!
Beta/Release Uplift Approval Request
- User impact if declined: A potential crasher
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This is an early return for a rare condition. Returning early avoids the crash.
- String changes made/needed:
|
||
Comment 21•3 years ago
|
||
Comment on attachment 9267464 [details]
Bug 1749633 - Return early if event target is defunct. r?morgan!
Approved for 99.0b5. Thanks.
|
|
||
Comment 22•3 years ago
|
||
| bugherder uplift | ||
Description
•