macOS 10.13+10.14 Crash in [@ pthread_kill | abort | _RegisterApplication], [@ pthread_kill | abort | AbortIfNotRunningSystemCurrentEnoughBasedOnBuildString | _RegisterApplication]
Categories
(Core :: Widget: Cocoa, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr102 | --- | unaffected |
firefox-esr115 | --- | unaffected |
firefox116 | + | wontfix |
firefox117 | --- | wontfix |
firefox118 | --- | wontfix |
People
(Reporter: aryx, Unassigned)
Details
(Keywords: crash)
Crash Data
These crashes are from Firefox 116.0 launched on macOS 10.13 and 10.14 which are not supported anymore.
Signatures:
- 10.13 [@ pthread_kill | abort | AbortIfNotRunningSystemCurrentEnoughBasedOnBuildString | _RegisterApplication], example bp-691d2ab5-e450-4d56-b1aa-4d7680230803
- 10.14 [@ pthread_kill | abort | _RegisterApplication], example bp-f3acbfa5-e407-4f56-8422-5c9f40230803
Are these crashes expected if a user download Firefox 116.0 and tries to launch it on these platforms?
Crash report: https://crash-stats.mozilla.org/report/index/f3acbfa5-e407-4f56-8422-5c9f40230803
Reason: EXC_SOFTWARE / SIGABRT
Top 10 frames of crashing thread:
0 libsystem_kernel.dylib __pthread_kill
1 libsystem_pthread.dylib pthread_kill
2 libsystem_c.dylib abort
3 HIServices _RegisterApplication
4 HIServices GetCurrentProcess
5 HIToolbox MenuBarInstance::GetAggregateUIMode
6 HIToolbox MenuBarInstance::IsVisible
7 AppKit _NSInitializeAppContext
8 AppKit -[NSApplication init]
9 AppKit +[NSApplication sharedApplication]
Updated•10 months ago
|
Comment 1•10 months ago
|
||
The bug is marked as tracked for firefox116 (release). However, the bug still isn't assigned.
:gcp, could you please find an assignee for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.
For more information, please visit BugBot documentation.
Comment 2•10 months ago
|
||
Yeah, I think this is best explained by people manually downloading and trying to install/run. As long as the volume stays low, I don't think there's cause for alarm. But we should definitely keep an eye on that!
Updated•10 months ago
|
Comment 3•9 months ago
|
||
This is a reminder regarding comment #1!
The bug is marked as tracked for firefox116 (release). We have limited time to fix this, the soft freeze is in 13 days. However, the bug still isn't assigned.
Comment 4•9 months ago
|
||
This is a reminder regarding comment #1!
The bug is marked as tracked for firefox116 (release). We have limited time to fix this, the soft freeze is in 10 days. However, the bug still isn't assigned.
Comment 5•9 months ago
|
||
About 2/3 of affected macOS users have been successfully migrated to the ESR channel. QA did extensive testing and we also did another round of testing and review of the Balrog rules in place and weren't able to identify a scenario which would lead to users being automatically updated to these releases erroneously by us.
The best theory we have right now is that this is being caused by third-party software which aims to keep various installed programs up to date, but does so without utilizing our update servers and therefore ignoring the migration rules we set up.
Given that this appears to be caused by factors which are out of our control and the volume remains low, resolving this as WONTFIX.
Description
•