provide app to generate a crash/bug report

[Martin Pitt]

Binary package hint: apport

We accumulated some specialized helper scripts to generate bug reports in /usr/share/apport/*_hook (currently for apt, gcc, and kernel). More use cases turn up, like generating a report for X.org failures.

This needs to be generalized, so that we have a script which we pass:

 * files to attach
 * arbitrary key/value pairs
 * description
 * report type (default bug)

and which creates a report in /var/crash/, so that the user can ack it.

[Braiam Peguero (braiampe)]

This bug should be marked as the fix has been release.

[Matt Zimmerman (mdz)]

No, this bug is not fixed yet. It's about generalizing scripts like /usr/share/apport/apportcheckresume, gcc_ice_hook, kernel_crashdump, kernel_oops and package_hook.

[Matt Zimmerman (mdz)]

I wish I'd noticed this bug before implementing the Java one and making the problem worse. :-) This is something I'd be interested in working on in my spare time, but I'm not sure what the interface should look like.

Here's what the current scripts do:

apportcheckresume:
- is invoked by apport's upstart job if /var/lib/pm-utils/status exists
- receives no information from the caller
- creates a KernelOops report and attaches some pertinent information
- associates the bug with the kernel package (which has a hook which will do more stuff)

gcc_ice_hook:
- is invoked by gcc itself when an ICE occurs
- receives a path to the compiler executable and a file containing preprocessed output (command line args)
- creates a Bug report and attaches only what it was given
- leaves apport to do the rest (including figure out which package to file on)

kernel_crashdump:
- is invoked by apport's upstart job if /var/crash/vmcore exists
- receives no information from the caller
- creates a KernelCrash report and attaches some pertinent information
- associates the bug with the kernel package (which has a hook which will do more stuff)

kernel_oops:
- is invoked by kerneloops when it detects an oops
- receives a text blob containing the oops data (stdin)
- creates a KernelOops report and attaches some pertinent information
- associates the bug with the kernel package (which has a hook which will do more stuff)

package_hook:
- is invoked by apt when it detects a package install/upgrade failure
- receives a package name, a log file and an error message from the caller (command line args and stdin)
- creates a Package report and attaches the above information
- associates the report with the package which failed
- the general hook has a bunch of logic to further try to find the right package

java_uncaught_exception:
- is invoked by the JVM when a Java program crashes due to an uncaught exception
- receives a list of key/value pairs from the caller and attaches them directly to the report (stdin)
- has some logic to figure out the ExecutablePath based on the URL of the main class (passed in)
- leaves apport to do the rest (including figure out which package to file on)

There isn't really that much common code here that I see, just:

- instantiating the Report object
- adding the information provided by the caller, if any
- calling .add_*_info as appropriate

It might be nice to have a standard way to pass in key/value pairs from the caller, and a convenience function for parsing it and putting it in the report, but that's all that I see which is common. All of the above scripts would still require mostly custom code to do their jobs.

[Bryce Harrington (bryce)]

I also have a couple such scripts, one for capturing X.org crashes, and another for GPU lockups, which I've independently also been thinking might be able to share some code. However the code I think they'd be sharing is just the generic bits pertaining to X.org logs and such; the triggering mechanisms for the two scripts are quite distinct. There is little in them that I think would be of value to other crash handlers in general. What little there is probably could just be rolled into the apport hook utils library itself.

Maybe it'd be sufficient just to make a thorough tutorial on how to write one. This could then outline in a general way how to set up udev hooks, how to attach info, how to test it, etc.

[Martin Pitt (pitti)]

Thanks for the analysis. It was just a rough idea when I filed that, I didn't look into how much common code these hooks have. Once you are in python, we don't need them at all, as the Report class and hookutils already provide a much more convenient and richer interface than you could ever express with a CLI, and the latter isn't type/structure rich enough to do things like passing multiple binary data pipes, etc. So I guess I'll just close this as 'wontfix'.

@Bryce: as for documentation, did you stumble over particular things in hookutils or the general python-apport API which are unclear/dubious? I'm happy to improve the documentation there.