Wednesday, 14 May 2014

Re: and upgrade crashes

On Wed, May 14, 2014 at 01:07:51AM -0700, Robert Park wrote:
> > That would be very useful indeed. I assume the version data sent to
> > 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 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.

This is a python-specific problem with crash reports. For C programs,
/proc/pid/maps tells us with certainty whether the package or its
dependencies have been upgraded out from under us, and avoids filing useless
crash reports pointing to wrong versions. We can't do this reliably for
python programs, because python doesn't map pure-python modules into memory.

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

Yes, if you know a way to do this it would certainly be a welcome

Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer