don't report crashes for programs that don't match the file on disk (like for kernel crashes)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
apport (Ubuntu) |
Fix Released
|
Medium
|
Brian Murray | ||
Precise |
Fix Released
|
Medium
|
Brian Murray | ||
Quantal |
Fix Released
|
Medium
|
Brian Murray |
Bug Description
[Impact]
Reporting of crashes against currently-installed versions of packages, which this is not the version of package on disk, results in garbage data in the errors.ubuntu.com graphs that make it impossible to know with certainty that a given version of a package fixed a given crash. This severely hinders our reliance on errors.ubuntu.com for SRU validation.
[TEST CASE]
1) install lptools
2) lp-grab-attachments 2039920 (should crash with a keyerror)
3) close the apport dialog regarding the application crashing (via the X in the corner)
4) sudo vi $(which lp-grab-
5) modify copyright year or some comment
6) ubuntu-bug /var/crash/
7) Check the send error repot check box and click continue
8) ls -l /var/crash (observe _usr_bin_
9) remove _usr_bin_
10) reinstall lptools
11) install package from -proposed, follow test case and there should *not* be a .upload or .uploaded file as seen in step 8
[Regression Potential]
Worst-case scenario is that some crashes that should be reported fail to be reported as a result of a bug in this change.
Every crash report that gets fixed in a package upload winds up with some fuzziness in the bucket showing a small number of crash reports in the very version that fixes it. E.g.:
https:/
(bug #853060)
This makes it impossible to tell with certainty by looking at errors.ubuntu.com if a crash is really fixed, or if it's just been made less frequent. We need to have good data here to be able to use errors.u.c for decision making around SRU publication.
The suspicion is that the rule preventing launchpad bugs from being filed when the running process doesn't match the file on disk is not being applied correctly to whoopsie. It definitely should be.
(It's possible that this is therefore a duplicate of bug #1020994. I'm not sure, I haven't looked at the code.)
I would also argue that, if this happens in the "system service" case, we should not show the user any crash dialog for it either, so long as we don't have support for leading them to a targeted update to fix the crash. We get no useful crash information from the user in this case, and the risk of confusion from the dialog is great when it's a system service crash. As a matter of policy, front-end applications need to be resilient in the face of failures of back-end daemons.
ProblemType: BugDistroRelease: Ubuntu 12.10
Package: apport 2.4-0ubuntu8
ProcVersionSign
Uname: Linux 3.5.0-10-generic x86_64
ApportVersion: 2.4-0ubuntu8
Architecture: amd64
Date: Mon Aug 20 12:34:10 2012Installatio
PackageArchitec
UpgradeStatus: Upgraded to quantal on 2012-06-11 (70 days ago)
modified.
mtime.conffile.
summary: |
- don't report python crashes for programs that don't match the file on - disk (like for kernel crashes) + don't report crashes for programs that don't match the file on disk + (like for kernel crashes) |
Changed in apport (Ubuntu Quantal): | |
status: | Triaged → In Progress |
description: | updated |
Changed in apport (Ubuntu Quantal): | |
importance: | High → Medium |
Changed in apport (Ubuntu Precise): | |
importance: | High → Medium |
description: | updated |
Changed in apport (Ubuntu Precise): | |
status: | Triaged → In Progress |
assignee: | nobody → Brian Murray (brian-murray) |
Since apport's handling of this is mainlined in /usr/share/ apport/ apport, it's probably not an issue for the kernel crash handler. It may be an issue specific to the python crash handler.