On Wednesday, May 14, 2014 01:07:51 Robert Park wrote:
> On Tue, May 13, 2014 at 5:47 PM, Bjoern Michaelsen
>
> <bjoern.michaelsen@canonical.com> wrote:
> >> > ... e.g. trivially: mark crashers 48hours after the upgrade
> >> > as 'potentially an upgrade sideeffect' or somesuch?
> >>
> >> Probably not retroactively. But I imagine it would be fairly easy to
> >> add info to future error reports asking if do-release-upgrade (or
> >> whatever) was running at the time.
> >
> > That would be very useful indeed. I assume the version data sent to
> > errors.ubuntu.com in these cases to be wrong and poisoning the well
> > anyway:
> > - the client will send an error report with the application version the
> > package>
> > manager reports to be installed
> >
> > - the application crashed will actually be a older, different one.
>
> This has bit me a couple of times, although I didn't understand what
> was happening at the time.
>
> I've seen certain python tracebacks in errors.ubuntu.com that, if you
> check the version number specified in the crash, you find that the
> code causing the traceback literally does not exist (in that version).
> The only explanation is that the user was running an older copy, which
> crashed, but the report contains the version number of the updated
> package.
>
> > It would be ideal to fingerprint the crashed binary and compare it to the
> > version installed on disc, and skip reporting if those differ.
>
> In the case of python programs you'd want to be sure to fingerprint
> all the various .py files that might be loaded... probably better to
> fingerprint every file in the package, if any differ then the report
> is invalid.
If packages are crashing during an upgrade, that's still a bug, it's just a
different one.
Scott K
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
