drkonqi and backtrace analysis

Thiago Macieira thiago at kde.org
Mon Aug 4 14:03:26 BST 2008


On Monday 04 August 2008 12:54:27 Lubos Lunak wrote:
>  Therefore I'd like to commit the attached patch which should try harder
> when analysing the backtrace and should also collect information about
> which binaries are missing debuginfo. The idea is that distributions will
> also ship $KDEDIR/lib/kde4/libexec/installdebuginfo [1], and if it is
> available then drkonqi will offer installing the necessary debugging
> packages and try again.

Good! That's a nice idea.

>  I would like to also backport this to 4.1, together with the fixes which
> already are in trunk, but a) this adds new i18n, and b) I think it needs
> some testing, as there are still some issues I'm unsure about, such as: 
> -  the dialog offering to install debugging packages hides the backtrace, so
> one cannot actually tell if it's really necessary - any ideas for a better
> UI solution?
> - it currently lists even things like libc in the list of libraries needing
> debuginfo if it's present in the backtrace, which may not be usually
> necessary - should it restrict the list just to KDE/Qt libs or any better
> ideas?
> - it is a question whether the detection whether a backtrace is or is not
> useless is not too strict - e.g. the backtrace from [2] is currently
> flagged [3] as useless (with the copy and save buttons disabled), but it
> looks like it could be actually good enough - is it ok to still complain,
> or any ideas?

I'd say:
1) no new features in the 4.1 branch; backport the fixes, but not the feature 
or the new i18n

2) how are you accomplishing this detection? Are you using the fact that gdb 
says you should install more debuginfo packages? If so, maybe you could show 
the backtrace and simply add some text and another button at the bottom of the 
dialog.

3) the list of libraries to be installed should be trimmed by the 
installdebuginfo script that the distribution supplies. If the distro thinks 
installing debuginfo for libc and glib is not necessary, then so be it.

4) the backtrace at [2] below is an corner case: the crash happened in thread 
6, which has a good enough backtrace, but thread 1 is completely useless. On 
the other hand, if you're not strict enough, the worst case scenario is that 
we stay where we are right now.

> [1] see Debuginfo::installDebuginfo() for invocation
> [2] http://lists.kde.org/?l=kde-devel&m=121784325621415&w=2
> [3] for debugging it is possible to make it process any backtrace, see
> beginning of BackTraceGdb::processDebuggerOutput()


-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080804/73739d43/attachment.sig>


More information about the kde-core-devel mailing list