Apport

Differences between revisions 42 and 73 (spanning 31 versions)
Revision 42 as of 2009-03-06 08:07:07
Size: 13988
Editor: p579DE82C
Comment:
Revision 73 as of 2016-09-22 10:16:18
Size: 16446
Editor: cjwatson
Comment: "bzr get" synonym is deprecated; prefer "bzr branch"
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Available languages:[[https://wiki.ubuntu.com/Apport_it| Italiano]],
Line 3: Line 5:
= Apport - Automatic crash reports =

=
= What is this all about? ==
= What is this all about? =
Line 24: Line 24:
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? ==
We are sure 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? =
Line 35: Line 34:
  {{attachment:apport-gtk-desktopfile.png}}

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:

  {{attachment:apport-async-crash.png}}

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:

  {{attachment:apport-gtk-report.png}}

Experienced users can also take a look into the report content:

  {{attachment:apport-gtk-report-details.png}}

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

The automatic crash interception component of apport is disabled by default in stable releases for a number of reasons:
  {{attachment:apport_crash_nodetails.png}}

You can click on "Show Details..." to see what data it collected:

  {{attachment:apport_crash_details.png}}

If the user leaves the "Send error report" checkbox enabled, Apport 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 =

== Why is it disabled? ==

Apport is not enabled by default in stable releases, even if it is installed. The automatic crash interception component of apport is disabled by default in stable releases for a number of reasons:
Line 78: Line 50:
 This is mitigated by the fact that it presents you what will be sent to the bug tracker, and that all crash report bugs are private by default, limited to [[https://edge.launchpad.net/~ubuntu-crashes-universe|the Ubuntu bug triaging team]]. We can reasonably expect developers and technically savvy users, who run the development release, to be aware of this and judge whether it is appropriate to file a crash report. But we shouldn't assume that every Ubuntu user of stable releases is able to do so.  This is mitigated by the fact that it presents you what will be sent to the bug tracker, and that all crash report bugs are private by default, limited to [[https://launchpad.net/~ubuntu-crashes-universe|the Ubuntu bug triaging team]]. We can reasonably expect developers and technically savvy users, who run the development release, to be aware of this and judge whether it is appropriate to file a crash report. But we shouldn't assume that every Ubuntu user of stable releases is able to do so. In 12.04 and up this is transparently handled by whoopsie, see ErrorTracker.
Line 87: Line 59:
== I'm a developer. How do I use these crash reports? ==

=== Report format ===
'''Note''' apport does not trap SIGABRT signals. If you are getting such a signal, then please see DebuggingProgramCrash.

== Ubuntu 11.10 and earlier ==
 * If you want to debug a specific program once, just do:
 {{{
sudo service apport start force_start=1
}}}
/* "service" is deprecated. I think a better command will be "sudo start apport force_start=1" */

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

== Ubuntu 12.04 and later ==

Starting with 12.04, Apport itself is running at all times because it collects crash data for whoopsie (see ErrorTracker). However, the crash interception component is still disabled. To enable it permanently, do:
{{{
sudo nano /etc/apport/crashdb.conf
}}}
... and '''add a hash symbol # in the beginning''' of the following line:
{{{
        'problem_types': ['Bug', 'Package'],
}}}
To disable crash reporting just remove the hash symbol.

= I'm a developer. How do I use these crash reports? =

== Report format ==
Line 94: Line 98:
DistroRelease: Ubuntu 6.10 DistroRelease: Ubuntu 12.04
Line 113: Line 117:
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. Only a tiny subset of the available fields are shown here. Apport reports include a core dump in a compressed and encoded format, which is useful for post-mortem debugging and post-mortem generation of a symbolic stack trace.
Line 117: Line 121:
=== Fields ===
Some fields warrant further details:
 * '''SegvAnalysis''': when examining a Segmentation Fault (signal 11), Apport attempts to review the exact machine instruction that caused the fault, and checks the program counter, source, and destination addresses, looking for any virtual memory address (VMA) that is outside an allocated range (as reported in the ProcMaps attachment).
 * '''SegvReason''': a VMA can be read from, written to, or executed. On a SegFault, one of these 3 CPU actions has taken place at a given VMA that either not allocated, or lacks permissions to perform the action. For example:
  * {{{SegvReason: reading NULL VMA}}} would mean that a NULL pointer was most likely dereferenced while reading a value.
  * {{{SegvReason: writing unknown VMA}}} would mean that something was attempting to write to the destination of a pointer aimed outside of allocated memory. (This is sometimes a security issue.)
  * {{{SegvReason: executing writable VMA [stack]}}} would mean that something was causing code on the stack to be executed, but the stack (correctly) lacked execute permissions. (This is almost always a security issue.)
Line 118: Line 130:
=== Tools === == Tools ==
Line 122: Line 134:
 * '''Ubuntu Bug Patterns''': [[ http://bazaar.launchpad.net/~ubuntu-bugcontrol/apport/ubuntu-bugpatterns/files | These ]] are patterns for packages (writable by Ubuntu Bug Control) that prevent bugs from being filed by apport. Complete details are found in the [[ http://bazaar.launchpad.net/~ubuntu-bugcontrol/apport/ubuntu-bugpatterns/annotate/head%3A/README | README ]].
Line 128: Line 141:
== How does it work internally? ==

=== Crash interception ===

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.

=== Backend ===
= How does it work internally? =

== Crash interception ==

Apport uses `/proc/sys/kernel/core_pattern` to directly pipe the core dump into
apport:

{{{
$ cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport %p %s %c
$
}}}

Note that even if `ulimit` is set to disabled core files (by specyfing a core file size of zero using `ulimit -c 0`), apport will ''still'' capture the crash.

For intercepting Python crashes it installs a `/etc/python*/sitecustomize.py` to call apport on unhandled exceptions.

=== Example ===

Apport is even able to capture core files if PID 1 (Upstart) dies:

 1. If Upstart detects an internal inconsistency, it raises the `SIGABRT` signal.
 1. The Upstart crash handler is called on `SIGABRT`.
 1. Upstart crash handler forks a child process.
 1. The Upstart child process re-raises the signal which results in the child exiting abnormally.
 1. The kernel detects the child process has exited abnormally and calls `apport`, piping the core file to apports standard input (due to `/proc/sys/kernel/core_pattern`).
 1. `apport` writes the core file to disk in `/var/crash/`.
 1. PID 1 waits for its child to terminate (which only happens once `apport` has finished writing the core file).
 1. PID 1 exits.
 1. kernel panics.
 1. On next boot, Whoopsie will detect the crash file and process it.

== Backend ==
Line 140: Line 177:
=== Frontend invocation === == Frontend invocation ==
Line 144: Line 181:
== Launchpad-based auto-retracer ==

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 [[https://lists.ubuntu.com/archives/ubuntu-devel/2007-March/023440.html|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
The frontend then collects additional information like package versions, package file checksums, or OS version, and calls all matching package hooks.

To disable this, you can run `gsettings set com.ubuntu.update-notifier show-apport-crashes false` (as your ordinary desktop user).

= Launchpad-based auto-retracer =

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` or `need-amd64-retrace`. See the [[https://lists.ubuntu.com/archives/ubuntu-devel/2007-March/023440.html|announcement]].

= Per-package Apport Hooks =

It is possible for packages to specify information gathered from the system and included in the bug report. These are done by apport hooks contained in packages.
For some useful examples see:

 * source_xorg.py - adds additional log files and hard
ware details to bug reports
Line 154: Line 195:

in {{{/usr/share/apport/package-hooks}}} .
 * source_totem.py - asks the reporter questions and gathers different information based on responses

in {{{/usr/share/apport/package-hooks}}}. There is also a [[ http://wiki.ubuntu.com/Apport/PackageHooks | list ]] of packages providing apport hooks.
Line 159: Line 201:
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
 ||Hook||Description||Release||
 ||<rowstyle="background-color: #FFFFE0;">source_xorg.py||Xorg debugging logs|| Intrepid ||
 ||<rowstyle="background-color: #FFFFE0;">firefox-3.0.py||Firefox debugging logs|| Intrepid ||
 ||<rowstyle="background-color: #FFFFE0;">source_linux.py||Linux Kernel debugging logs|| Intrepid ||
 ||<rowstyle="background-color: #FFFFE0;">tracker.py||Tracker debugging logs|| Intrepid ||
 ||<rowstyle="background-color: #FFFFE0;">source_network-manager.py||Network Manager & Network Manager applet || Intrepid ||
 ||<rowstyle="background-color: #FFFFE0;">source_jockey.py||Jockey restricted drivers || Intrepid ||
 ||<rowstyle="background-color: #FFFFE0;">source_apport.py||Apport || Intrepid ||
 ||<rowstyle="background-color: #FFFFE0;">source_cups.py||Printing debugging logs|| Jaunty ||
 ||<rowstyle="background-color: #FFFFE0;">usplash.py|| usplash and grub config || Jaunty ||


== 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 [[http://archive.ubuntu.com/ubuntu/pool/main/a/apport/|Ubuntu archive]].
 * apport is developed with the [[http://bazaar-vcs.org|bazaar]] RCS on [[https://launchpad.net/products/apport|Launchpad]]. If you want to contribute to it or develop your own system based on it, you can get your own branch with

    `bzr get` https://code.launchpad.net/~ubuntu-core-dev/apport/ubuntu

 You can also [[http://codebrowse.launchpad.net/~ubuntu-core-dev/apport/ubuntu/changes|browse it online]].

== Future plans ==
If a crash or bug report is submitted through apport, the relevant hooks will be run automatically. If you have an already reported 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]]).

= Use the source, Luke! =

 * You can download the upstream tarball from the [[https://launchpad.net/apport/+download|Launchpad project page]], or the Ubuntu source tarball from the [[http://archive.ubuntu.com/ubuntu/pool/main/a/apport/|Ubuntu archive]].
 * apport is developed with the [[http://bazaar-vcs.org|bazaar]] RCS on [[https://code.launchpad.net/apport|Launchpad]]. If you want to contribute to it or develop your own system based on it, you can get your own branch with `bzr branch lp:apport` for trunk, or `debcheckout -a apport` for the Ubuntu packaging branch.

 You can also [[http://bazaar.launchpad.net/~apport-hackers/apport/trunk|browse it online]].

= Future plans =
Line 193: Line 214:
== Further links == = Further links =
Line 197: Line 218:
 * [[http://codebrowse.launchpad.net/~ubuntu-bugcontrol/apport/ubuntu-bugpatterns/files|Ubuntu apport bug patterns]]  * [[http://bazaar.launchpad.net/~ubuntu-bugcontrol/apport/ubuntu-bugpatterns/files|Ubuntu apport bug patterns]]
 * [[ErrorTracker|Whoopsie]] is a newer Ubuntu crash submission system that doesn't require any input from the user and integrates with Apport
Line 200: Line 222:
 * [[ BrianMurray | Brian Murray ]] gave a [[ https://wiki.ubuntu.com/MeetingLogs/devweek0909/ApportPkgHooks | class ]] at Ubuntu Developer week regarding writing package hooks.
 * Integration using LaunchpadIntegration: [[https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation/Coding#LPI]]

Available languages:Italiano,

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 are sure 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:

  • apport_crash_nodetails.png

You can click on "Show Details..." to see what data it collected:

  • apport_crash_details.png

If the user leaves the "Send error report" checkbox enabled, Apport 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

Why is it disabled?

Apport is not enabled by default in stable releases, even if it is installed. The automatic crash interception component of apport is disabled by default in stable releases for a number of reasons:

  1. Apport collects potentially sensitive data, such as core dumps, stack traces, and log files. They can contain passwords, credit card numbers, serial numbers, and other private material.

    This is mitigated by the fact that it presents you what will be sent to the bug tracker, and that all crash report bugs are private by default, limited to the Ubuntu bug triaging team. We can reasonably expect developers and technically savvy users, who run the development release, to be aware of this and judge whether it is appropriate to file a crash report. But we shouldn't assume that every Ubuntu user of stable releases is able to do so. In 12.04 and up this is transparently handled by whoopsie, see ErrorTracker.

  2. During the development release we already collect thousands of crash reports, much more than we can ever fix. Continuing to collect those for stable releases is not really useful, since
    • The most important crashes have already been discovered in the development release.
    • The less important ones are not suitable for getting fixed in stable releases (see https://wiki.ubuntu.com/StableReleaseUpdates

    • Asking users to send crash reports to us is insincere, since we can't possibly answer and deal with all of them.
  3. Data collection from apport takes a nontrivial amount of CPU and I/O resources, which slow down the computer and don't allow you to restart the crashed program for several seconds.

Note apport does not trap SIGABRT signals. If you are getting such a signal, then please see DebuggingProgramCrash.

Ubuntu 11.10 and earlier

  • If you want to debug a specific program once, just do:
    sudo service apport start force_start=1

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

Ubuntu 12.04 and later

Starting with 12.04, Apport itself is running at all times because it collects crash data for whoopsie (see ErrorTracker). However, the crash interception component is still disabled. To enable it permanently, do:

sudo nano /etc/apport/crashdb.conf

... and add a hash symbol # in the beginning of the following line:

        'problem_types': ['Bug', 'Package'],

To disable crash reporting just remove the hash symbol.

I'm a developer. How do I use these crash reports?

Report format

apport internally uses the standard Debian control syntax for reports, i. e. keeps everything in a flat file that looks like this:

DistroRelease: Ubuntu 12.04
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 encoded 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.

Fields

Some fields warrant further details:

  • SegvAnalysis: when examining a Segmentation Fault (signal 11), Apport attempts to review the exact machine instruction that caused the fault, and checks the program counter, source, and destination addresses, looking for any virtual memory address (VMA) that is outside an allocated range (as reported in the ProcMaps attachment).

  • SegvReason: a VMA can be read from, written to, or executed. On a SegFault, one of these 3 CPU actions has taken place at a given VMA that either not allocated, or lacks permissions to perform the action. For example:

    • SegvReason: reading NULL VMA would mean that a NULL pointer was most likely dereferenced while reading a value.

    • SegvReason: writing unknown VMA would mean that something was attempting to write to the destination of a pointer aimed outside of allocated memory. (This is sometimes a security issue.)

    • SegvReason: executing writable VMA [stack] would mean that something was causing code on the stack to be executed, but the stack (correctly) lacked execute permissions. (This is almost always a security issue.)

Tools

There are several tools available for working with a crash report:

  • Ubuntu Bug Patterns: These are patterns for packages (writable by Ubuntu Bug Control) that prevent bugs from being filed by apport. Complete details are found in the README.

  • 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?

Crash interception

Apport uses /proc/sys/kernel/core_pattern to directly pipe the core dump into apport:

$ cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport %p %s %c
$ 

Note that even if ulimit is set to disabled core files (by specyfing a core file size of zero using ulimit -c 0), apport will still capture the crash.

For intercepting Python crashes it installs a /etc/python*/sitecustomize.py to call apport on unhandled exceptions.

Example

Apport is even able to capture core files if PID 1 (Upstart) dies:

  1. If Upstart detects an internal inconsistency, it raises the SIGABRT signal.

  2. The Upstart crash handler is called on SIGABRT.

  3. Upstart crash handler forks a child process.
  4. The Upstart child process re-raises the signal which results in the child exiting abnormally.
  5. The kernel detects the child process has exited abnormally and calls apport, piping the core file to apports standard input (due to /proc/sys/kernel/core_pattern).

  6. apport writes the core file to disk in /var/crash/.

  7. PID 1 waits for its child to terminate (which only happens once apport has finished writing the core file).

  8. PID 1 exits.
  9. kernel panics.
  10. On next boot, Whoopsie will detect the crash file and process it.

Backend

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.

Frontend invocation

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 frontend then collects additional information like package versions, package file checksums, or OS version, and calls all matching package hooks.

To disable this, you can run gsettings set com.ubuntu.update-notifier show-apport-crashes false (as your ordinary desktop user).

Launchpad-based auto-retracer

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 or need-amd64-retrace. See the announcement.

Per-package Apport Hooks

It is possible for packages to specify information gathered from the system and included in the bug report. These are done by apport hooks contained in packages. For some useful examples see:

  • source_xorg.py - adds additional log files and hardware details to bug reports
  • usplash - ignores crashes in specific code paths
  • source_totem.py - asks the reporter questions and gathers different information based on responses

in /usr/share/apport/package-hooks. There is also a list of packages providing apport hooks.

Please see /DeveloperHowTo for further information.

If a crash or bug report is submitted through apport, the relevant hooks will be run automatically. If you have an already reported 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).

Use the source, Luke!

  • You can download the upstream tarball from the Launchpad project page, or the Ubuntu source tarball from the Ubuntu archive.

  • apport is developed with the bazaar RCS on Launchpad. If you want to contribute to it or develop your own system based on it, you can get your own branch with bzr branch lp:apport for trunk, or debcheckout -a apport for the Ubuntu packaging branch.

    You can also browse it online.

Future plans

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

Further links

Apport (last edited 2017-05-25 20:03:48 by penalvch)