1184276 - [e10s] PContentChild::SendGetBlocklistState fails with 'message was deserialized, but the handler returned false (indicating failure)'

Status: RESOLVED FIXED

(Core :: DOM: Content Processes, defect)

Description

[Jim Mathies [:jimm]]

handler:
https://hg.mozilla.org/mozilla-central/annotate/e7e69cc8c07b/dom/ipc/ContentParent.cpp#l1114

This has never looked too bad on nightly but on aurora it's currently about the top 3rd or 4th abort if you total up all the signatures.

http://www.mathies.com/mozilla/client-abort-report-aurora.txt

Comment 1

[George Wright (:gw280) (needinfo me!)]

Attachment: plugintag.patch

Having spoken a bit with blassey about this, we think this might be a good start to see if the crashes go away. As it's not reproducible, we want to try and get more diagnostic info to try and pinpoint where the issue lies. This return false seems like the most likely candidate, so let's switch that to a success and see what happens.

I've also added more logging on the off-chance that someone running a debug build or something happens to hit this.

Comment 2

[George Wright (:gw280) (needinfo me!)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1b55d2dbeafe

Comment 3

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/1b55d2dbeafe

Comment 4

[Jim Mathies [:jimm]]

Can we uplift this to aurora as well?

Comment 5

[George Wright (:gw280) (needinfo me!)]

Comment on attachment 8638572 [details] [diff] [review]
plugintag.patch

Approval Request Comment
[Feature/regressing bug #]: not a regression
[User impact if declined]: e10s content process crashes can occur when a plugintag is unavailable for whatever reason.
[Describe test coverage new/current, TreeHerder]: mozilla-central tests
[Risks and why]: low risk; no major changes here, just explicitly returning true to avoid an abort.
[String/UUID change made/needed]: none

Comment 6

[George Wright (:gw280) (needinfo me!)]

I just spoke with jimm about this, and we think that this is probably a viable solution for the time being (at least for m8). The idea here is:

- Keep the bug open until we verify whether or not it's this nullptr issue that's causing the abort
- If it is, resolve this bug and file a follow up to investigate why nsPluginHost::PluginWithId() is returning nullptr and re-nom for e10s triage (likely not an m8)
- If not, investigate further.

Comment 7

[Trevor Rowbotham [:rowbot]]

If you are still looking for a way to reproduce this, the browser_plugin_infolink.js test seems to hit this on every other run for me on Windows 7 when you run the test with the --repeat or --run-until-failure flags.  The test is currently disabled in e10s.

mach mochitest browser/base/content/test/plugins/browser_plugin_infolink.js --e10s --repeat 10
^this should fail 5 times with the following error:

IPDL protocol error: Handler for GetBlocklistState returned error code
###!!! [Parent][DispatchSyncMessage] Error: (msgtype=0x3A004E,name=PContent::Msg_GetBlocklistState) Processing error: message was deserialized, but the handler returned false (indicating failure)

Comment 8

[Trevor Rowbotham [:rowbot]]

I just tried running the test with your patch and it appears to be passing now.

Comment 9

[George Wright (:gw280) (needinfo me!)]

Thanks for the info Trevor!

Comment 10

[George Wright (:gw280) (needinfo me!)]

Closing this as per comment 6.

Comment 11

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8638572 [details] [diff] [review]
plugintag.patch

Approved as this has been in m-c for a few days, the change looks pretty straightforward and low risk.

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/250b48c714a0