Missing crash reports for long-running processes

[Matt Zimmerman]

On Fri, Aug 21, 2009 at 02:29:33AM +0200, Emilio Pozuelo Monfort wrote:
> > If we're fixing issues with Apport, I think that's a bigger one.  I run
> > Karmic, but I don't update everyday.  Probably once a week or two.  And
> > basically if I get an Apport dialog I just close it as I know that my
> > backtrace will probably get rejected as something inevitably changed.
> 
> This could be solved by using build ids and storing debug symbols on path
> containing the build ids (basically a path that contains a hash in it,
> which
> should be unique, e.g. /usr/lib/debug/.build-id/12/34567890abcdef.debug).
> 
> This way you can have multiple copies of debugging symbols for different
> versions of the same binary, as now the path is different for each one of
> them
> (as they would have different build ids).
> 
> I have a trivial patch for debhelper to place debugging symbols in a build
> id
> path. Also GCC already adds build ids to the binaries, so going this way
> shouldn't be hard.
> 
> > I do realized the impact of this and the amount of datacenter space it'd
> > take to keep all the binaries.  But it's a source of frustration for me
> > as it seems that Apport is only for people who update daily.
> 
> You could keep debugging symbols for e.g. the last 15 days, or some fixed amount
> of days (depending on the disk space available).

I think we already keep debugging symbols for the past N versions or days.
We don't need for them to parallel installable as you described; we only
ever need one set of packages for a given retrace.

Or have I misunderstood?

-- 
 - mdz