Crash in [@ -[MOZMenuOpeningCoordinator _runMenu]] with !mRunMenuIsOnTheStack
Categories
(Core :: Widget: Cocoa, defect, P3)
Tracking
()
People
(Reporter: mccr8, Assigned: spohl)
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
|
48 bytes,
text/x-phabricator-request
|
diannaS
:
approval-mozilla-esr115+
|
Details | Review |
Crash report: https://crash-stats.mozilla.org/report/index/47c42691-017a-49ea-bf48-e91d60221209
MOZ_CRASH Reason: MOZ_RELEASE_ASSERT(!mRunMenuIsOnTheStack)
Top 10 frames of crashing thread:
0 XUL -[MOZMenuOpeningCoordinator _runMenu] widget/cocoa/MOZMenuOpeningCoordinator.mm:92
1 Foundation __NSFireDelayedPerform
2 CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__
3 CoreFoundation __CFRunLoopDoTimer
4 CoreFoundation __CFRunLoopDoTimers
5 CoreFoundation __CFRunLoopRun
6 CoreFoundation CFRunLoopRunSpecific
7 Foundation -[NSRunLoop runMode:beforeDate:]
8 Foundation -[NSRunLoop runUntilDate:]
9 AppKit NSCoreDragTrackingProc
This release assert was added in bug 1707598. The volume is low, but perhaps the stacks are interesting.
Comment 1•3 years ago
|
||
The severity field is not set for this bug.
:spohl, could you have a look please?
For more information, please visit auto_nag documentation.
| Assignee | ||
Comment 2•3 years ago
•
|
||
It looks like _runMenu is already on the stack here. Markus, could you take a look to see what might be going on here?
Comment 3•3 years ago
|
||
Hmm, interesting: We only enqueue a delayed perform of _runMenu if mRunMenuIsOnTheStack is false:
if (!mRunMenuIsOnTheStack) {
// Call _runMenu from the event loop, so that it doesn't block this call.
[self performSelector:@selector(_runMenu) withObject:nil afterDelay:0.0];
}
But then mRunMenuIsOnTheStack is true by the time the delayed _runMenu perform is executed.
So it seems that, between the time at which this code runs, and the time at which the delayed perform is executed, something else causes us to enter _runMenu. But I don't understand how that's possible - if another delayed perform for _runMenu was already pending, then we should have crashed in the !mPendingOpening assert further up in the same function.
| Assignee | ||
Updated•3 years ago
|
| Assignee | ||
Comment 4•2 years ago
|
||
Updated•2 years ago
|
| Assignee | ||
Updated•2 years ago
|
Comment 6•2 years ago
|
||
| bugherder | ||
Updated•2 years ago
|
Comment 7•2 years ago
|
||
The patch landed in nightly and beta is affected.
:spohl, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox122towontfix.
For more information, please visit BugBot documentation.
| Assignee | ||
Comment 8•2 years ago
|
||
I don't believe that the crash rate here warrants an uplift and even thought he patch seems straightforward, it could benefit from more bake time.
Comment 9•2 years ago
|
||
What are your thoughts about taking this on ESR?
| Assignee | ||
Comment 10•2 years ago
|
||
Comment on attachment 9373046 [details]
Bug 1804978: Prevent release assert crashes due to a race when opening context menus on macOS. r=mstange!
ESR Uplift Approval Request
- If this is not a sec:{high,crit} bug, please state case for ESR consideration: This prevents a crash due to a possible race when opening context menus on macOS.
- User impact if declined: Possibility of crashes when opening context menus on macOS.
- Fix Landed on Version: 123
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): The patch is minimal and well understood. The patch adds a native API call that cancels the opening of a context menu when the user is attempting to open a different/new context menu.
Comment 11•2 years ago
|
||
Comment on attachment 9373046 [details]
Bug 1804978: Prevent release assert crashes due to a race when opening context menus on macOS. r=mstange!
Approved for 115.9esr
Comment 12•2 years ago
|
||
| uplift | ||
Updated•2 years ago
|
Description
•