How to proceed with MiniDebugInfo
Alexander Larsson
alexl at redhat.com
Mon May 28 17:57:48 UTC 2012
On Sat, 2012-05-26 at 11:50 +0100, Richard W.M. Jones wrote:
> On Thu, May 24, 2012 at 04:43:12PM +0200, Jan Kratochvil wrote:
> > On Thu, 24 May 2012 16:35:57 +0200, Frank Ch. Eigler wrote:
> > > jan.kratochvil wrote:
> > > > If your feature does not solve any problem it is just a bloat.
> > >
> > > This overstates the case. Alex's proposal clearly solves some problems.
> >
> > This is just about wording.
> >
> > My reaction was to:
> > I don't think there has to be a specific "problem".
>
> ... but then he goes on to list 4 or 5 different features,
> which are all nice to haves at a very small cost.
>
> I'll add one more case, which seems to happen to me all the time:
>
> - You're in IRC or email, and all the bug reporter has given you is a
> random copy and paste from their terminal. They don't care to open
> a bug; they don't much care about anything except getting a fix.
>
> Minidebuginfo would help here.
Yeah, in general the goal of MiniDebugInfo is to raise the *minimum*
quality of all backtraces. If all the stars align we should be able to
have a system that gives perfect backtraces, using server magic in ABRT
and other things, but in all the cases where this for some reason
doesn't happen we should be able to *always* at least get full function
names in the backtrace instead of "???" (unless the stack is totally
corrupted of course).
More information about the devel
mailing list