Ubuntu Wiki

Status

• Created: Date(2005-04-23T05:46:42Z) by MattZimmermanBR

• Priority: MediumPriorityBR

• People: MartinPittLead, MichaelVogtSecondBR

• Contributors: MattZimmermanBR

• Interested: MartinPitt, LaMontJones, MichaelVogt, SebastienBacherBR

• Status: BrainDump, BreezyGoal, UduBof, DistroSpecificationBR

• Branch: BR

• Malone Bug: BR

• Packages: BR

• Depends: BR

• UduSessions: 1, 4, 8, etc BR

Introduction

Streamline the process of collecting data for common end-user problems, so that they can be prioritized and addressed

Rationale

Scope and Use Cases

• When a program crashes, send a report (with an absolute minimum of user interaction)
• Extract and store debug symbols from standard builds, and store them in a centralized repository for use in analyzing these reports
• When a package installation, removal or upgrade fails, send a report (with an absolute minimum of user interaction)
• When a kernel panic/oops/etc. occurs, send a report (with an absolute minimum of user interaction)

• [http://www.cs.wisc.edu/cbi/ Cooperative bug isolation]?

Implementation Plan

1. The debugging symbols needs to be extracted during build time and put into a central server so that they can be downloaded. Storing the debug symbols in the packages themself is not feasible because it would make the size of the packages explode. But the debug symbols needs to be available to make usefull backtraces from a crashed application.

1. A problem is how to report the crash to the user. A breezy install will no longer have a MTA installed and if a daemon/non-interactive application crashs it can't report the problem to the user (even when he is logged in and runs X it is probably not possible to connect to the display). The solution for this problem is to think about a generic event notifier applet (probably usefull for other things like: "disk full", "temperature too hot" etc too) based on dbus.

1. A common frontend needs to be developed that will present the crash/problem to the user and is able to collect the debug symbols for a usefull report. It then must be able to send it to a central server that collects the bugreports. A daemon on the server must remove duplicates and report the problems to Malone. Http will be used to send the reports to the server.

1. When a package install/upgrade/remove fails this should be reported too. This needs to be hooked into dpkg.

1. Kernel need ksymoops to get the debug information. There is a kernel crashdump project (http://lkcd.sourceforge.net/) that should be investigated.

1. Fedora is using a similar scheme (ubuntu #8149) that may be interessting for us too.

Data Preservation and Migration

Packages Affected

User Interface Requirements

Outstanding Issues

UDU BOF Agenda

• What data needs to be submitted?

  • core dump; MartinPitt: core dumps are difficult to handle since you need to have exactly the same libraries; a good stack trace is already very helpful, much smaller, and easier to handle

  • identifying information for all code involved (package versions? filenames? md5sums?)
  • additional run-time information (environment, command line arguments, user comments for reproduction)
• How should the debug symbol extraction work?
• Handling and caching of debug symbols on client
• Automated bug reporting to Malone

UDU Pre-Work

• MartinPitt already has a prototype for crash reports, see AutomatedCrashReporting