For crash-stats, here's a sample crash of the GMP plugin (an
artificially-induced crash):
https://crash-stats.mozilla.com/report/index/4d802ab8-0e03-4531-afc9-5ade22140820
These crashes can be identified by ProcessType=plugin and
PluginFilename=gmpopenh264 in the metadata.
Here is a supersearch link for OpenH264 crashes (use the Signature facet
tab):
https://crash-stats.mozilla.com/search/?product=Firefox&plugin_filename=gmpopenh264&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform
RecvCrashPluginNow is our testing function to crash the plugin (to make
sure that crash reporting works) and is not a signal of a real issue.
There are a handful (7) of crashes which look "real". Because these are
release builds with COMDAT-folding, the crash stacks are going to look a
bit bogus. For example looking at
https://crash-stats.mozilla.com/report/index/eb8a8381-dafb-4d04-abb8-a5a1c2140818:
Obviously PGMPChild::OnMessageReceived should never be calling into
dom::Telephony. However it's probably some other actor in the GMP IPDL
tree that has the same method code. It would be hard to debug without
looking at the callsite (PGMPChild::OnMessageReceived) which is
generated code.
Overall, I don't think we have any particular worries about OpenH264
crash rates, but we should watch them for spikes. At this week's
crashkill meeting, Kairo volunteered to set up some regular reports so
that it would easy to monitor this separately from the rest of the
browser/plugin crashes. That may take a few weeks, though.
--BDS
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
