Apport - Automatic crash reports
What is this all about?
Debugging program crashes without any automated tools has been pretty time consuming and hard for both developers and users. Many program crashes remain unreported or unfixed because:
- Many crashes are not easily reproducible.
End users do not know how to prepare a report that is really useful for developers, like building a package with debug symbols, operating gdb, etc.
- A considerable part of bug triage is spent with collecting relevant information about the crash itself, package versions, hardware architecture, operating system version, etc.
- There is no easy frontend which allow users to submit detailed problem reports.
- Existing solutions like bug-buddy or krash are specific to a particular desktop environment, are nontrivial to adapt to the needs of a distribution developer, do not work for crashes of background servers (like a database or an email server), and do not integrate well with existing debug packages that a distribution might provide.
Apport is a system which
- intercepts crashes right when they happen the first time,
- gathers potentially useful information about the crash and the OS environment,
- can be automatically invoked for unhandled exceptions in other programming languages (e. g. in Ubuntu this is done for Python),
- can be automatically invoked for other problems that can be automatically detected (e. g. Ubuntu automatically detects and reports package installation/upgrade failures from update-manager),
- presents a UI that informs the user about the crash and instructs them on how to proceed,
- and is able to file non-crash bug reports about software, so that developers still get information about package versions, OS version etc.
We hope that this will lead to a much better level of quality assurance in the future.
If you want to make crash reports of your software even more useful when being reported through apport, please see /DeveloperHowTo.
What does it look like for users?
The user side of apport is designed to be extremely simple and as unannoying as possible.
If any process in the system dies due to a signal that is commonly referred to as a 'crash' (segmentation violation, bus error, floating point exception, etc.), or e. g. a packaged Python application raises an uncaught exception, the apport backend is automatically invoked. It produces an initial crash report in a file in /var/crash/ (the file name is composed from the name of the crashed executable and the user id). If the crashed process belongs to the user who is currently logged in, or it belongs to a system process and the user is an administrator, apport informs the user about the crash and offers to report the problem:
If a user process crashes while the user is not currently logged in, update-notifier will present a notification when the user starts a desktop session the next time:
Clicking on the icon will cause the same frontend to appear. The notification is also shown for crashes of system processes; since they need the frontend being invoked as root, immediately starting it through gksu would be too disruptive.
Now apport collects various debug information and asks the user what to do with it:
Experienced users can also take a look into the report content:
If the user chooses "Send report", apport-gtk uploads the collected information to the bug tracking system. After that it opens the packages' bug filing page with a sensible default bug title and leaves the rest of bug filing process to the web UI.
How to enable apport
Apport is not enabled by default in stable releases, even if it is installed. There are two ways to enable it.
- If you want to debug a specific program once, just do:
sudo force_start=1 /etc/init.d/apport restart
Then you can simply trigger the crash again, and Apport's dialog will show up with instructions to report a bug with traces. Apport will be automatically disabled on next start.
If you are triaging bugs, this is the best way to get traces from bug reporters that didn't use Apport in the first place.
- To enable it permanently, do this:
sudo nano /etc/default/apport
... and change enabled from "0" to "1".
** Why is this disabled if QA is one of our goals, and even so why isn't there a gui to enable it for less experiences users
*** It is only disabled by default in stable releases because it increases system load and crash reports are likely to duplicates of ones already reported by people testing the development release.
** I guess if we're talking a 'major' system load increase then its best to wait until such time as that load is significantly less, but even so thats a shame as QA depends on reports from everyone not just devs so I presume this decision was made due to a very large increase ?--regardless I think its naive to suggest that reports would be 'duplicates' when we can't possibly be insinuating that every type of hardware/software combo has been tested not only due to linux distro fragmentation, but also due to migrating windows users.
I'm a developer. How do I use these crash reports?
apport internally uses the standard Debian control syntax for reports, i. e. keeps everything in a flat file that looks like this:
DistroRelease: Ubuntu 6.10 ExecutablePath: /usr/bin/gcalctool Package: gcalctool 5.8.24-0ubuntu2 ProcCmdline: gcalctool ProcEnviron: SHELL=/bin/bash PATH=/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games LANG=de_DE.UTF-8 StackTrace: [...] #0 0x00002ae577bb37bf in poll () from /lib/libc.so.6 No symbol table info available. #1 0x00002ae57786991e in g_main_context_check () from /usr/lib64/libglib-2.0.so.0 No symbol table info available. [...] CoreDump: base64 eJzsXQmcFMXV7+XGA0dBREVoDxSPXQYEB...
Only a tiny subset of the available fields are shown here. Apport reports include a core dump in a compressed and unencoded format, which is useful for post-mortem debugging and post-mortem generation of a symbolic stack trace.
However, when uploading the data to a bug tracking system, a different format can be used. e. g. when using Launchpad, the data is uploaded in Multipart/MIME format so that the small parts land directly in the bug summary and the big parts become separate bug attachments.
There are several tools available for working with a crash report:
apport-unpack: Unpack a report into single files (one per attribute). This is most useful for extracting the core dump. Please see the manpage for further details. This tool is not necessary when working with Launchpad, since it already splits the parts into separate attachments.
apport-retrace: Regenerate stack traces of a report. If you supply the -g option, this tool will automatically download available debug symbol packages and use them to generate a symbolic stack trace. The manpage explains the functionality and all available options in detail.
python-problem-report: This package ships a Python module problem_report which provides general dictionary access to a crash report and loading/saving methods (not specific to apport reports).
python-apport: This ships a Python package apport which encapsulates core functionality of apport and is specific to crash and bug reports. You can use it to implement your own frontends and backends.
apport-collect: This checks the source package(s) of an existing Launchpad bug, runs apport hooks for them, and uploads their collected information back to the bug report.
How does it work internally?
The Ubuntu 6.10 Linux kernel has a patch to call a usermode helper in the event of a crash (in kernel terms: whenever the process would dump its core if ulimit -c is nonzero). This usermode helper is configured in /proc/sys/kernel/crashdump-helper. To avoid cluttering the disk with core dumps, the default ulimit is kept at 0, and instead the kernel introduces a second size limit for temporary core dumps in /proc/sys/kernel/crashdump-size.
Ubuntu 7.04 uses kernel 2.6.19's new feature of using /proc/sys/kernel/core_pattern with a pipe. The core dump is directly piped into apport, and the other information (such as the signal number and PID) is passed through environment variables.
In order to keep the delay and CPU/IO impact as low as possible, /usr/share/apport/apport only collects data which has to be acquired while the crashed process still exists: information from /proc/pid, the core dump, the executable path, and the signal number. The report is written to /var/crash/executable_path.uid.crash.
In Gnome, update-notifier keeps an inotify watch on /var/crash. Whenever there is something new, it calls /usr/share/apport/apport-checkreports. If there are new reports, it calls /usr/share/apport/apport-gtk, which is the frontend shown in the screenshots above.
The Canonical data center runs a service which automatically retrace bugs with apport. By tagging the bugs according to architecture in Launchpad, a retrace will be done and the tag will be removed. Tags that are used are need-i386-retrace, need-amd64-retrace or need-ppc-retrace. See the announcement.
Per-package Apport Hooks
For examples on how to include apport-specific hooks in packages, see:
- ubiquity - adds additional debugging details to crash report
- usplash - ignores crashes in specific code paths
in /usr/share/apport/package-hooks .
Please see /DeveloperHowTo for further information.
If a crash or bug report is submitted through apport, those will be run automatically. If you have an already existing bug that was filed without apport, and you are interested in the information from those hooks, you can ask the bug reporter to use apport-collect bugnumber (see #Tools).
Apport Hooks available
This is a list of the Apport Hooks available since Intrepid
Xorg debugging logs
Firefox debugging logs
Linux Kernel debugging logs
Tracker debugging logs
Network Manager & Network Manager applet
Jockey restricted drivers
Printing debugging logs
usplash and grub config
Use the source, Luke!
On Ubuntu, you can use apt-get source apport to get the complete source package.
You can download the source tarball from the Ubuntu archive.
You can also browse it online.
Various improvements to performance, better tools to work with reports, and integration of more languages (Mono/Python stack traces, assertion messages, etc.) See the relevant specification.
Please do not hesitate to report bugs and feature requests to the bug tracker.