CrashReporting
Launchpad entry: https://launchpad.net/distros/ubuntu/+spec/crash-reporting
Packages affected apport, Malone
Summary
Currently apport sends crash reports as public Malone bugs. We will improve this process to avoid exposing potentially sensitive data to the public and avoid sending unwanted bug email to developers.
Because a few bugs cause most crashes, this system should eventually involve a database of crash reports, automatically aggregated by type so that developers can allocate their time to the top crashers.
Rationale
The original idea was to create an entirely separate crash database and web frontend for it. However, since we need a lot of the features of a bug tracker (assignments, release tracking, searching, duplication, email/web interaction, getting feedback from reporters), this database will just use Malone in an appropriate way.
We currently do not want bugs to be filed anonymously, because:
- we want to keep the possibility of contacting the reporters for further information,
- the current testing community is large enough to supply us with much more reports that the triagers can handle anyway (and enough bugs to keep the reprocessing infrastructure busy), and
- mostly this would just result in even more duplicates.
Use cases
- Willy was creating a logo for his soccer club in Inkscape when it crashed. Being the family's Ubuntu expert, he feels a responsibility to help improve the system. He's reported one or two bugs in Malone before, though it wasn't a particularly enjoyable experience.
- Millie was logging in to her bank account when Firefox crashed. She's used to clicking the "Send" button for Windows Error Reporting, so she does the same for apport. Her banking password can be found in the crash information, so this needs to be treated confidentially.
Design
New approach of crash bug reporting workflow
- Create Launchpad users which control access to the bug, split by main/restricted and universe/multiverse.
Apport files bugs as private/nonsecurity by default, with only the crash reprocessing bot subscribed (Launchpad user apport, the "Apport retracing service").
The retracing bot generates the symbolic stack traces, handles duplicates (see apport-crash-duplicates), and removes the core dump attachment. Then it subscribes the relevant team to the bug.
- The triaging teams regularly inspect crash reports (preferably prioritized by number of duplicates). After verifying that a stack trace does not contain sensitive information, they can set the bug to "public".
Comparisons to other crash feedback agents
[http://windowsdevcenter.com/pub/a/windows/2004/03/16/wer.html Windows Error Reporting under the covers]
[http://developer.apple.com/technotes/tn2004/tn2123.html Apple TN2123: CrashReporter]
[http://ramikayyali.com/archives/2005/07/26/krash Kool Krashing] (see also [http://amarok.kde.org/blog/archives/4-amaroK-1.2-It-Crashes-Somewhat-Less.html amaroK 1.2 - it crashes somewhat less])
[http://flickr.com/photos/jfpoole/143205824/ Adium Crash Reporter]
Implementation
Create two new Launchpad teams ubuntu-crashes-main (for components main and restricted) and ubuntu-crashes-universe (for components universe and multiverse), set a "black hole" contact email address and put the ubuntu-core-dev, respectively ubuntu-dev teams into it. This avoids sending crash email to these teams (explicit requirement from our desktop team) and allows for later adjustments for accessing crash bugs.
- Malone currently has the ability to set tags in the blob that gets uploaded to the cloakroom. This needs to get extended to mark a bug as private/nonsecurity.
- (design is self-explanatory)
- (design is self-explanatory)