Simplified crash reporting via ABRT Server
Summary
This feature provides simplified crash reporting along with fully featured server for handling user-reported problems.
Owner
- Name: ABRT Development Team
- Email: crash-catcher at lists.fedorahosted.org
Current status
- Targeted release: Fedora 18
- Last updated: 2012-10-08
- Percentage of completion: 100%
- Server is receiving roughly 1000 reports per day.
- Kernel oops support added.
- As of mid-August, no outstanding issues are remaining.
- ABRT Server is publicly deployed [1]
- Updated client packages are present in Fedora 18.
- Package crash report uploading works properly.
Detailed Description
Current crash reporting process is quite complicated and requires number of time consuming steps to finish. This feature adds number of improvements which should simplify the process leading to more submissions from Fedora users.
Benefit to Fedora
- Improved privacy of Fedora users.
- Less problematic problem reporting.
- More accurate statistics of misbehaving applications.
Scope
Client side
Package crash is handled by ABRT daemon and core backtrace is generated. This backtrace contains only package build_id, function name, function hash, binary path and offset within binary. With this approach, there is no need to install debuginfo packages or use retrace server for backtrace generation.
Core backtrace doesn't contain any data which reduces the risk of sending sensitive data like passwords or credit card numbers to the public bugzilla allowing user to send us the backtrace automatically.
Sample core backtrace [2] is provided.
Reporting
Support for new simplified reporting using core backtrace has to be implemented in client utilities. This is done in reporter-ureport tool, which bundles all the information required by the ABRT Server into small json file, which is then sent to the public instance.
This json report is called μReport. Structure of this file is well-defined in ABRT Project Document [3], section 5.4.8.
Sample μReport [4] is provided.
This process should be invisible for end-user as it's handled by abrt-gui.
Server side
Server should accept valid μReport and store it in the database for further processing. Currently, this includes retracing (adding source file and line number information to the backtrace) and deduplication (merging with other similar reports).
After processing, this information is accessible via web interface of the server [1].
Web interface provides overview of incoming reports, statistics of most problematic components and detailed display of reported problems.
Deduplication and clustering of the reports allows the server to provide more accurate data about cause of the crash – if the crash is caused by bug in a library, server will not blame the components which are using the library but the library itself.
How To Test
Current set of ABRT packages is required for testing. Please verify that you have libreport-plugin-ureport package installed.
Required steps
If you already have some application crashes caught by ABRT, you can skip the first step.
- Force the crash of your favorite package - to do so, run the application and use
pkill -SIGSEGV <application name>to crash it. - Try reporting newly created problem via abrt-gui.
Expected results
- Reporting should succeed.
- After few minutes, it should be possible to view your report on the public instance [1].
User Experience
- Users: reporting process is quick and easy, there is no need to check the backtrace for sensitive data nor posses a bugzilla account.
- Maintainers: server provides accurate statistics of crashes of their components, server blames problematic libraries instead of applications which are using them.
Dependencies
None
Contingency Plan
None necessary, rest of the ABRT functionallity remains untouched – it is still possible to use old ways of reporting.
Documentation
Release Notes
- Fedora's bug reporting tool (ABRT) now uses new, simplified way of reporting user problems. These reports are now handled by ABRT Server, which also provides statistics and clustering of the reports, giving maintainers more accurate data about the problem.