Closed Bug 1293284 Opened 3 years ago Closed 2 years ago

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

Categories

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

50 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 1364849
Tracking Status
e10s + ---

People

(Reporter: mconley, Assigned: kanru)

References

(Blocks 2 open bugs)

Details

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).
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.
(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.
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.
See Also: → 1324428
(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.
Assignee: nobody → kchen
See Also: → 1325918
Blocks: 1325918
Priority: -- → P1
On nightly we already reuse some of these short lived content processes (in the way described by comment 3)
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1364849
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.
You need to log in before you can comment on or make changes to this bug.