| 2012-04-18 14:21:25 |
Martin Pitt |
bug |
|
|
added bug |
| 2012-04-18 14:21:31 |
Martin Pitt |
apport (Ubuntu): status |
New |
Triaged |
|
| 2012-04-18 14:21:32 |
Martin Pitt |
apport (Ubuntu): assignee |
|
Martin Pitt (pitti) |
|
| 2012-04-18 14:21:37 |
Martin Pitt |
apport (Ubuntu): importance |
Undecided |
Medium |
|
| 2012-04-18 14:21:39 |
Martin Pitt |
bug |
|
|
added subscriber Sebastien Bacher |
| 2012-04-20 14:10:27 |
Launchpad Janitor |
branch linked |
|
lp:apport |
|
| 2012-04-20 14:10:41 |
Martin Pitt |
apport (Ubuntu): status |
Triaged |
Fix Committed |
|
| 2012-05-18 14:35:30 |
Launchpad Janitor |
apport (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2012-05-18 14:43:27 |
Launchpad Janitor |
branch linked |
|
lp:~ubuntu-core-dev/ubuntu/precise/apport/ubuntu |
|
| 2012-05-29 16:39:22 |
Martin Pitt |
nominated for series |
|
Ubuntu Precise |
|
| 2012-05-29 16:39:22 |
Martin Pitt |
bug task added |
|
apport (Ubuntu Precise) |
|
| 2012-05-29 16:39:28 |
Martin Pitt |
apport (Ubuntu Precise): status |
New |
In Progress |
|
| 2012-05-29 16:39:30 |
Martin Pitt |
apport (Ubuntu Precise): assignee |
|
Martin Pitt (pitti) |
|
| 2012-05-29 16:39:33 |
Martin Pitt |
apport (Ubuntu Precise): importance |
Undecided |
Medium |
|
| 2012-05-29 17:52:22 |
Martin Pitt |
apport (Ubuntu Precise): status |
In Progress |
Fix Committed |
|
| 2012-05-30 06:37:11 |
Martin Pitt |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2012-06-01 04:06:07 |
Martin Pitt |
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. |
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://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2296
SRU TEST CASE:
- Start "evince &" in a terminal (or any other program, really)
- Pretend the package would get an upgrade, either by actually installing a newer package version, or doing "sudo touch /usr/bin/evince"
- Let it crash with "killall -SEGV evince"
- In the precise version, apport either displays the bug, or /var/log/apport.og gets an exception about self['ExecutablePath'] not existing any more.
- In this fixed version, apport.log just gets "executable was modified after program start, ignoring" and does not produce a report in /var/crash/.
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. |
|
| 2012-06-04 23:13:03 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2012-06-04 23:13:10 |
Brian Murray |
tags |
|
verification-needed |
|
| 2012-06-13 05:07:30 |
John S. Gruber |
bug |
|
|
added subscriber John S. Gruber |
| 2012-06-14 13:12:31 |
Martin Pitt |
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://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2296
SRU TEST CASE:
- Start "evince &" in a terminal (or any other program, really)
- Pretend the package would get an upgrade, either by actually installing a newer package version, or doing "sudo touch /usr/bin/evince"
- Let it crash with "killall -SEGV evince"
- In the precise version, apport either displays the bug, or /var/log/apport.og gets an exception about self['ExecutablePath'] not existing any more.
- In this fixed version, apport.log just gets "executable was modified after program start, ignoring" and does not produce a report in /var/crash/.
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. |
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://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2296
SRU TEST CASE:
- Install an older version of gnomine, e. g. the version from precise final.
- Start "gnomine &" in a terminal (or any other program, really)
- upgrade gnomine to precise-updates.
- Let it crash with "killall -SEGV gnomine"
- In the precise version, apport either displays the bug, or /var/log/apport.log gets an exception about self['ExecutablePath'] not existing any more.
- In this fixed version, apport.log just gets "executable was modified after program start, ignoring" and does not produce a report in /var/crash/.
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. |
|
| 2012-06-28 06:52:25 |
Martin Pitt |
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://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2296
SRU TEST CASE:
- Install an older version of gnomine, e. g. the version from precise final.
- Start "gnomine &" in a terminal (or any other program, really)
- upgrade gnomine to precise-updates.
- Let it crash with "killall -SEGV gnomine"
- In the precise version, apport either displays the bug, or /var/log/apport.log gets an exception about self['ExecutablePath'] not existing any more.
- In this fixed version, apport.log just gets "executable was modified after program start, ignoring" and does not produce a report in /var/crash/.
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. |
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://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2296
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['ExecutablePath'] not existing any more.
- 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. |
|
| 2012-07-06 05:26:21 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/precise-proposed/apport |
|
| 2012-07-06 05:27:20 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/apport |
|
| 2012-07-16 21:38:45 |
Stéphane Graber |
tags |
verification-needed |
verification-done |
|
| 2012-07-17 22:47:11 |
Launchpad Janitor |
apport (Ubuntu Precise): status |
Fix Committed |
Fix Released |
|
