1301888 - content process crash right after parent process crash, with e10s disabled (control cohort)

Status: RESOLVED INVALID

(Core :: General, defect)

Description

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I wanted to test crash reporting on a laptop we got to help debug bug 1296630.  In order to do this, I loaded the testcase from bug 826978 to generate a crash report I could look at, crashed (all of Firefox, since e10s seems to be disabled), typed user comments and email into the crash report, hit "Restart Firefox", and then went to about:crashes.

This, surprisingly, generated *two* crash reports:
bp-03f06009-961a-4e7e-a0e1-21ca02160910
bp-9967da56-015f-4fac-980c-d13ee2160910

They're slightly different.  The first one reports less memory being available.  The second one has "Process Type: content", and has a smaller number of threads (consistent with being a content process, I presume, although I didn't look closely).  Only the first one has the user comment that I entered.

I didn't see any sign of a content process crashing after I restarted Firefox.

And my Firefox 49.0b8 install (with updates disabled, to test bug 1296630) seems to be in the control e10s cohort.

So if I'm in the control e10s cohort, why did I have a content process crash, shortly after having a parent process crash?

Comment 1

[(not currently active) Ted Mielczarek]

That is very strange! If you look at the modules list you can see that the first one is clearly a browser process crash (it has firefox.exe in the modules list) and the second one is in fact a content process crash (it has plugin-container.exe in the modules list).

If you run Firefox with this profile, load a web site, and look at task manager, do you see any content processes? I have no idea what's happening here, but clearly we loaded the same site in both a content process and in the chrome process, as evidenced by the fact that they both crashed at the same place. Maybe this is some sort of bug in the browser e10s handling?

Comment 2

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I won't have access to the laptop in question until September 26.

Comment 3

[(not currently active) Ted Mielczarek]

I do note that the Uptime reported in the second process is all of 1 second.

Comment 4

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

But let's see if Jim has any thoughts, in particular as to whether this is a sign that there's something wrong with the e10s rollout being able to disable e10s properly.

Comment 5

[Jim Mathies [:jimm]]

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #1)
> That is very strange! If you look at the modules list you can see that the
> first one is clearly a browser process crash (it has firefox.exe in the
> modules list) and the second one is in fact a content process crash (it has
> plugin-container.exe in the modules list).

This caught my attention as well, plugin-container is used for NPAPI and media plugins, remote content is rendered in a firefox.exe process. However! This is beta, and the work that split content out to firefox.exe on Windows landed in 51 (bug e10s-rename), so this could be a content process. Since e10s is clearly disabled here (control cohort) I'm guessing this process is the background thumbnailing process loading the same page and crashing as a result. The uptimes kind of point to something like this (147 seconds vs. 1 second).

Comment 6

[(not currently active) Ted Mielczarek]

Oh! I had forgotten about that thing. Maybe it would be nice if we had an extra crash report annotation to indicate that it's the thumbnailing process instead of the normal content process?

Comment 7

[Jim Mathies [:jimm]]

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #6)
> Oh! I had forgotten about that thing. Maybe it would be nice if we had an
> extra crash report annotation to indicate that it's the thumbnailing process
> instead of the normal content process?

No point actually, under e10s the thumbnailing services loads into the first content process. We may decide to split it out into a separate process at some point.

Comment 8

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

OK, sounds like this isn't a bug, then.