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.
Launchpad entry: apport-mono-crashes
Packages affected: apport, mono
When a CIL (mono) program is terminated with a 'crashy' signal (usually SIGSEGV), capture the C# stack trace and have apport include it into the crash report. In addition, we want apport reports for unhandled exceptions in Mono programs.
In current feisty, apport crash reports for Mono programs only deliver the gdb stacktrace, which is relatively useless. We actually want the Mono C# backtrace, which Mono prints to stderr when a crash happens, but Apport cannot capture stderr.
- F-Spot crashes with a SIGSEGV. Apport creates a report which contains the Mono backtrace and the gdb stack trace.
- Tomboy is terminated with an unhandled exception. Apport creates a report with the Mono backtrace.
- Add a Mono hook to apport which generates the report and collects auxiliary data.
- Add a default exception handler to Mono which calls the Apport hook, if present.
- Store the C# backtrace in the core dump if a Mono application crashes due to a signal.
There are two cases of crashes here: (1) due to an unhandled exception, and (2) due to a crash-related signal (SIGSEGV/SIGBUS/etc.). In both cases, Mono prints out a backtrace by default, which we want to capture for the apport report. The function that prints out the unhandled exception is mono/metadata/object.c:mono_print_unhandled_exception()
(1) Unhandled exception
After printing the stacktrace to stderr (current default behaviour), Mono's default exception handler additionally calls /usr/share/apport/mono-hook pid and pipes the stacktrace to its stdin. mono-hook will collect the usual generic data from /proc and create a proper crash report in /var/crash/.
(2) Crash due to signal reception
Mono's current signal handler already causes the Mono backtrace to be written to stderr. This needs to be changed to:
- write the backtrace to a global variable
- print out that variable to stderr to remain compatible with previous behaviour
Then apport's report_add_gdb_info() can fish out the value of that global variable from the core dump and add it to the report.
Data preservation and migration