Summary: | Crash Reporting Assistant does not give useful crash information, while gdb does. | ||
---|---|---|---|
Product: | [Applications] drkonqi | Reporter: | Cyp <cyp561> |
Component: | general | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | Hugo.Mildenberger, mail |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Cyp
2009-11-16 10:12:21 UTC
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. |