Documentation bug (section 4.10)?

[Jens Thoms Toerring]

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  ___      address@hidden
   \__________________________      http://toerring.de