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.
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 DistUpgradeAppo rt.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.