Skip to content
Matěj Habrnál edited this page Mar 10, 2015 · 6 revisions

ABRT workflow

Something crashed

When your application crashes, the crash event is handled by one of ABRT’s language or runtime dependent hooks which forwards the crash information to abrt daemon. The daemon stores the data in /var/tmp/abrt and runs a chain of events that for example collect more data about the system, produce backtrace from core dump or notifies a user.

Workflow for reporting

If an user reports a crash (either via gnome-abrt or abrt-cli report) the workflow is the following:

  1. the reporting client sends a uReport [1] to FAF server (http://retrace.fedoraproject.org/faf/) [2] - the FAF server returns whether the crash has already been reported and also might return some kind of a solution text. (For example https://bugzilla.redhat.com/show_bug.cgi?id=1090572).
  2. the reporting client checks the response from the FAF server - the reporting client displays the information returned from the FAF server to the reporter and terminates the reporting process in case there is a bug report for the crash; otherwise the process continues with the 3rd step
  3. the reporter via the reporting client generates backtrace from coredump
  1. the reporting client sends coredump to retrace server (http://retrace.fedoraproject.org/) [3] - the Retrace server sends backtrace back to the reporter's machine
  2. the reporting client downloads all required debuginfo packages to the reporter's machine (it might be GiBs of data) and generates backtrace locally
  1. the reporter manually reviews the crash data and gives the reporting client an explicit permission to publish it - the reporting client provides the report with the tools to simplify this task for him
  2. the reporter via the reporting client reports the crash to Bug Tracker (e.g. https://bugzilla.redhat.com/) [4] - the reporting client creates a new bug in the bug tracking system. If a duplicate bug exists, the reporting client adds a comment to the original bug instead (attach a "better" backtrace if available). The duplicate case can happen only if there was a problem on the FAF server.

Ad 1. send uReport is to FAF server

FAF server is Crash collecting server, also known as ABRT server. Provides accurate statistics of incoming reports and acts as a proxy in front of bugzilla (or any other issue tracker) when it comes to automatic reporting of crashes. It’s designed to receive anonymous μReports and to find clusters of similar reports among them. For reports that are known, user receives fast response containing links to faf’s problem page, issue tracker or an entry from knowledge base, that contains number of well-known issues like usage of proprietary kernel modules or browser crashes caused by unsupported modules.

Ad 2. Generate backtrace from coredump

Generate backtrace can be done either locally or remotely by retrace server. In the first case all required package with debug info will be downloaded and backtrace will be generated. In the second case the coredump will be sent to the retrace server where the backtrace will be generated and after that sent back to the client.

Ad 3. Report to bug tracker (Bugzilla, etc.)

The reporter searches for potential duplicate reports. If no duplicate bug report exist the new bug report is created. Reporter can also fill the URL field with an URL to another bug tracker (e.g. ABRT Server report URL) and add a new comments and attachments to the bug report.

Clone this wiki locally