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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
