Bug 167911 - drkonqi does not make backtraces of applications that are not in $PATH
Summary: drkonqi does not make backtraces of applications that are not in $PATH
Status: RESOLVED WORKSFORME
Alias: None
Product: drkonqi
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Dario Andres
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-31 22:47 UTC by George Kiagiadakis
Modified: 2009-06-21 12:45 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description George Kiagiadakis 2008-07-31 22:47:49 UTC
Version:            (using KDE 4.1.0)
Installed from:    Debian testing/unstable Packages
Compiler:          gcc version 4.3.1 (Debian 4.3.1-2) 
OS:                Linux

I was wondering for a long time why drkonqi doesn't ever make backtraces of the applications that I develop myself, but it makes backtraces of kde applications... Today I did some research and found out that it makes backtraces only if the application that crashed lives in a directory in $PATH.

First I looked at the drkonqi code and found the hidden "developer mode" option, so I enabled it and then I had a "debugger" button in drkonqi. I made a simple test kde4 application that crashes and run it from my $HOME. It crashed, it opened drkonqi and I clicked the debugger button. This opened gdb in a konsole window, showing this:

GNU gdb 6.8-debian
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 "x86_64-linux-gnu"...
(no debugging symbols found)
Attaching to program: /usr/bin/test, process 1157
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0x00007f52d6c8f210 in ?? ()
(gdb) bt
#0  0x00007f52d6c8f210 in ?? ()
#1  0x00007f52d6c8f064 in ?? ()
#2  0x00007f52d78159f0 in ?? ()
#3  0x0000000000000000 in ?? ()
(gdb)

Notice the "/usr/bin/test"! Remember that I ran this from my $HOME!
Then I looked in ps for the gdb command line and saw this:

 1163 pts/10   Ss+    0:00 /usr/bin/gdb -nw test 1157

This is obviously the wrong command line syntax. It could be far better if it had invoked gdb with this syntax: "gdb --pid 1157". This generates a correct backtrace here.

To double check this, I copied test to /usr/local/bin and then drkonqi was able to make a backtrace.
Comment 1 George Kiagiadakis 2009-06-20 22:19:07 UTC
It seems to be working these days... I assume this was a gdb bug. Closing.
Comment 2 George Kiagiadakis 2009-06-21 12:42:10 UTC
SVN commit 984656 by gkiagia:

Use the -p %pid gdb option also when starting gdb in konsole.
This fixes various situations where the program's name is different than the
one %execname is replaced with or the program is not in $PATH. One situation
is when apps are started by kdeinit, where gdb tries to debug "kdeinit"
(the kde3 version). Another situation is the one I had reported in bug 167911.
CCBUG: 167911


 M  +1 -2      gdbrc  


WebSVN link: http://websvn.kde.org/?view=rev&revision=984656
Comment 3 George Kiagiadakis 2009-06-21 12:45:31 UTC
For the record: it was never a gdb bug. It worked because Lubos Lunak had changed the gdb command in http://websvn.kde.org/?view=rev&revision=830011, but he had only changed the command that is used for generation of the backtrace inside drkonqi. Now I also fixed the command that is used for launching gdb externally in konsole.