Revision 1 as of 2006-11-27 14:22:13

Clear message

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.


We want to extend the range of crashes that apport can process, as well as make the process more efficient.


In Edgy we do not get any useful information from crashed processes which cannot write into their cwd (like notification-daemon) or are terminated with SIGABRT due to an exception (like interpreted Python/Mono programs). To accelerate processing, the core dump should not be temporarily written to the disk at all.

Use cases

  • notification-daemon, a user-session daemon which does a chmod('/') at program start, crashes. apport is able to get a proper core dump and extract useful information from it.

  • serpentine crashes with an unhandled Python exception. apport picks this up and creates a report which contains the Python backtrace.
  • F-Spot crashes. apport creates a report which contains the Mono backtrace.


  • Have the kernel pipe the core dump to apport instead of writing it to the disk temporarily. This is both faster and also makes core dump creation independent from cwd writability.
  • Add hooks to most common interpreters (Python/Mono) to intercept unhandled exceptions and create an apport report.



In 2.6.19, Andi Kleen committed a new feature for /proc/sys/kernel/core_pattern: it can start with a pipe ('|') now, in which case the remainder is interpreted as a path. That path is executed, and the core dump is piped to stdin. We will base our solution on this, however, two modifications are still required:

  • 2.6.19 upstream does not support arguments for the called program. In order to avoid having to write and process the core dump, we want to use the %p and %e macros. Thus the kernel should first split core_pattern value at spaces, consider the first field as program path, the rest as arguments, and, after splitting, perform macro substitution (this will work correctly with %e containing spaces). Andi Kleen would welcome to see this fixed upstream, but doesn't want to work on that himself.

  • We do not want to generally enable core dumps, thus we need to leave the default ulimit -c to 0. However, the apport init script needs a way to modify the global ulimit -c, similar to edgy's sys/kernel/crashdump_size sysctl. We should find a solution that can go upstream, so that eventually apport (and similar crash interception projects) work on a stock upstream kernel across all distributions. TODO: discuss with kernel maintainers


Apport needs to read the core dump from stdin if the core dump path is '-' (this is already implemented in Feisty). The init script needs to set the appropriate core_pattern and raise the global default ulimit -c to 200 MB on start, and do the reverse on stop.

We will also add a new Python package apport (shipped in python-apport deb) which provides a default Python exception handler that creates an apport report (this is already implemented in Feisty).

Python 2.4/2.5 should try to import apport.python_hook, and if that succeeds, call the apport exception handler (python_hook.install()). See for details and patch.


To be discussed.

Data preservation and migration

Not required.