Crash in [@ IPCError-browser | ShutDownKill | _fini]
Categories
(Core :: DOM: Content Processes, defect)
Tracking
()
People
(Reporter: furkan, Unassigned)
Details
Crash Data
Maybe Fission related. (DOMFissionEnabled=1)
Crash report: https://crash-stats.mozilla.org/report/index/cbe50d24-da50-4818-845d-1a2440210223
Reason: DUMP_REQUESTED
Top 3 frames of crashing thread:
0 @0x29de63cf312
1 libxul.so _fini
2 [stack] [stack]@0x1dc67
Comment 1•4 years ago
|
||
This is a content process shutdown hang in… the _fini
frame is from stack scanning so that could be false positive, and the unknown address could indicate JS JITcode? This may not be actionable, but there's no indication that the root cause is IPC.
Comment 2•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Content Processes' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 3•4 years ago
|
||
Resolving incomplete because this crash report is not actionable. ShutDownKills is how we report shutdown hangs, so crashing while initiating a ShutDownKill is not a critical problem and won't cause user data loss.
Comment 4•4 years ago
|
||
(In reply to Chris Peterson [:cpeterson] from comment #3)
Resolving incomplete because this crash report is not actionable. ShutDownKills is how we report shutdown hangs, so crashing while initiating a ShutDownKill is not a critical problem and won't cause user data loss.
As I understand it, it's not actually crashing: when the content process fails to shut down in time, the parent process creates a “crash” dump of its current state and then kills it.
However, it may also be the case that there isn't enough information in the crash report to take action on.
Description
•