Closed
Bug 1384631
Opened 7 years ago
Closed 7 years ago
Crash in mozilla::SchedulerGroup::Runnable::Run
Categories
(Core :: XPCOM, defect)
Tracking
()
RESOLVED
FIXED
mozilla56
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox54 | --- | unaffected |
firefox55 | --- | unaffected |
firefox56 | --- | fixed |
People
(Reporter: kats, Assigned: mstange)
References
Details
(Keywords: crash, regression)
Crash Data
Attachments
(1 file)
(deleted),
patch
|
billm
:
review+
|
Details | Diff | Splinter Review |
This bug was filed from the Socorro interface and is
report bp-fd5b2d6b-68d6-4547-bda5-90fe10170726.
=============================================================
Got a couple of crashes in nightly opening a window. The window opened but just showed the "oops" tab.
This one I got with ctrl+shift+n (open recently closed window): https://crash-stats.mozilla.com/report/index/0b0b87b4-aca8-4d75-b3eb-e46340170726 is the other report
The one at bp-fd5b2d6b-68d6-4547-bda5-90fe10170726 I got opening a new private browsing window.
Reporter | ||
Comment 1•7 years ago
|
||
Doesn't seem to be reproducible though.
Assignee | ||
Comment 3•7 years ago
|
||
I can reproduce this on Windows if I have the Gecko profiler running and cause a new content process to be created, e.g. by opening a tab or collecting a profile (which opens a new tab).
This seems to be an interaction between bug 1382910 and bug 1378975: Bug 1382910 makes us dispatch CheckResponsivenessEvents very early during child process startup, and bug 1378975 causes them to be dispatched to the SystemGroup, which is not available early during startup.
The patch in bug 1376987 adds the necessary null check, and Bill tells me that it can land quickly.
Crash Signature: [@ mozilla::SchedulerGroup::Runnable::Run] → [@ mozilla::SchedulerGroup::Runnable::Run]
[@ mozilla::SchedulerGroup::SetValidatingAccess]
Depends on: 1376987
Keywords: regression
Assignee | ||
Comment 4•7 years ago
|
||
This patch contains the relevant parts from bug 1376987, with mystor's comment applied.
Attachment #8891004 -
Flags: review?(wmccloskey)
Attachment #8891004 -
Flags: review?(wmccloskey) → review+
Pushed by mstange@themasta.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/0792186da250
Make SystemGroup::Dispatch work early during startup, when it hasn't been initialized yet. r=billm
Assignee | ||
Updated•7 years ago
|
Crash Signature: [@ mozilla::SchedulerGroup::Runnable::Run]
[@ mozilla::SchedulerGroup::SetValidatingAccess] → [@ mozilla::SchedulerGroup::Runnable::Run]
[@ mozilla::SchedulerGroup::SetValidatingAccess]
[@ mozilla::SystemGroup::Dispatch ]
Assignee | ||
Updated•7 years ago
|
Assignee: nobody → mstange
Status: NEW → ASSIGNED
Comment 7•7 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox56:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
Updated•7 years ago
|
status-firefox54:
--- → unaffected
status-firefox55:
--- → unaffected
status-firefox-esr52:
--- → unaffected
You need to log in
before you can comment on or make changes to this bug.
Description
•