Closed pocmo closed 5 years ago
@Dexterp37 FYI. Good crash statistics is something that has haunted us for a while. Since we can generate custom pings with Glean I think we could just build such a crash ping.
A small technical challenge here is that the crash reporter is running in a different process (since the app process crashes) and we should avoid corrupting our data while writing from multiple processes.
@Dexterp37 FYI. Good crash statistics is something that has haunted us for a while. Since we can generate custom pings with Glean I think we could just build such a crash ping.
This is very interesting. We are starting to have conversations around crash data using glean. I'll make sure you'll be part of these conversations as well :)
A small technical challenge here is that the crash reporter is running in a different process (since the app process crashes) and we should avoid corrupting our data while writing from multiple processes.
Yes, this sounds like an interesting technical challenge. I filed bug 1522461 on our end to track this.
From the GV meeting: GV catches native code crashes; In non-GV apps with native code (e.g. Lockbox; or a WebView-based browser) we may not be able to send a crash ping since we do not catch those crashes.
If we do a crash ping, it would be good to have a 'component' classifier in it, so that we can see where the crash originated. Could be a string that we fill in, like 'frontend', 'geckoview', 'glean', etc.
Description
We want to have good crash statistics (e.g. crash rates) in order to:
Our current crash reporting tools are insufficient:
Resources
Target
Tasks
Dependencies
┆Issue is synchronized with this Jira Task