1352458 - Crash in mozilla::ipc::MessageChannel::SendBuildID | mozilla::dom::ContentChild::Init

Status: RESOLVED WORKSFORME

(Core :: DOM: Content Processes, defect, P2)

Description

[Andrew McCreight [:mccr8]]

This bug was filed from the Socorro interface and is 
report bp-fdc1ea52-c3e2-4c2b-be2e-ebd6e2170331.
=============================================================

There are 101 crashes with this signature. They seem to be happening when we're unable to open the channel to the parent process. I could fail gracefully in this method, but I'm not sure things are in a recoverable state if we can't even open a channel to the ContentParent.

About half of them have "Failed to connect GPU process" in their graphics critical error annotation. I don't know if that's unusual or not.

Comment 1

[(Away)]

(In reply to Andrew McCreight [:mccr8] from comment #0)
> There are 101 crashes with this signature. They seem to be happening when
> we're unable to open the channel to the parent process. I could fail
> gracefully in this method, but I'm not sure things are in a recoverable
> state if we can't even open a channel to the ContentParent.

ContentChild::Init returns early if Open() fails, so it seems more like we're able to open the channel but then it gets closed. I don't know if that helps.

Comment 2

[(Away)]

[Tracking Requested - why for this release]: This may be more common than we're seeing data for, in light of bug 1396728 comment 15. Requesting tracking as a precautionary measure until we better understand how frequent this is.

Comment 3

[(Away)]

Jim are you able to tell whether (or how many) reports of this are hitting Windows Error Reporting rather than Firefox's crash reporter?

Comment 4

[Chris Peterson [:cpeterson]]

This crash seemed to start in 53.0 or 55.0. Over the last 12 months, there were 7 crashes in 53.0a1 and the rest are 55.0 or later.

The crash volume in beta builds seems to fluctuate. Some 55.0b and 56.0b beta builds had fewer than a dozen crash reports while others had hundreds.

https://crash-stats.mozilla.com/search/?signature=%3Dmozilla%3A%3Aipc%3A%3AMessageChannel%3A%3ASendBuildID%20%7C%20mozilla%3A%3Adom%3A%3AContentChild%3A%3AInit&product=Firefox&date=%3E%3D2016-09-20T18%3A44%3A00.000Z&date=%3C2017-09-19T18%3A44%3A33.000Z&_sort=-date&_facets=signature&_facets=version&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-version

Windows 7 seems to be overrepresented. 80% of the crash reports are from Windows 7, but only about 50% of Windows Firefox users run Windows 7.

Comment 5

[Liz Henry (:lizzard) (relman/hg->git project)]

I can track this during the 56 cycle, for a bit. If we don't get a big spike in crashes or anyone actively investigating I will wontfix for 56 after next week.

Comment 7

[Jim Mathies [:jimm]]

My first thought was anti-virus, but I'm not finding injected modules in most of these crash reports.

(In reply to David Major [:dmajor] from comment #3)
> Jim are you able to tell whether (or how many) reports of this are hitting
> Windows Error Reporting rather than Firefox's crash reporter?

I don't see anything related in the crashes we're tracking. See bug 1371286 if you're curious.

Will poke a bit more.

Comment 8

[Liz Henry (:lizzard) (relman/hg->git project)]

Crash volume on release 56 is quite low, 18 crashes in the last week.
We are still seeing lots of crashes on beta, but for only a few installs (for example, 69 crashes/6 installs on beta 6)

Comment 9

[Andrew McCreight [:mccr8]]

I believe that this was "fixed" on trunk by the patches landed in bug 1333056. This could be uplifted there if desired.

Comment 10

[Andrew McCreight [:mccr8]]

I nominated the relevant patch for uplift.

Comment 11

[Andrew McCreight [:mccr8]]

This should crash in a different way now.