Proposed F18 feature: MiniDebugInfo

[Jiri Moskovcak]

On 05/09/2012 01:51 PM, Jakub Jelinek wrote:
> On Wed, May 09, 2012 at 01:44:03PM +0200, Alexander Larsson wrote:
>> 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.
>
> But you don't need any kind of minidebuginfo for that first step,
> you can make it even faster by just uploading the backtrace + build-ids
> and on the server side the rest of transforming that to a low-quality
> backtrace can be handled automatically, without
> further user intervention, in case the user didn't go through to uploading
> the high quality thing from retrace server.
>
> 	Jakub

- that's something what we have right now (should be in F18), we have a 
server which accepts something we call microreport (kind of a backtrace 
without debuginfo + build_id and some other information - yes, it's 
similar to minidump) this is small enough to be uploaded on almost any 
internet connection and contains enough information to find duplicates.

The workflow we would like to use is something like this:
1. ABRT detects a crash
2. User clicks report which sends a microreport (few kilobytes)
3. is it a dupe?
   YES: send back response with the ticket url, increase the dupe counter
   NO: ask user to upload the core or full backtrace

But, I think that's a totally different use-case than what minidebuginfo 
is trying to solve.

 From what I understand the use case for minidebuginfo is when something 
crashes on machine where the full debuginfo is not available and for 
some reason the machine is configured to not store the coredumps, but we 
still want to have something more in log than just "process foo has 
crashed".

--Jirka