Debug KDE2 with internal debugger (was Re: BUG in german translation)

[jbb]

On Tue, 25 Jan 2000, you wrote:
> On Tue, 25 Jan 2000, you wrote:
> 
> > BTW: How could one debug KDE2 applications with the internal debugger?
> 
> If you have kdevelop1.1 running under kde2 correctly (which is not difficult)
> then
> 
> - If you've managed to make a kde2 kdevelop project then just press debug. Make
> sure to set "bin_program=.libs/project", if necessary in project.kdevprj.
> 
>  - If it's not a kdevelop project, but it's an ordinary executable, then
> debug using the "other executable" option.
> 
> - If it's a dlopen'd library, launched by kinit (kdeinit?), then build a
> kinit project first and then debug with arguments. Make sure you have "Try
> setting BPs on lib load" checked in the debugger options so that breakpoints
> can be set in the lib correctly. kinit shouldn't need debug symbols on, but your
> library will, of course.

oops, this last suggestion won't work as kinit forks and then loads the lib. gdb
will follow the parent process not the child.

This is in gdb help but is not implemented in kdevelop

"(gdb) help set follow
Set debugger response to a program call of fork or vfork.
A fork or vfork creates a new process.  follow-fork-mode can be:
  parent  - the original process is debugged after a fork
  child   - the new process is debugged after a fork
  ask     - the debugger will ask for one of the above choices
For "parent" or "child", the unfollowed process will run free.
By default, the debugger will follow the parent process.     "


However the GDB info pages says this

"   GDB has no special support for debugging programs which create 
additional processes using the `fork' function.  When a program forks, 
GDB will continue to debug the parent process and the child process 
will run unimpeded.  If you have set a breakpoint in any code which the 
child then executes, the child will get a `SIGTRAP' signal which 
(unless it catches the signal) will cause it to terminate. 

However, if you want to debug the child process there is a workaround 
which isn't too painful.  Put a call to `sleep' in the code which the 
child process executes after the fork.  It may be useful to sleep only 
if a certain environment variable is set, or a certain file exists, so 
that the delay need not occur when you don't want to run GDB on the 
child.  While the child is sleeping, use the `ps' program to get its 
process ID.  Then tell GDB (a new invocation of GDB if you are also 
debugging the parent process) to attach to the child process (see Attach
).  From that point on you can debug the child process just
like any other process which you attached to. "

Contradictory to gdb help, but the principle of attaching to process can be
used here.

-- 
Regards,

jbb
http://homepages.ihug.co.nz/~jbb
ICQ: 60412209