On Wed, May 14, 2014 at 08:23:32AM -0700, Steve Langasek wrote:
> 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
> > > 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.
> 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
It should be possible to compare the time when the crashing process was
started (available in /proc/$pid/stat, assuming the process still exists
when the kernel runs apport to collect the core file) and the time the
package for that process was last upgraded (by looking at the mtime of
<phrakture> i learned vim by reading the source code. am I hardcore yet?
<Axioplase> phrakture: not enought yet... read it rot13'd, and you'll be
<phrakture> I read it as analog output on an oscilliscope
<mgedmin> rot13, bah, try reading the gzipped source tarball
<lack> standing on your head.