[PATCH] drkonqi: s/backtrace/backtrace full/g

Dominique Devriese dominique.devriese at student.kuleuven.ac.be
Tue Jan 27 13:49:59 GMT 2004

Stephan Kulow writes:

> On Tuesday 27 January 2004 13:59, Dominique Devriese wrote:
>> Stephan Kulow writes:
>> > On Tuesday 27 January 2004 12:26, Dominique Devriese wrote:
>> >> I'm going to commit this to HEAD unless someone objects.
>> > I think, what's needed here is a check if the first bt command
>> > gave any useful output. Otherwise the full one won't add much but
>> > nonsense.
>> Is it a problem to add some more nonsense ?
> Yes, because they just cause work load.

As I already said, the major workload is gdb loading symbols.  Doing
another backtrace won't add that much overhead.  Anyway, I don't think
it is a very significant problem

>> > I would really like to have code in there that hides the fact
>> > that there is a bug tracking system if the user runs the usual
>> > gentoo or mandrake packages ;(
>> Sorry, I'm not familiar with those packages, but I assume you're
>> implying they're broken...  Anyway, this is not really related, or
>> is it ?
> Not broken in the usual sense. Just stripped of any information that
> would make it possible to make sense out of the backtrace

Ok, I see what you mean.  For this purpose, I have some Debian
packages compiled with debugging support on
http://www.kde-debian.org/~domi/debian-kde-debug.html ( the host is
having problems again atm though :( ).  Maybe the Mandrake folk have
something similar ?

I suppose we could grep the gdb output for "(No debugging symbols
found)" or sth like that, and suggest the user downloads debugging
binaries if so ?


More information about the kde-core-devel mailing list