incomplete crash files getting uploaded to the error tracker

Bug #1355546 reported by Brian Murray
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
apport (Ubuntu)
New
Undecided
Unassigned

Bug Description

Looking at some crash reports in the Ubuntu Error Tracker, I saw a couple that there were odd because they were missing the DistroRelease data.

https://errors.ubuntu.com/oops/b6579caa-1f91-11e4-b37e-fa163e75317b

That error was reported at 2014-08-09 06:52:21 (b6579caa-1f91-11e4-b37e-fa163e75317b) inserted into OOPS CF. Shortly, afterwards (2014-08-09 06:52:34 (bd8b1dbc-1f91-11e4-9deb-fa163e22e467) inserted into OOPS CF) an OOPS from the same user was reported.

https://errors.ubuntu.com/oops/bd8b1dbc-1f91-11e4-9deb-fa163e22e467

The second OOPS has all the data collected including Dependencies, and DistroRelease. whoopsie should only upload the .crash file if there is a .upload file so it seems likely that apport created the .upload file prematurely. Although, for that to be the case then apport would have to modify the .upload file again such that whoopsie noticed it. Regardless, there is something odd going on.

I found a second example too:

https://errors.ubuntu.com/oops/ce4805be-1f20-11e4-a536-fa163e4aaad4
https://errors.ubuntu.com/oops/d5761f42-1f20-11e4-9c34-fa163e707a72

summary: - apport seems to be creating .upload files before data collection is
- complete
+ incomplete crash files getting uploaded to the error tracker
Revision history for this message
Brian Murray (brian-murray) wrote :

Looking at apport's code I don't see anywhere the report file is written to more than once.

Revision history for this message
Brian Murray (brian-murray) wrote :

For what it is worth the examples are both python tracebacks and not coredumps.

Revision history for this message
Brian Murray (brian-murray) wrote :

I mean anywhere the .upload file is written two times.

Revision history for this message
Brian Murray (brian-murray) wrote :

I've managed to recreate this issue, well the uploading of the incomplete crash report at least, by doing the following.

1) in a terminal run 'sudo chmod 600 /etc/apt/sources.list'
2) run 'update-manager'
3) observe a crash and click "Leave Closed" on the crash notification dialog
4) confirm that there is in /var/crash/ a .upload and .uploaded file for the update-manager crash

If you inspect the update-manager crash file you'll notice it is missing Dependencies and DistroRelease so the additional apport data collection was never done.

Revision history for this message
Brian Murray (brian-murray) wrote :

The test case I've indicated might be a bad example as apport will also want to use apt, however the apport dialog contains information (revealed after clicking "Show Details") that doesn't get written to the report.

UnreportableReason: E: Opening /etc/apt/sources.list
DistroRelease: Ubuntu 14.04

So there is still something wrong in apport's code.

Revision history for this message
Brian Murray (brian-murray) wrote :

I'd tracked the update-manager case down to the following in apport/ui.py:

    try:
        report.add_package_info(package)
    except ValueError:
        # this happens if we are collecting information on an uninstalled
        # package
        if not ignore_uninstalled:
            raise
    except SystemError as e:
        report['UnreportableReason'] = excstr(e)
        return

We are returning from thread_collect_info() before we've written the collected information to the report. Removing the return works but then 'UnreportableReason' was changed to 'This package does not seem to be installed correctly'. I think this issue with /etc/apt/sources.list is likely a separate bug (than the menulibre examples in the description), so I'll open a separate bug for it.

Revision history for this message
Brian Murray (brian-murray) wrote :

This may be a duplicate of bug 1512902, although it seems unlikely if the same crash report was submitted later.

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.