Closed Bug 1384631 Opened 2 years ago Closed 2 years ago
Crash in mozilla::Scheduler
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.
Doesn't seem to be reproducible though.
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.
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 firstname.lastname@example.org: 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
Crash Signature: [@ mozilla::SchedulerGroup::Runnable::Run] [@ mozilla::SchedulerGroup::SetValidatingAccess] → [@ mozilla::SchedulerGroup::Runnable::Run] [@ mozilla::SchedulerGroup::SetValidatingAccess] [@ mozilla::SystemGroup::Dispatch ]
Assignee: nobody → mstange
Status: NEW → ASSIGNED
You need to log in before you can comment on or make changes to this bug.