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
Assignee: nobody → gwright
tracking-e10s: ? → m8+
Created attachment 8638572 [details] [diff] [review] 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.
Attachment #8638572 - Flags: review?(wmccloskey)
Attachment #8638572 - Flags: review?(wmccloskey) → review+
Can we uplift this to aurora as well?
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
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.
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)
I just tried running the test with your patch and it appears to be passing now.
Thanks for the info Trevor!
Closing this as per comment 6.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
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.
Attachment #8638572 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
status-firefox41: --- → affected
status-firefox42: affected → fixed
Target Milestone: --- → mozilla42
status-firefox41: affected → fixed
You need to log in before you can comment on or make changes to this bug.