Proposed F18 feature: MiniDebugInfo

Alexander Larsson alexl at
Mon May 7 15:15:17 UTC 2012

On Mon, 2012-05-07 at 16:25 +0200, Jan Kratochvil wrote:
> On Mon, 07 May 2012 15:07:20 +0200, Alexander Larsson wrote:
> > I just wrote a new Feature proposal for shipping minimal debug info by
> > default:
> >
> The "several choices" is missing the primary possibility of no debug info
> needed at the client side at all thanks to already implemented
> Why not to use ABRT Retrace Server for the bugreports instead?
> I am only aware the upload of core file may be slow but that can be solved
> (by gdbserver for core files, which was already implemeted once).  I do not
> know if it is a real problem or not, core file do not have to be large.

Well, its not listed as an option because that means there is no feature
to be done at all.

However, I don't think the retrace server is always what you want. They
have several disadvantages:

* They don't work offline, or before/after the network is up
* There are privacy issues with sending the users coredumps to some
  server on the internet
* They don't work for site-local packages, or scratch builds of fedora
* They require some server to store every build of every fedora package
  forever, and sync new builds from the buildsystem there.
* If some organization doesn't want to send reports to the fedora
  servers they need to duplicate all debug info packages on their
  retrace server
* They only work for ABRT, not if you're e.g. debugging something
  locally, or a user is reporting a backtrace with gdb
* They can only be used for crash reporting, not e.g. tracing
  or profiling
* Its problematic to use a retrace server during early boot, or e.g. in
  non-session apps like a daemon

I think retrace servers are interesting, because when applicable they do
allow you to get a higher quality backtrace, with full debug info.
However, I think we should *always* have a baseline backtrace with at
least function names, which is there when retracing isn't. 

This is very similar to the backtrace shown at kernel oopses: they are
low-quality backtraces, which are generated at time of the oops, and not
later. It gets you the most out of the machine at a time where the
machine is otherwise already pretty useless. We want that for userspace
too, regardless if it is early boot, late shutdown or any other state of
the system.

So, I don't think the existance of retracing servers is contrary to
having minidebuginfo.

More information about the devel mailing list