CrashReporting

Revision 25 as of 2007-05-30 07:39:16

Clear message

Summary

Currently apport sends crash reports as public bugs in Launchpad. 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.

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 Launchpad 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

Authenticated bug filing

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.

New approach of crash bug reporting workflow

  1. Create Launchpad users which control access to the bug, split by main/restricted and universe/multiverse.

  2. Apport files bugs as private/nonsecurity by default, with only the crash reprocessing bot subscribed (Launchpad user apport, the "Apport retracing service").

  3. 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.

  4. 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

Implementation

  1. 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.

  2. 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 (see [https://bugs.launchpad.net/malone/+bug/116367 #116367]).

  3. (design is self-explanatory)
  4. (design is self-explanatory)

Comments

MatthewPaulThomas:

  • "We currently do not want bugs to be filed anonymously" because we get "more reports tha[n] the triagers can handle anyway"? That's circular reasoning. If they were crash reports rather than bug reports, they wouldn't need triaging! Similarly, "this would just result in even more duplicates" wouldn't be a problem, it would be a feature. Developers would instead start with the most-commonly-occurring crashes and report bugs about them, like developers do with other crash-reporting systems.
  • Requiring the person experiencing a crash to get a Launchpad account will bias the results. For example, it will mean Edubuntu-specific software (and other kids' software) is under-represented, because the people using it don't even know what a "bug" is, or may even be prevented from signing up.

MartinPitt responds:

  • I am fully aware that this is not the ultimate solution. Eventually Malone should get a concept of a crash database. This spec is meant to be an intermediate solution for the worst problems we currently have, using the tools that are available today (except fr point 2).

CategorySpec