[Bug 153929] drkonqi "Unable to create a valid backtrace." problem

[kavol]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=153929         
kavol seznam cz changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |



------- Additional Comments From kavol seznam cz  2008-01-30 10:39 -------
> I think we have enough of our own bugs to fix
> (at least I read so somewhere).

closing a bug will magically make it go away?

btw, I guess resolving this bug would actually help fixing the others since you would get more informations

> I would say that the actual problem is that your Gentoo
> is a bit over-optimized and libpthread/libthread_db are stripped

stripping is "over optimizing"? - wov, so, Fedora is over-optimized, Mandriva is over-optimized, even Debian is over-optimized ...

I am reopening the bug: in comment #2 you say "The posted backtraces should not be marked as useless though." - so, if there is a way to get an useful backtrace but drkonqi fails to do so, it's drkonqi's fault

compare the attached console logs - I do not see anything important in the second one which is not present in the first (however, I can be mistaken, I'm not a programmer ...)

I add the corresponding drkonqi output for the second case (after adding debug symbols for glibc):

Application: nspluginviewer (nspluginviewer), signal SIGSEGV
[?1034hUsing host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 0xb7d8a6d0 (LWP 17904)]
[New Thread 0xb3b9ab90 (LWP 17910)]
[New Thread 0xb439bb90 (LWP 17909)]
[New Thread 0xb4b9cb90 (LWP 17908)]
[KCrash handler]
#6  0x4823ed46 in XtRemoveTimeOut () from /usr/lib/libXt.so.6
#7  0xb4ba1000 in ?? ()
#8  0xbff0ea6b in ?? ()
#9  0xbff0ea38 in ?? ()
#10 0xb6032db1 in ?? () from /opt/netscape/plugins/libflashplayer.so
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
#0  0xb7f49410 in __kernel_vsyscall ()

KDE does not exist in "vacuum" - if it is using external tools, it has to be able to cope with any of their possible problems ... you can never ever rely on the assumption that the things work as expected; for example, if somebody writes code for opening a file, a check whether the operation went ok (so that the program does not crash on using a null handle) is a must and I bet you wouldn't argue, but now you say you just issue a command and expect it not to fail without checking any preconditions?

I just looked into kdebase/README and kdebase/runtime/drkonqi/README and there is not a single note about needing glibc debuginfo - so regarding comment #2, it's a packagers fault that he has not a crystall ball to tell him that he has to make drkonqi depending on it?

p.s. sorry for writing in a bit ironical style - I cannot help it to express myself better; I do not want to harm anybody, and I appreciate the work put into KDE and the fact that we discovered the cause of the problem ... now I just would like to make sure that no one runs into it in the future; if there is too much other (more important) work then just postpone the solution but do not say that the problem does not exist