Version: (using KDE 4.3.1) Compiler: gcc-4.3.4 OS: Linux Installed from: Gentoo Packages Here is the complete crash information from drkonqi: Application: Run Command Interface (kdeinit4), signal: Segmentation fault [Current thread is 0 (process 8781)] gdb gives a lot more information for the same crash - see bug 214774 for the output of gdb. In case it's relevant, I'm using "splitdebug", so the debug information for all programs is located in /usr/lib/debug/ instead of in the executables or libraries.
I have noticed that this happens some times. I was under the impression that this happens when the debug symbols in /usr/lib/debug do not match the executable that is running (because they are a different version, probably because they were upgraded while kde was running), but in this case it is really strange... The thing is that it is gdb that gives the incomplete backtrace, so it's not entirely drkonqi's fault.
I do have the same problem with hardened gentoo ~x86, using sys-devel/gdb-6.8-r1 and kde-base/drkonqi-4.3.4 (not that drkonqi ever worked within my environment)
Running kdebugdialog on drkonqi as suggested in BUG #217742, I had the following in ~/.xsession-errors: drkonqi(9110) BacktraceLineGdb::parse: garbage detected: "0x5559b422 in _start () from /lib/ld-linux.so.2 " drkonqi(9110) BacktraceLineGdb::parse: garbage detected: "Current language: auto; currently c Doing the same with, say, gdb -p $(pgrep kwrite) and killall -s SIGSEGV $(which kwrite), gdb actually has no symbols. gdb -p $(pgrep kwrite) GNU gdb 6.8 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 "i686-pc-linux-gnu". Attaching to process 9082 Reading symbols from /usr/bin/kwrite...Reading symbols from /mnt/hda1/debug/usr/bin/kwrite.debug...done. done. 0x53c65422 in _start () from /lib/ld-linux.so.2 (gdb) bt #0 0x53c65422 in _start () from /lib/ld-linux.so.2 #1 0x523b6df0 in ?? () #2 0x00000000 in ?? () Current language: auto; currently c
@Hugo: In your case gdb doesn't give any useful information at all, so this is not a drkonqi bug. Drkonqi relies completely on gdb. You probably have build your system without debug symbols, so what you can do is consult the gentoo manuals on how to build with debug symbols.
@George: it's very simple with gentoo to have debug symbols and sources ready (add -ggdb to CFLAGS/CXXFLAGS, and put "splitdebug" and "installsources" into FEATURES within /etc/make.conf) before emerging packets. But the problem here seems to be two-fold: 1.) gdb-6.8-r1/r2 does not work correctly on Gentoo's hardened x86/amd64 platforms (only analyzing post mortem dumps works, to some usable extend), and 2.) drkonqi is probabably somewhat confused: drkonqi(9110) BacktraceLineGdb::parse: garbage detected: "0x5559b422 in _start () from /lib/ld-linux.so.2 " drkonqi(9110) BacktraceLineGdb::parse: garbage detected: "Current language: auto; currently c Though there are no symbols, it's not exactly garbage.
(In reply to comment #5) > @George: it's very simple with gentoo to have debug symbols and sources ready > (add -ggdb to CFLAGS/CXXFLAGS, and put "splitdebug" and "installsources" into > FEATURES within /etc/make.conf) before emerging packets. But the problem here > seems to be two-fold: > > 1.) gdb-6.8-r1/r2 does not work correctly on Gentoo's hardened x86/amd64 > platforms (only analyzing post mortem dumps works, to some usable extend), and Report a bug to gentoo or gdb. > 2.) drkonqi is probabably somewhat confused: > > drkonqi(9110) BacktraceLineGdb::parse: garbage detected: "0x5559b422 in _start > () from /lib/ld-linux.so.2 > " > drkonqi(9110) BacktraceLineGdb::parse: garbage detected: "Current language: > auto; currently c > > Though there are no symbols, it's not exactly garbage. DrKonqi is working fine. Those lines are correctly detected as garbage because they *are* garbage to us. They are not providing any useful information and they are discarded from all backtraces. DrKonqi only keeps the stack frames in the report. Notice in your output that the stack frames (those starting with #number) are not marked as garbage ;)
I also use 'splitdebug' feature on my Gentoo system, but never have noticed such problem. Close this old report, but feel free to reopen if you can still reproduce the problem.