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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/172754 Title: provide app to generate a crash/bug report -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
