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