gdb usage hint

[Jens Zurheide]

Yippie!!!!

Finally I found out how to attach to a running kdevelop with the debugger 
and get the symbols of all shared libraries loaded. (Those of you who know 
how to do this can skip the rest of this email.) Finally I can try to track 
down the reason why kdevelop sometimes gets slower and slower and finally 
nearly stops responding. The problem is that this bug has to occur once 
again.

Ok, for those that experience the problem and have kdelibs, qt, and 
kdevelop compiled with debug symbols, the trick is the following:

do a 
> ps aux | grep kdevelop 
to get the process id of kdevelop that is not responding any more. Other 
preparation step might include 
> export LD_BIND_NOW=1
> export LD_LIBRARY_PATH=[path to your shared debug libs]:$LD_LIBRARY_PATH
Then start gdb and enter 
(gdb) file kdevelop
If necessary use the correct path to the executable (which might be in the 
directory .libs if kdevelop is directly started from the build dir without 
installing it first). Then set a breakpoint at the main function and start 
the execution.
(gdb)b main
(gdb)r
Now, all symbols are loaded and you can attach to the stopped kdevelop
(gdb)attach <whatever_your_pid_is>. Answer 'y' to the question about 
killing the already running program

If you prefer kdbg the above steps need some modifications but it should 
work rather similar.

I hope this might help someone some day to get some nasty and hard to 
reproduce bugs squashed.

Have fun,
Jens