Reject crashes that happen right after upgrade
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
apport (Ubuntu) |
Fix Released
|
Medium
|
Martin Pitt | ||
Precise |
Fix Released
|
Medium
|
Martin Pitt |
Bug Description
According to Sebastian we often get crash reports for packages which just have been upgraded, but the old version of the executable is still running. (e. g. bug 983697). Apport already prevents filing a report when the executable changed between the time the crash happens and the time the user reports the bug, but this is not sufficient here: In that example, evince crashed right _after_ installing the new version (the running process got confused about the new data on disk presumably), so that check doesn't help.
We need to check if the binary was modified after the process started.
FIX: http://
SRU TEST CASE:
- Install an older version of shotwell, e. g. the version from precise final.
- Start "shotwell &" in a terminal (or any other program, really)
- upgrade shotwell to precise-updates.
- Let it crash with "killall -SEGV shotwell"
- In the precise version, apport either displays the bug, or /var/log/apport.log gets an exception about self['Executabl
- In this fixed version, apport.log just gets "executable was modified after program start, ignoring" and does not produce a report in /var/crash/.
- Without upgrading the package in between, the proposed version continues to generate a proper crash report.
REGRESSION POTENTIAL: Low, the change has been tested in quantal for a while already, is covered by a test case, and the other dozens of test cases cover the "normal" case when a binary is older than the process start time.
Changed in apport (Ubuntu Precise): | |
status: | New → In Progress |
assignee: | nobody → Martin Pitt (pitti) |
importance: | Undecided → Medium |
Changed in apport (Ubuntu Precise): | |
status: | In Progress → Fix Committed |
description: | updated |
description: | updated |
/proc/pid/status does not have an obvious start time, but we can look at the mtime of the /proc/pid/exe symlink and compare it with the mtime of the symlink target.