reporting of crashes for programs that don't match the file on disk is happening

Bug #1373154 reported by Brian Murray on 2014-09-23
This bug affects 1 person
Affects Status Importance Assigned to Milestone
apport (Ubuntu)

Bug Description

The change to apport in bug 1039220, not to report crashes with an UnreportableReason of "The problem happened with the program.*which changed since the crash occurred." seems to have regressed somehow. While the code looks the same I was able to create a crash file with the following content:

UnreportableReason: The problem happened with the program /usr/games/gnome-sudoku which changed since the crash occurred.
_MarkForUpload: True

_MarkForUpload in this case should be False not True. This crash file was created on Trusty by following the steps in bug 1272716, choosing not to report the crash when apport asked, then installing the fixed version of gnome-sudoku, and running apport-bug /var/crash/_usr_games_gnome-sudoku.1000.crash.

You can see the crash I reported at Notice how the ExecutableTimestamp (Thu, 23 Jan 2014 15:57:56 GMT) is from well before the date of the SRU for gnome-sudoku.

Test Case
1) Downgrade gnome-sudoku to version 1:3.10.2-0ubuntu2
2) Launch gnome-sudoku
3) Upgrade gnome-sudoku to version 1:3.10.2-0ubuntu3.1
4) Start an easy game in gnome-sudoku
5) Fill in a number, then press undo
6) Observe crash dialog
7) Click continue
8) grep "_MarkForUpload" /var/crash/* - observe _MarkForUpload is True

Changed in apport (Ubuntu):
importance: Undecided → High
tags: added: trusty
Brian Murray (brian-murray) wrote :

This seems to only happen when I view the details of the crash report, if I choose not to view the details then no data is added to the crash report (which also seems like a bug).

description: updated
Brian Murray (brian-murray) wrote :

I think there are actually two separate issues here.

If an old version of an application is still running, then the package is upgraded, and then it crashes. The crash file is about the new version of the application even though the old binary is running. In this case _MarkForUpload is True and there is no UnreportableReason. This problem has probably always existed.

The other issue is the one I describe in the description where a .crash file is created, data collection is not done (for whatever reason) until after the package has been upgraded, and when it is collected UnreportableReason contains information about the program changing. In this case _MarkForUpload should be False and I'll test that again.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers