Proposed F18 feature: MiniDebugInfo

[Alexander Larsson]

On Wed, 2012-05-09 at 13:32 +0200, Jiri Moskovcak wrote:

> Appart from that I see two questions here:
> 1. Whether to add the minidebuginfo in Fedora
> 2. Whether to use this stripped backtrace when reporting a bug.
> 
> 
> For 1: The decision to use it or not should be based on some real-life 
> tests like "how it impacts the current gnome/kde live cd" or other 
> spins. If the additional payload is really small then I don't see a 
> problem here (but I'm glad the decision is not mine ;))

That requires us to rebuild the entire distro to get the minidebuginfo
rpms. Its certainly doable, but some work. I can produce a patch to
rpm-build that does this, but I can't really do the rebuild stuff, that
would need help from someone on the build team.

> For 2: At this point (F18 timeframe) probably not. From ABRT point of 
> view the minidebug is not a problem at all if we can use gdb to generate 
> some backtrace using the mindebuginfo. But what matters are developers 
> who will need to deal with this stripped backtrace and I can guarantee 
> that there will be many unhappy devels. And also the ABRT server 
> projects rely on the coredumps: 
> http://git.fedorahosted.org/git?p=abrt.git;a=blob_plain;f=doc/project/abrt.pdf;hb=HEAD 
> And once put into life these server side projects will be a great help 
> in bugfixing.

I'm not proposing that we drop the existing backtraces with full debug
info, but (appart from the other places where backtraces are also
useful) I'd like it if ABRT could somehow catch all the cases where
people abort a bugreport because things are scary/slow/bad
network/whatever and at least report the low quality backtrace, which
should be very quick and require little work from the user.

I don't have a full design in mind, but I'm thinking that as soon as the
user acks that he wants to report the bug we would start by just
uploading the low quality backtrace, and *then* start retracing the bug
and show the user the backtrace with full data etc, asking them if its
ok to submit the data. That way we get at least *something* in all
crashes, and perfect reports for users that goes all the way.