How to proceed with MiniDebugInfo

Jan Kratochvil jan.kratochvil at redhat.com
Thu May 24 12:46:21 UTC 2012


On Thu, 24 May 2012 11:07:06 +0200, Alexander Larsson wrote:
> 2) The results of the MiniDebugInfo is not perfect, and
>    there is a theoretically perfect approach. So we should not
>    spend time/energy/space/bits/whatever on the non-perfect
>    appraoch. 

>    However, the perfect approach has other disadvantages
>    due to being online/centralized, so I and others think
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

/ is not + here, other solutions require online connectivity but they do not
have to be centralized.

>    its worth having both.

There are many ways how to solve this problem, unfortunately nobody knows what
is your problem, there are too many close but still different problems in this
basket.  You have delivered solution without stating the problem first.

(1) There are two kinds of developers:
(a) PC (instruction) of the crash only
(b) full context with parameters, variables and wanting even more.

(2) There are also two different kinds of developers:
(a) dependency on network services (like ABRT Retrace Server) is OK
(b) everything must work with full feature set even offline.

(3) And yet more two different kinds of developers:
(a) we must not upload anything for security reasons
(b) we can freely upload anything because Fedora already has no security.
 - we already freely download+execute Mozilla binary plugins not reviewed
   + signed by Fedora Project, 99%(?) people install Flash anyway etc.

(4) And yet more two different kinds of developers:
(a) desktop ones who have thousands of BZs and ignore any ABRT BZ anyway
    They are more interested in stats in which parts it crashes the most.
(b) at least Tools ones who check each BZ and have more problem that some
    crashes repeat but they are not reproducible and even rich backtraces in
    many cases do not contain enough info and it would be best to extend the
    backtraces/bugreports even more.

There are various other solutions still keeping high quality backtraces such
as:

(x) Already stated fast core files upload to ABRT Retrace Server via gdbserver.
(y) With F-18 shorted .debug files 
    http://fedoraproject.org/wiki/Features/DwarfCompressor
    downloading specific .debug.xz files can be much faster than whole
    *-debuginfo.rpm.
(z) Symbol server for GDB - no need to download full debuginfos, GDB fetches
    only parts on demand.

Maybe other solutions but it depends which of the 16 combinations of the (1),
(2), (3) and (4) use cases above you choose.


Regards,
Jan


More information about the devel mailing list