drkonqi and backtrace analysis

Thiago Macieira thiago at kde.org
Tue Aug 5 13:41:42 BST 2008

On Tuesday 05 August 2008 12:35:01 Lubos Lunak wrote:
> On Monday 04 of August 2008, Thiago Macieira wrote:
> > On Monday 04 August 2008 12:54:27 Lubos Lunak wrote:
> > I'd say:
> > 1) no new features in the 4.1 branch; backport the fixes, but not the
> > feature or the new i18n
>  Well, I know this general rule, and that's why I asked. If I don't
> backport anything, we get even more reports with useless info. If I
> backport only the fixes, we will get bugreports even without it, just with
> complaints that drkonqi doesn't let them save the backtrace and that they
> don't know what to do. No big difference. Ok, we now have a bugsquad, but I
> still don't see why not help them a little.

How about showing the backtrace if the user really wants it? Append to the 
report, after the warning that it seems to be useless.

> > 2) how are you accomplishing this detection? Are you using the fact that
> > gdb says you should install more debuginfo packages?
>  Does it? Where?

$ gdb --pid `pidof plasma`
GNU gdb 6.8-1mdv2009.0 (Mandriva Linux release 2009.0)                                      
Copyright (C) 2008 Free Software Foundation, Inc.                                           
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>               
This is free software: you are free to change and redistribute it.                          
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"                  
and "show warranty" for details.                                                            
This GDB was configured as "i586-mandriva-linux-gnu".                                       
Attaching to process 12909                                                                  
Reading symbols from /home/tmacieir/KDE4/bin/plasma...done.                                 
[snip long list of Reading / Loaded symbols]
Loaded symbols for /lib/libnss_files.so.2
0xffffe424 in __kernel_vsyscall ()
Missing debug package(s), you should install: OpenEXR-debug bzip2-debug dbus-
debug fontconfig-debug freetype2-debug gamin-debug gcc-debug glib2.0-debug 
ilmbase-debug jasper-debug lcms-debug libice-debug libjpeg-debug libmng-debug 
libpng-debug libsm-debug libtiff-debug libx11-debug libxau-debug libxcb-debug 
libxcomposite-debug libxcursor-debug libxdmcp-debug libxext-debug libxfixes-
debug libxft-debug libxi-debug libxinerama-debug libxml2-debug libxpm-debug 
libxrandr-debug libxrender-debug libxtst-debug mesa-debug pcre-debug sqlite3-
debug zlib-debug

I have no idea how gdb comes up with that list. But the fact that gdb links to 
librpm-4.4.so and librpmdb-4.4.so may be an indication.

> > If so, maybe you could show the backtrace and simply add some text and
> > another button at the bottom of the dialog.
>  It normally analyzes the output from gdb and guesses from the backtrace.
> See BackTraceGdb::checkUsefulBacktrace().

All it has to do is call installdebuginfo with the information from gdb. 
There's no need to guess anything.

> > 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.
>  It is not the distro who usually gets the report though, and the distro
> also doesn't know where in the backtrace a library is needed.

What I meant is that you *probably* don't need most of the packages that gdb 
prints. That list above came from the list of everything that was loaded into 

> > 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.
>  That backtrace is currently not considered to be good enough, regardless
> of the irrelevant thread 1, but I take this that it should be strict only
> with really broken backtraces.

Then you should be less strict. In any case, not hide the backtrace.

  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/20080805/9e30d356/attachment.sig>

More information about the kde-core-devel mailing list