Proposed F18 feature: MiniDebugInfo

[Alexander Larsson]

On Tue, 2012-05-08 at 13:08 +0200, Miloslav Trmač wrote:
> My take:
> 
> 1) Developers of the software in question: Bluntly, the ~1-100 users
> in the whole world shouldn't matter in our discussion - if they are
> even running the RPM, they can and probably will install complete
> debuginfo, enable logging and do other non-default things to make
> their job easier; The Fedora defaults don't matter that much for them,
> and the mini debuginfo is not that useful either.

I generally agree with this. When i'm working on an app I generally have
custom builds of it and its dependencies. However, at some point down
the dependency chain i start relying on distro packages, and it would be
kind of nice to have some info for that when e.g. profiling or
something.

> 2) Non-programming end-users.  _This_ is the case that we need to get
> right by default.    In many cases, a developer is lucky if the end
> user ever sends any crash report, they often don't respond to
> follow-up questions, and the problem does not have to be reproducible
> at all.  From such users we definitely want as full crash information
> as possible (IOW, including the variable contents information) because
> there won't be a second change to get it.  The mini debuginfo is
> therefore irrelevant, we need to steer users to the retrace server (or
> to attaching full core files to reports, which has much worse privacy
> impact).

I agree that we need to get this right, and that its the most important
problem. However, I don't agree with your reasoning. Its true that it
would be nice to have as much information as possible, and having the
retraced data availible when it works is nice. However, the details with
retracing, having to show the full backtrace letting you ack the
backtrace for privacy issue, the waiting for the retracing to happen,
etc, risks scaring the user away resulting in nothing being reported at
all. 

Take this post for instance:

https://plus.google.com/110933625728671692704/posts/iFXggK7Q8KJ

It show exactly why this is a problem. We try to get more information,
but the result is less information. 

A report based on the minidebuginfo already existing on the system will
give you a basic backtrace that is quite useful, and this should be
reportable with a single, fast operation just sending the data to the
server (as well as logging it to the system logs). The developer can
then do the retrace from that on the server side to get line numbers if
they are needed. We can also have an optional method of reporting that
gives the "full" stacktrace information, does the retracing over the
network and whatnot, but I don't think its a good idea to do by default.

> BTW, the feature suggests mini debuginfo would be useful for userspace
> tracing - AFAIK such uses, e.g. systemtap, use the variable location
> information very extensively, and would thus not benefit from mini
> debuginfo.

True.