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

RESOLVED FIXED in Firefox 41



DOM: Content Processes
3 years ago
3 years ago


(Reporter: jimm, Assigned: gw280)


(Blocks: 2 bugs)

Dependency tree / graph

Firefox Tracking Flags

(e10sm8+, firefox41 fixed, firefox42 fixed)



(1 attachment)



3 years ago

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.

Assignee: nobody → gwright
tracking-e10s: ? → m8+
Created attachment 8638572 [details] [diff] [review]

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.
Attachment #8638572 - Flags: review?(wmccloskey)
Attachment #8638572 - Flags: review?(wmccloskey) → review+


3 years ago
Keywords: leave-open

Comment 4

3 years ago
Can we uplift this to aurora as well?
Flags: needinfo?(gwright)
Comment on attachment 8638572 [details] [diff] [review]

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
Flags: needinfo?(gwright)
Attachment #8638572 - Flags: approval-mozilla-aurora?
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

3 years ago
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)
Flags: needinfo?(gwright)

Comment 8

3 years ago
I just tried running the test with your patch and it appears to be passing now.
Thanks for the info Trevor!
Flags: needinfo?(gwright)
Closing this as per comment 6.
Last Resolved: 3 years ago
Resolution: --- → FIXED
Comment on attachment 8638572 [details] [diff] [review]

Approved as this has been in m-c for a few days, the change looks pretty straightforward and low risk.
Attachment #8638572 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+


3 years ago
Blocks: 1189025
status-firefox41: --- → affected
status-firefox42: affected → fixed
Keywords: leave-open
Target Milestone: --- → mozilla42
You need to log in before you can comment on or make changes to this bug.