Hi, In section 4.10 (Debugging Programs with Multiple Processes) you will find as the second paragraph:
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 (*note Attach::). From that point on you can debug the child process just like any other process which you attached to. That used to do the job until some time ago, but nowadays you don't seem to get out of the sleep() command anymore. It looks to me as if (IIRC) in older versions of gdb the process you did attach to received a SIGTRAP signal that got one out of the sleep() function, but that in newer versions this SIGTRAP signal isn't send anymore and thus the scheme proposed in the manual fails. Instead of using a call to sleep() in this kind of situation I found that calling 'raise(SIGSTOP)' now works (although you have to do a 'next' or 'step' a few times until you arrive at the next line of code). I.e. to be able to start debugging at the printf() line one would need int main( void ) { if ( ! fork( ) ) { raise( SIGSTOP ); printf( "Child is running\n" ); exit( 0 ); } wait( NULL ); return 0; } Can someone confirm this observation or tell me what I'm doing wrong? Is there a better method than using raise() with SIGSTOP? Best regards, Jens -- \ Jens Thoms Toerring ___ j...@toerring.de \__________________________ http://toerring.de _______________________________________________ bug-gdb mailing list bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb