Version: CVS (using KDE Devel) Installed from: Compiled sources I am using an update to date Fedora core and 2.6 kernel with KDE CVS. I have not been able to get stack traces from the KDE crash handler for several months now. The crash handler may need to be adjusted for TLS changes made by Redhat. For example I just crashed kdevelop and got this: Using host libthread_db library "/lib/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 1088776224 (LWP 5417)] [New Thread 1109752752 (LWP 5430)] 0xffffe410 in ?? () #0 0xffffe410 in ?? () #1 0xbfffd46c in ?? () I am sure that I am built debug with symbols. 0xffffe410 does not look like a valid address.
Not KDevelop. Reassigning.
*** Bug 71765 has been marked as a duplicate of this bug. ***
This bug is still there (Debian unstable exhibits it, too), and it is very annoying. It also breaks "Debug in KDevelop" because the backtraces are unusable. Any progress on that bug?
sorry, but gdb is doing the stacktraces. You better contact bugs.debian.org
When I use GDB the traces are perfectly OK. Only KDE gets them totally wrong. How is this a problem in GDB? Suggest to reopen this bug.
I concur. traces from gdb are fine, that's how I am working around the problem.
Also, I am using Redhat Fedora, not Debian. I believe the new features in gdb for nptl have changed the what the crash handler is expecting to get back from the debugger. The crash handler needs to be adjusted for this and fixed to send the new commands. All current kernels both 2.4 and 2.6 have nptl now.
even when attached to a running process?
The debugger in kdevelop works correctly. It is only the crash handler that has a problem.
I've been getting a similar problem for a while (funnily enough, I'm looking in to it now because KDevelop 3.0.0 is crashing frequently). With gdb 6.0, I get this: #0 0x419427e8 in waitpid () from /lib/libpthread.so.0 #1 0x40f7e64c in __JCR_LIST__ () from /usr/kde/3.2/lib/libkdecore.so.4 #2 0x40ec202b in KCrash::defaultCrashHandler(int) (sig=11) at kcrash.cpp:246 #3 0x419414d3 in __pthread_sighandler () from /lib/libpthread.so.0 #4 0xffffd420 in ?? () #5 0x0000000b in ?? () #6 0x00000033 in ?? () and with gdb 5.3, I get this: 0x419427e8 in waitpid () from /lib/libpthread.so.0 #0 0x419427e8 in waitpid () from /lib/libpthread.so.0 #1 0x40f7e64c in __JCR_LIST__ () from /usr/kde/3.2/lib/libkdecore.so.4 By running kdevelop from gdb, I can get full backtraces.
I introduced "memset (0, 42, 1000);" into kolourpaint to crash it. Here are the results of gdb vs drkonqi: (gdb) r Starting program: /home/kdevel/cvs/kdegraphics/kolourpaint/kolourpaint Program received signal SIGSEGV, Segmentation fault. 0x4142e417 in memset () from /lib/i686/libc.so.6 Current language: auto; currently c (gdb) bt #0 0x4142e417 in memset () from /lib/i686/libc.so.6 #1 0xbffff474 in ?? () #2 0x0806ee64 in kpMainWindow (this=0x81933f8) at kpmainwindow.cpp:66 #3 0x080665bd in main (argc=1, argv=0xbffff474) at kolourpaint.cpp:139 #4 0x413d0082 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) q The program is running. Exit anyway? (y or n) y ---------------- This backtrace appears to be of no use. This is probably because your packages are built in a way which prevents creation of proper backtraces, or the stack frame was seriously corrupted in the crash. 0x41456739 in wait4 () from /lib/i686/libc.so.6 #0 0x41456739 in wait4 () from /lib/i686/libc.so.6 #1 0x414d3340 in sys_sigabbrev () from /lib/i686/libc.so.6 #2 0x412b0a73 in waitpid () from /lib/i686/libpthread.so.0 #3 0x408c0ee3 in KCrash::defaultCrashHandler(int) () from /home/kdevel/dist/lib/libkdecore.so.4
Drkonqi has never been able to gather useful backtraces on FreeBSD, regardless of gcc, gdb, KDE or FreeBSD version. If there's also an issue on Linux at the moment, I suggest looking into ways of fixing this carefully so the backtrace tab works reliably on all platforms.
Regarding my Comment #11, I only compile _parts_ of KDE with -g to improve compile time and reduce binary sizes. At least with gdb, you can _still_ get meaningful backtraces with function names, just not line numbers (for the bits you didn't compile with -g). With Dr Konqi, I get nothing.
It seems Dr Konqi as of KDE 3.2.3 now works in FreeBSD-CURRENT. I couldn't find out what suddenly makes it work though.
On Wed, Jul 14, 2004 at 01:10:48PM -0000, Michael Nottebrock wrote: > It seems Dr Konqi as of KDE 3.2.3 now works in FreeBSD-CURRENT. I couldn't > find out what suddenly makes it work though. My be a -CURRENT change, doesn't work on 5.2 nor 5.2.1 for me. Rob
It should be an gdb - NPTL problem, export LD_ASSUME_KERNEL=2.4.1 work arounds the issue. Actually when gdb attaches to the crashed process, it cannot generate an useful backtrace, it's nothing to do with drkonqi. (Maybe need to use some command line switches?).
On Tue, 14 Sep 2004 06:20 pm, Szombathelyi György wrote: > It should be an gdb - NPTL problem I have a feeling there are multiple causes of this bug because I don't have NPTL.
I used the following method to seperate a drkonqi bug from gdb: 1. Wait for a crash and drkonqi will pop up 2. Attach gdb to the crashed process (like drkonqi): gdb processname pid 3. Get a backtrace from gdb: bt 4. Compare with drkonqi's result: they are identical and both unuseful. So it seems that it's not a drkonqi bug. With LD_ASSUME_KERNEL=2.4.1 both results were useful.
On Mon, 20 Sep 2004 10:51 pm, Szombathelyi György wrote: > I used the following method to seperate a drkonqi bug from gdb: > 1. Wait for a crash and drkonqi will pop up > 2. Attach gdb to the crashed process (like drkonqi): gdb processname pid > 3. Get a backtrace from gdb: bt > 4. Compare with drkonqi's result: they are identical and both unuseful. So > it seems that it's not a drkonqi bug. With LD_ASSUME_KERNEL=2.4.1 both > results were useful. With all combinations of linux 2.4/2.6.8.1 with and without LD_ASSUME_KERNEL=2.4.1, Dr Konqi says: ~~~~ This backtrace appears to be of no use. This is probably because your packages are built in a way which prevents creation of proper backtraces, or the stack frame was seriously corrupted in the crash. ~~~~ gdb: [kdevel@tux kdevel]$ kolourpaint& [1] 3841 [kdevel@tux kdevel]$ ps waux | grep kolourpaint kdevel 3841 26.8 8.8 26176 16800 pts/2 S 08:42 0:03 kolourpaint kdevel 3843 0.0 0.3 1672 596 pts/2 S 08:42 0:00 grep kolourpaint [kdevel@tux kdevel]$ kill -SIGSEGV 3841 KCrash: crashing... crashRecursionCounter = 2 KCrash: Application Name = kolourpaint path = <unknown> pid = 3841 [kdevel@tux kdevel]$ gdb `which kolourpaint` 3841 (...) 0x41455749 in wait4 () from /lib/i686/libc.so.6 (gdb) bt #0 0x41455749 in wait4 () from /lib/i686/libc.so.6 #1 0x414d2340 in sys_sigabbrev () from /lib/i686/libc.so.6 #2 0x412a8a73 in waitpid () from /lib/i686/libpthread.so.0 #3 0x40903587 in KCrash::defaultCrashHandler(int) () from /home/kdevel/dist/lib/libkdecore.so.4 (gdb) But during ordinary operation, a gdb that's attached _can_ produce a bt: (gdb) bt #0 0x4147e11e in select () from /lib/i686/libc.so.6 #1 0x410fbfd4 in __JCR_LIST__ () from /home/kdevel/cvs/qt-copy/lib/libqt-mt.so.3 #2 0x40cbf23f in QEventLoop::enterLoop() () from /home/kdevel/cvs/qt-copy/lib/libqt-mt.so.3 #3 0x40cbf104 in QEventLoop::exec() () from /home/kdevel/cvs/qt-copy/lib/libqt-mt.so.3 #4 0x40caf3c0 in QApplication::exec() () from /home/kdevel/cvs/qt-copy/lib/libqt-mt.so.3 #5 0x0806b46e in main (argc=1, argv=0xbffff494) at kolourpaint.cpp:181 #6 0x413cf082 in __libc_start_main () from /lib/i686/libc.so.6
*** This bug has been confirmed by popular vote. ***
Using gdb-6.2.1 seems to correct this (see Bug 98934)
Can somebody still reproduce this problem (that is, drkonqi itself gives useless backtrace, but gdb started from drkonqi works fine [*]) ? [*] http://techbase.kde.org/index.php?title=Development/FAQs/Debugging_FAQ#How_do_I_switch_Dr_Konqi_to_developer_mode.3F
And note that the gdb commands used by drkonqi are actually "thread" and "thread apply all bt".
Waiting for a response.