1059494 - [e10s] Hanging content processes are never killed in CPOWs

Status: RESOLVED DUPLICATE of bug 1118618

(Core :: DOM: Content Processes, defect)

Description

[John Schoenick [:johns]]

Currently, running a loop such as | while (true); | in content JS from a CPOW hangs indefinitely. This also means that any CPOW that calls into a already-hanging process will hang the parent indefinitely.

Comment 1

[Chris Peterson [:cpeterson]]

Gavin and Brad think this bug should block M2.

Comment 2

[Jim Mathies [:jimm]]

We're going to look at implementing a general purpose hang dialog or notification, that popup up when the content process stops responding which gives the user the option of recovering their tabs.

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Actually, maybe we should think a bit more about this. First, the out-of-process hang dialog will be a real pain to implement. We can probably share code with the plugin hang UI, but it's still going to be difficult. Is there any reason why we couldn't use an in-process dialog? I realize that we'd be spinning a nested event loop and processing messages from the child during that time, but I wonder if that would cause problems.

Second, I wonder if there's some way that we could make the CPOW message fail without killing the child. We'd have to send a message to the child revoking the original CPOW message. And, if the child had already started processing the CPOW message, we'd have to ignore its response. If the child sent up nested requests to the parent while answering the revoked message, I guess we could still process those; I don't think it would do any harm.

The second approach sounds really nice to me. However, I'm leery of doing a lot of hacking on the IPC code before bug 1049879 is sorted out.

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

...and thinking about this some more, the second sentence of comment 0 should not happen. If a content process is hung in JS and we send an unrelated CPOW to it, then the slow script dialog should trigger in the child, which causes us to send IPC to the parent. At that time we should process the CPOW (since it has a higher priority). Luke was playing around with this earlier and he said it works as advertised.

He also suggested a neat idea: the JS interrupt callback (which triggers the slow script dialog) could perhaps check for CPOWs every second and process them. That would make us more responsive at the cost of breaking run-to-completion semantics a little more than the slow script dialog already does.

Comment 5

[Jim Mathies [:jimm]]

Knocking this down to m4, blocked by m3 bug 1049551.

Comment 6

[Jim Mathies [:jimm]]

Hey bill, I'm going to be looking at this over the break since it's one of my two remaining m4s. I'll be investigating an approach based on your comments.

You are currently working on plugin hang related work, is there anything going on there that might affect the work here?

Comment 7

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I'd prefer to take this if you don't mind. I'm working on some patches for a general hang detector that should cover this. I'll file a more specific bug today.