https://crash-stats.mozilla.com/search/?product=Firefox&signature=~AssertPluginThread&release_channel=nightly&release_channel=aurora&process_type=%21plugin&_facets=plugin_name&_facets=process_type&_facets=dom_ipc_enabled&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=dom_ipc_enabled#crash-reports From what I can tell, all of these are plugin-process crashes. Most of them have e10s enabled, but not all, so I don't know whether this is e10s-related or not. 100% of them were submitted from the infobar, which seems suspicious to me. (Found as a result of looking at bug 1205979). Jim, this seems unfortunate to me but I'm not sure what it's relative priority is. What do you think?
Looking through a batch of these: 1) everything is in plugin-container.exe (plugin crash) 2) uptime = 0 ^ have to dig into plugin process code to see if we set this properly. I seriously doubt these crashes are happening in the first 0 seconds of running. 3) thread 0 stack traces predominately appear to be in mozilla::plugins::PluginInstanceChild::Destroy() ^ have to do some python analysis to confirm this since currently I'm just manually looking these over. 4) every crash appears to be related to java
Ryan, any chance softvision could do a round of e10s testing with java plugins looking for crashy test cases?
Flags: needinfo?(jmathies) → needinfo?(ryanvm)
Flags: needinfo?(ryanvm) → needinfo?(mfunches)
ack: we have been testing Flash Plugin (Blocking/cp2) this week; I will update test workbook with this request.
Benjamin/Jim; We have completed testing for the Java Plugin with e10s enabled. We picked several sites that make use of the java applets. You can review the information at this link: https://docs.google.com/spreadsheets/d/1VNljSnOkciM471nWVI4dQBVF1RUf3ULh-jUU1CT-J-k/edit#gid=1865772785 Please "ni" me if you would like additional testing or confirmations done. a) I have seen bug reports related to GoToWebinar, however we do not have accounts for that. If Moz has a test account, we will test. b) We had no immediate crashes, however the Windows 10x64 applying Fx.32 did experience some crashes. The IDs are listed on the Java Notes tab. c) I have created the following wiki where I will update information related to ongoing Plugin testing - https://wiki.mozilla.org/QA/Plugin_Compatibility_Testing
(In reply to Michelle Funches - QA from comment #5) > Benjamin/Jim; We have completed testing for the Java Plugin with e10s > enabled. > We picked several sites that make use of the java applets. You can review > the information at this link: > > https://docs.google.com/spreadsheets/d/1VNljSnOkciM471nWVI4dQBVF1RUf3ULh- > jUU1CT-J-k/edit#gid=1865772785 > > Please "ni" me if you would like additional testing or confirmations done. > a) I have seen bug reports related to GoToWebinar, however we do not have > accounts for that. If Moz has a test account, we will test. > b) We had no immediate crashes, however the Windows 10x64 applying Fx.32 did > experience some crashes. The IDs are listed on the Java Notes tab. > c) I have created the following wiki where I will update information related > to ongoing Plugin testing - > https://wiki.mozilla.org/QA/Plugin_Compatibility_Testing Thanks!
Gabriele is this possibly the same as the bug you fixed about plugin crashes?
Priority: -- → P2
This doesn't look like bug 1284030 for a number of reasons: first of all it seems to affect versions both before bug 1284030 was introduced and after it was fixed. The uptime is 0 which also makes it unlikely since to trigger bug 1284030 you need to wait for a hang and then for an additional 5s and finally AssertPluginThread() is calling MOZ_RELEASE_ASSERT() which will generate a minidump upon failure so these do look like genuine assertions to me where the plugin code in npjp2.dll is calling NPN_ReleaseObject() on the wrong thread.
The crashes themselves are an "expected" problem with the Java plugin. The question we need to solve (urgently) is why these are not being marked as plugin-process crashes.
Alright, I'll have a look at the code that's populating those crash reports. BTW looking through other reports I've noticed that that having a 0s uptime is not that uncommon: https://crash-stats.mozilla.com/search/?uptime=0&_sort=-date&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature So either it's true (even though it's strange) or we have a bug where we do not set the uptime correctly under certain conditions. Those conditions don't seem specific to this bug though. Leaving the NI.
Assignee: nobody → gsvelto
Status: NEW → ASSIGNED
I've noticed that the reports are missing a bunch of fields, not just ProcessType: PluginFilename, PluginName, PluginVersion and StartupTime are also empty.
OK, here's what all those fields have in common: they're all populated under CrashReporterParent::GenerateChildData() http://hg.mozilla.org/mozilla-central/file/60b340e55efe/dom/ipc/CrashReporterParent.cpp#l115 There's not many failure modes that would lead to CrashReporterParent::GenerateChildData() not writing data out: I don't think it's possible that the method is not being called as the crash wouldn't be informed at all (it seems to live on the same path that leads to NotifyCrashReport()). It is possible that it's hitting some issue when writing to disk though: those fields are the last one to be written out to the .extra file so if something funny happens (e.g. out of space, file locked by some other process, etc...) they won't be written out successfully. Unfortunately unless I have a way to reproduce the issue it's very hard to tell what's going wrong.
Michelle, are any of those crashes (listed in Java Notes) 100% reproducible?
Actually, that perhaps does not matter. Those crashes don't match the pattern bsmedberg initially described.
This has been fixed in bug 1277582.
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1277582
hi, this is marked as duplicate of bug 1277582 which is marked as fixed on 50+. however there are still loads of plugin crashes coming through the infobar that end up in the process_type "browser", like these flash related crashes on 52.0a2: https://crash-stats.mozilla.com/search/?submitted_from_infobar=__true__&signature=^npswf&product=Firefox&version=52.0a2&process_type=browser#facet-signature
(In reply to [:philipp] from comment #18) > hi, this is marked as duplicate of bug 1277582 which is marked as fixed on > 50+. however there are still loads of plugin crashes coming through the > infobar that end up in the process_type "browser", like these flash related > crashes on 52.0a2: > https://crash-stats.mozilla.com/search/ > ?submitted_from_infobar=__true__&signature=^npswf&product=Firefox&version=52. > 0a2&process_type=browser#facet-signature Then it's not a duplicate; it seemed very similar but apparently it's not :-/ Reopening.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Whiteboard: [fce-active] → [fce-active-legacy]
You need to log in before you can comment on or make changes to this bug.