Missing crash reports for long-running processes
mdz at ubuntu.com
Wed Aug 26 20:32:06 BST 2009
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,
> 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
> (as they would have different build ids).
> I have a trivial patch for debhelper to place debugging symbols in a build
> 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?
More information about the ubuntu-devel