1293284 - Find cheaper and less crash-reporty ways of killing short-lived content processes

Status: RESOLVED DUPLICATE of bug 1364849

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

Description

[Mike Conley (:mconley) (:⚙️)]

In bug 1290186, we were dealing with a case where many content processes were being spawned and told to shutdown really quickly - sometimes before they really had a chance to initialize properly. What we ended up with was content processes that had the shutdown timer ticking away while they're still in the process of synchronously asking the parent for startup information, hitting the timeout, and then getting ShutdownKill'd.

I wonder if it makes more sense to detect the case of short-lived processes in ContentParent - like, if we've been asked to shutdown a content process before it's even had a chance to tell the parent that it's ready to roll, maybe we should just kill that content process without a timer (and without a crash report).

Comment 1

[Kan-Ru Chen [:kanru] (UTC+9)]

I looked at the ShutDownKill reports and find many of them contain signatures like gfxPlatform::Init, PContentChild::SendGetXPCOMProcessAttributes indicating that they are asked to shutdown before they are properly initialized. Looks like bug 1290186 is in a test. I'm not sure how this could happen in real word scenario.

Comment 2

[Mike Conley (:mconley) (:⚙️)]

(In reply to Kan-Ru Chen [:kanru] (UTC+8) from comment #1)
> I looked at the ShutDownKill reports and find many of them contain
> signatures like gfxPlatform::Init,
> PContentChild::SendGetXPCOMProcessAttributes indicating that they are asked
> to shutdown before they are properly initialized. Looks like bug 1290186 is
> in a test. I'm not sure how this could happen in real word scenario.

It can happen if, for example, the browser starts up, and the initial tab (which is remote, and starts up the content process) is told to load a non-remote URI (like, for example, about:newtab). This will cause a remoteness flip to occur, and a short-lived content process.

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Another option would be that if a content process is short-lived, that we somehow hand it over to the process preallocator that's being worked on in bug 1324428 so that it can be used next time a remote browser is created.

Comment 4

[Gabor Krizsanits (INACTIVE)]

(In reply to Mike Conley (:mconley) from comment #3)
> Another option would be that if a content process is short-lived, that we
> somehow hand it over to the process preallocator that's being worked on in
> bug 1324428 so that it can be used next time a remote browser is created.

I generally like this idea however I would love to find a fix for the original issue because we might want to kill the preallocated process to early as well. Also I'm not sure if we can get into a situation where the preallocator already have a process available but it probably should be handled as well.

Comment 5

[Gabor Krizsanits (INACTIVE)]

On nightly we already reuse some of these short lived content processes (in the way described by comment 3)

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I will have a look via removing the workaround patch as Mike formerly put in place to get bug 1290186 working. This work will be done via bug 1407949. If it's not enough I will reopen this bug.