| 2012-11-09 23:44:45 |
Brian Murray |
bug |
|
|
added bug |
| 2012-11-09 23:47:18 |
Brian Murray |
bug |
|
|
added subscriber Martin Pitt |
| 2013-01-04 12:25:40 |
Launchpad Janitor |
branch linked |
|
lp:apport |
|
| 2013-01-04 12:26:37 |
Martin Pitt |
apport (Ubuntu): status |
New |
Fix Committed |
|
| 2013-01-04 16:00:41 |
Brian Murray |
nominated for series |
|
Ubuntu Quantal |
|
| 2013-01-04 16:00:41 |
Brian Murray |
bug task added |
|
apport (Ubuntu Quantal) |
|
| 2013-01-04 16:00:51 |
Brian Murray |
apport (Ubuntu Quantal): importance |
Undecided |
High |
|
| 2013-01-04 16:00:56 |
Brian Murray |
apport (Ubuntu Quantal): status |
New |
Triaged |
|
| 2013-01-08 09:09:14 |
Launchpad Janitor |
apport (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2013-01-10 22:17:09 |
Brian Murray |
description |
I was testing bug 1067542 again and ran into a situation where release upgrade crash was unreportable because the binary had changed.
Digging into the issue DistUpgradeApport.py from update-manager / ubuntu-release-upgrader sets ExecutablePath = '/usr/bin/do-release-upgrade', however ProcCmdline = '/usr/bin/python /tmp/update-manager-xyz/quantal' (from the dist upgrade tarball).
Then when add_proc_info calls _check_interpreted (in apport/report.py) ExecutablePath is temporarily set to '/tmp/update-manager-xyz/quantal' and the ExecutableTimestamp is calculated using that ExecutablePath. Later, on when collect_info (in apport/ui.py) is run we use the "real" ExecutablePath, '/usr/bin/do-release-upgrade' in this example, which will have a different ExecutableTimestamp than the one written to the report during _check_interpreted.
This ultimately, makes reporting crashes in the release upgrader not reportable. |
[Test Case]
One convoluted way to test this the following:
1) on a quantal system run 'do-release-upgrade -d'
2) cancel the upgrade
3) switch to the release upgrader directory '/tmp/ubuntu-release-upgrade-XYZ'
4) edit DistUpgradeController create a new line (number 407) after 'if.self.configgetWithDefault...' with the contents 'x = (10 / 0)'. This will cause the release upgrader to crash the next time it is run.
5) in /tmp/ubuntu-release-upgrader-XYZ run the following:
'sudo /usr/bin/python /tmp/ubuntu-release-upgrader-XYZ/raring --sandbox'
Observe the release upgrader crash and that you are not prompted to file a bug in Launchpad.
----
I was testing bug 1067542 again and ran into a situation where release upgrade crash was unreportable because the binary had changed.
Digging into the issue DistUpgradeApport.py from update-manager / ubuntu-release-upgrader sets ExecutablePath = '/usr/bin/do-release-upgrade', however ProcCmdline = '/usr/bin/python /tmp/update-manager-xyz/quantal' (from the dist upgrade tarball).
Then when add_proc_info calls _check_interpreted (in apport/report.py) ExecutablePath is temporarily set to '/tmp/update-manager-xyz/quantal' and the ExecutableTimestamp is calculated using that ExecutablePath. Later, on when collect_info (in apport/ui.py) is run we use the "real" ExecutablePath, '/usr/bin/do-release-upgrade' in this example, which will have a different ExecutableTimestamp than the one written to the report during _check_interpreted.
This ultimately, makes reporting crashes in the release upgrader not reportable. |
|
| 2013-01-11 16:45:31 |
Brian Murray |
description |
[Test Case]
One convoluted way to test this the following:
1) on a quantal system run 'do-release-upgrade -d'
2) cancel the upgrade
3) switch to the release upgrader directory '/tmp/ubuntu-release-upgrade-XYZ'
4) edit DistUpgradeController create a new line (number 407) after 'if.self.configgetWithDefault...' with the contents 'x = (10 / 0)'. This will cause the release upgrader to crash the next time it is run.
5) in /tmp/ubuntu-release-upgrader-XYZ run the following:
'sudo /usr/bin/python /tmp/ubuntu-release-upgrader-XYZ/raring --sandbox'
Observe the release upgrader crash and that you are not prompted to file a bug in Launchpad.
----
I was testing bug 1067542 again and ran into a situation where release upgrade crash was unreportable because the binary had changed.
Digging into the issue DistUpgradeApport.py from update-manager / ubuntu-release-upgrader sets ExecutablePath = '/usr/bin/do-release-upgrade', however ProcCmdline = '/usr/bin/python /tmp/update-manager-xyz/quantal' (from the dist upgrade tarball).
Then when add_proc_info calls _check_interpreted (in apport/report.py) ExecutablePath is temporarily set to '/tmp/update-manager-xyz/quantal' and the ExecutableTimestamp is calculated using that ExecutablePath. Later, on when collect_info (in apport/ui.py) is run we use the "real" ExecutablePath, '/usr/bin/do-release-upgrade' in this example, which will have a different ExecutableTimestamp than the one written to the report during _check_interpreted.
This ultimately, makes reporting crashes in the release upgrader not reportable. |
[Test Case]
One convoluted way to test this the following:
1) on a quantal system run 'do-release-upgrade -d'
2) cancel the upgrade
3) switch to the release upgrader directory '/tmp/ubuntu-release-upgrade-XYZ'
4) edit DistUpgradeController.py create a new line (number 407) after 'if.self.config.getWithDefault...' with the contents 'x = (10 / 0)'. This will cause the release upgrader to crash the next time it is run.
5) in /tmp/ubuntu-release-upgrader-XYZ run the following:
'sudo /usr/bin/python /tmp/ubuntu-release-upgrader-XYZ/raring --sandbox'
Observe the release upgrader crash. If you inspect the contents of the crash file, /var/crash/_usr_bin_do-release-upgrade.0.crash you'll notice that with the current version of apport, additional system information is not collected - you will not find Dependencies in the .crash file. With the version of apport from -proposed you will find this.
----
I was testing bug 1067542 again and ran into a situation where release upgrade crash was unreportable because the binary had changed.
Digging into the issue DistUpgradeApport.py from update-manager / ubuntu-release-upgrader sets ExecutablePath = '/usr/bin/do-release-upgrade', however ProcCmdline = '/usr/bin/python /tmp/update-manager-xyz/quantal' (from the dist upgrade tarball).
Then when add_proc_info calls _check_interpreted (in apport/report.py) ExecutablePath is temporarily set to '/tmp/update-manager-xyz/quantal' and the ExecutableTimestamp is calculated using that ExecutablePath. Later, on when collect_info (in apport/ui.py) is run we use the "real" ExecutablePath, '/usr/bin/do-release-upgrade' in this example, which will have a different ExecutableTimestamp than the one written to the report during _check_interpreted.
This ultimately, makes reporting crashes in the release upgrader not reportable. |
|
| 2013-01-11 19:44:43 |
Launchpad Janitor |
branch linked |
|
lp:~ubuntu-core-dev/ubuntu/quantal/apport/ubuntu |
|
| 2013-01-17 19:22:50 |
Adam Conrad |
apport (Ubuntu Quantal): status |
Triaged |
Fix Committed |
|
| 2013-01-17 19:22:52 |
Adam Conrad |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2013-01-17 19:22:53 |
Adam Conrad |
bug |
|
|
added subscriber SRU Verification |
| 2013-01-17 19:22:55 |
Adam Conrad |
tags |
quantal raring |
quantal raring verification-needed |
|
| 2013-01-26 14:52:56 |
Brian Murray |
tags |
quantal raring verification-needed |
quantal raring verification-done |
|
| 2013-01-28 12:10:56 |
Colin Watson |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2013-01-28 12:11:10 |
Launchpad Janitor |
apport (Ubuntu Quantal): status |
Fix Committed |
Fix Released |
|
