On automatic bugreports

I’ve been looking at some nasty nautilus crashers this week, including bug 343488 which has several hundreds of duplicates in bugzilla. Thankfully the bug team has managed to mark all of these as duplicates, or this would be a major undertaking.

One problem with autogenerated bugreports like this is the lack of information in them. All they have is a backtrace (generally without debug information, i.e. pretty useless) and a short line of text saying what the reporter did at the time. You can get a better feeling for the bug by reading a lot of the duplicates and try to detect common patterns, but this only works sometimes.

Thanks to the miracle of separate debug info and debuginfo packages (which I created back in 2002) its now pretty easy to have a user create a backtrace with debug information. This makes the backtraces much more useful, and we eventually got someone to report a nice backtrace for the bug.

Sometimes that is not really enought, like in the case of this hard to reproduce bug. To verify my suspicions I really needed to see the stderr output from nautilus to verify that an assertion warning triggered. But the output from nautilus isn’t normally visible as nautilus isn’t started from a terminal. We eventually managed to find someone who could reproduce this and send us the end of ~/.xsession-errors which had the suspected output.

This got me thinking a bit. If that information had been availible in the automatic bug reports it would have been much easier to find this bug, and similarly with all crashes that spew several warnings or asserts before crashing. So, I wrote a patch for bug-buddy to output some extra information when it creates crash dumps.

The patch also adds some information on the kernel used, the X server used, whether accessibility is enabled and the selinux mode. I hope we’ll get this out to users soon so that we can do a better job fixing bugs.

One thought on “On automatic bugreports”

  1. I would like to point something out that we’ve discovered from the Mozilla project. That stacktraces are good for one thing: gathering statistics. You know what your top crashers are and you fix them, driving the MTBF up.

    Every crash is probably a bug, but it’s not worth the time to try and track down every crash with the time that you would apply to a well-diagnosed bug. Instead treat it like it is: wisdom of the crowds, and use it to find the big stuff. Or maybe the little stuff, too, but know that you will never be able to keep up with that much data.

Comments are closed.