990598 - [e10s] Everything goes south after CPOW timeout

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

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

I've noticed that if a page is taking a long time and a CPOW times out during that time, we lose the ability to communicate with the child. I just have to restart Firefox.

Comment 1

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

Attachment: timeout-fix

Jim, it looks like you worked on some of this timeout stuff for plugins. Anyway, the problem is that, when ShouldContinueFromReplyTimeout return false, we're supposed to do something to kill the child and cleanup. Right now we're not doing that. For now I think the easiest thing would be to just not timeout. Eventually we probably want to do something like what PluginParent does.

Comment 2

[Jim Mathies [:jimm]]

I understand what this changes, but I'm not sure if it's ok to do this. With plugins, if a reply times out in the child, we crash the plugin process to try and free up the parent. If the parent detects a timeout in the child, we throw up a hang ui and then either wait or terminate the child.

When we return false from this for content processes, the channel state gets set to timed out, and we synchronously close the connection - 

http://mxr.mozilla.org/mozilla-central/source/ipc/glue/MessageChannel.cpp#1369
http://mxr.mozilla.org/mozilla-central/source/ipc/glue/MessageChannel.cpp#1369

Returning true implies this will never happen and we will continue to wait forever implying the content process may end up being a zombie that sits around forever.

A couple questions - what impact will this have on B2G? Does closing the connection shutdown the child process, or does it hang around forever?

As you point out, we need a follow up bug to deal with this appropriately once we know what the correct behavior is supposed to be. (hang ui? terminate, etc.)

Comment 3

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

Attachment: no-timeout

I found a better fix for this. With this change, we should never call the code from the previous patch.

B2G should not be affected by this change. It never synchronously waits from the parent process, so the code in question will never be triggered.

Closing the connecting does not kill the child. It seems to just sit there spewing errors until I kill it.

Comment 4

[Jim Mathies [:jimm]]

Comment on attachment 8414761 [details] [diff] [review]
no-timeout

Looks

Comment 5

[Jim Mathies [:jimm]]

.. good! Note this is basically a backout of bug 905896.

Comment 6

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/4c394a47bbc7

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/4c394a47bbc7