Some plugin-process crashes are not marked as plugin crashes (submitted-from-infobar related?)

REOPENED
Assigned to

Status

()

P2
normal
REOPENED
2 years ago
8 months ago

People

(Reporter: benjamin, Assigned: gsvelto)

Tracking

({qawanted})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fce-active-legacy])

(Reporter)

Description

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

Comment 1

2 years ago
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

Comment 2

2 years ago
Ryan, any chance softvision could do a round of e10s testing with java plugins looking for crashy test cases?
Blocks: 1249209
Flags: needinfo?(jmathies) → needinfo?(ryanvm)
Keywords: qawanted

Updated

2 years ago
Flags: needinfo?(jmathies)
Sure.
Flags: needinfo?(ryanvm) → needinfo?(mfunches)
ack: we have been testing Flash Plugin (Blocking/cp2) this week; I will update test workbook with this request.
Flags: needinfo?(mfunches)
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

Comment 6

2 years ago
(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!
Flags: needinfo?(jmathies)
(Reporter)

Comment 7

2 years ago
Gabriele is this possibly the same as the bug you fixed about plugin crashes?
Flags: needinfo?(gsvelto)
Priority: -- → P2
(Assignee)

Comment 8

2 years ago
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.
Flags: needinfo?(gsvelto)
(Reporter)

Comment 9

2 years ago
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.
Flags: needinfo?(gsvelto)
(Assignee)

Comment 10

2 years ago
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.
Whiteboard: [fce-active]
(Assignee)

Updated

2 years ago
Assignee: nobody → gsvelto
Status: NEW → ASSIGNED
(Assignee)

Comment 11

2 years ago
I've noticed that the reports are missing a bunch of fields, not just ProcessType: PluginFilename,
PluginName, PluginVersion and StartupTime are also empty.
(Assignee)

Comment 12

2 years ago
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.
Flags: needinfo?(gsvelto)
Michelle, are any of those crashes (listed in Java Notes) 100% reproducible?
Flags: needinfo?(mfunches)
Actually, that perhaps does not matter. Those crashes don't match the pattern bsmedberg initially described.
Flags: needinfo?(mfunches)
(Assignee)

Comment 15

2 years ago
It seems we have a culprit, see bug 1277582 comment 66.
See Also: → bug 1277582

Updated

2 years ago
Duplicate of this bug: 1318136
(Assignee)

Comment 17

2 years ago
This has been fixed in bug 1277582.
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1277582

Comment 18

2 years ago
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
Flags: needinfo?(gsvelto)
(Assignee)

Comment 19

2 years ago
(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
Flags: needinfo?(gsvelto)
Resolution: DUPLICATE → ---
Whiteboard: [fce-active] → [fce-active-legacy]
You need to log in before you can comment on or make changes to this bug.