On Tue, Dec 17, 2013 at 08:30:28AM +0000, Nicolas Dufour wrote:
On Sun, Dec 15, 2013 at 07:42:49PM +0100, Kris De Gussem wrote:
I was wondering how to deal with bug reports automatically submitted by the operating system. It is often hard to verify for these bugs how exactly one could to provoke the issue but on the other hand it may be clear from the backtrace that some null pointer check (or related thing) is missing).
It's particularly difficult to deal with the Ubuntu automatic reports, mainly because they often don't include steps to reproduce. We can try to fix it thanks to the backtrace, but we have no certainty that it is actually fixed without the steps. So what should we do? Close as soon as we have committed a fix or wait until someone finds a way to reproduce and confirm the fix works.
I don't think there can be a hard and fast rule here; it's kind of a judgment call.
For X.org bugs in Ubuntu, where there was a crash we didn't know how to repro but the stacktrace pointed out the flaw (a null pointer deref or whatever), I'd commit the patch and mark the bug fixed. We would only need the steps to repro and confirmation of the fix if we needed to backport the fix to a stable release.
When the stacktrace didn't point out the flaw definitively, then we would indeed need to get steps to repro. If we had an idea for a patch, I'd post it to the bug report (and put a test package with the patch into a PPA), and wait on committing it to mainline until a user confirmed it. We usually only did this for crashes and lockups that were being hit by a lot of users, so even if one person was unresponsive, we could wait until another person filed a new bug, or commented on the original one. In a lot of cases the crash or hang wasn't deterministic but tended to occur periodically over N hours, so if they ran the package and used it for > 2*N hours we called it good.
It's worth noting that the automatic collecting tool avoids creating new bug reports if it finds one with the same stack trace that still has an open distro task. So, being a little aggressive at closing these bugs when you suspect they're fixed is okay - the system will file a new one if it's still crashing for someone.
My guess for Inkscape is that the former case is going to be more applicable. Perhaps suv has better advice on Inkscape policy here?
Of course, if the codebase is frozen for a release, there'll be stricter rules, since we do want to make sure a committed fix really does fix the issue, but there'll be policy guidance given when we're at that point.
By the way, the automatically generated bug reports can be controlled on the ubuntu side. We can arrange to collect some additional logs from the system at the time of the crash. (Very useful for X.org bug reports; maybe less so for Inkscape.)
Also, there is a site at errors.ubuntu.com where ALL reported crashes appear, even if the user doesn't file a bug report. This site counts how many of each crash were reported for each Ubuntu release, and links to the bug report if there is one. You have to register to gain access to the detailed data (let me know if you're applying and I'll put in a good word with the ubuntu folks.)
So right now, for package 0.48.4-1ubuntu3, the top crashers hit by users this past month are:
Bug 1047748 (71 crashes) sp_dtw_color_profile_event Bug 1216167 (14 crashes) pathv_to_linear_and_cubic_beziers (8 crashes) sp_guideline_destroy (8 crashes) sp_ctrlpoint_set_color
The interface also allows creating bug reports for crashes that don't yet have one. I created 1261918 as an example. Looks like there's a bunch of crashes that don't have bug reports yet.
The detail crash report page shows a full stack trace, and a table showing other instances of the crash, what package version and ubuntu version were in use, and the date and time the crash occurred. You can also look at other examples of the stack trace, which can sometimes be handy to compare data or examine race conditions.
For X.org I found this tool very helpful for prioritizing what crashers to work on, and identifying where backports of a fix to earlier stable releases would bring good bang for the buck.
HTH, Bryce