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