Re: process attaching gdb to itself

Re: process attaching gdb to itself

[Michael Elizabeth Chastain]

Hello,

  char cmd [256];
  sprintf (cmd, "gdb attach %d", getpid ());
  system (cmd);

'system' waits for the program that it calls to finish.
Thus, your program is waiting for gdb to finish before it
does anything.

Try the appended program which uses raw fork/exec.
It works for me on red hat linux 8, native i686-pc-linux-gnu.

If you try to do this in production code then you are likely
to run into a blizzard of race conditions, error cases,
and signal handling problems.  If you are doing this as a learning
experience, that's great -- read up on 'man fork' and
'man execlp', and check out a book on Linux systems programming.

Michael C
GDB QA Guy

===

  #include <stdio.h>

  int main ()
  {
    int pid = fork ();
    if (pid == -1)
    {
      /* error */
      fprintf (stderr, "fork error\n");
      exit (2);
    }

    if (pid != 0)
    {
      /* parent process */
      char spid [256];
      sprintf (spid, "%d", pid);
      execlp ("gdb", "gdb", "a.out", spid, NULL);
      /* execlp returns only if error */
      fprintf (stderr, "execlp error\n");
      _exit (2);
    }

    /* child process */
    sleep (5);
    printf ("hello hacker\n");
    return 0;
  }

Re: process attaching gdb to itself

[Andrew Cagney]

> Hello,
> 
>   char cmd [256];
>   sprintf (cmd, "gdb attach %d", getpid ());
>   system (cmd);
> 
> 'system' waits for the program that it calls to finish.
> Thus, your program is waiting for gdb to finish before it
> does anything.
> 
> Try the appended program which uses raw fork/exec.
> It works for me on red hat linux 8, native i686-pc-linux-gnu.
> 
> If you try to do this in production code then you are likely
> to run into a blizzard of race conditions, error cases,
> and signal handling problems.  If you are doing this as a learning
> experience, that's great -- read up on 'man fork' and
> 'man execlp', and check out a book on Linux systems programming.

Is the kernel Linux?  JeffJ and I just discovered that:

$ sleep 1000
^Z
PID 1234 suspended
$ gdb sleep 1234
...
(gdb)

works on BSD but fails on GNU/Linux.  When doing an attach, BSD always 
generates something for wait4 to consume. GNU/Linux does not, leaving 
GDB stuck in wait4 :-(

Andrew

Re: process attaching gdb to itself

[Daniel Jacobowitz]

On Sun, Sep 28, 2003 at 06:35:24PM -0400, Andrew Cagney wrote:
> >Hello,
> >
> >  char cmd [256];
> >  sprintf (cmd, "gdb attach %d", getpid ());
> >  system (cmd);
> >
> >'system' waits for the program that it calls to finish.
> >Thus, your program is waiting for gdb to finish before it
> >does anything.
> >
> >Try the appended program which uses raw fork/exec.
> >It works for me on red hat linux 8, native i686-pc-linux-gnu.
> >
> >If you try to do this in production code then you are likely
> >to run into a blizzard of race conditions, error cases,
> >and signal handling problems.  If you are doing this as a learning
> >experience, that's great -- read up on 'man fork' and
> >'man execlp', and check out a book on Linux systems programming.
> 
> Is the kernel Linux?  JeffJ and I just discovered that:
> 
> $ sleep 1000
> ^Z
> PID 1234 suspended
> $ gdb sleep 1234
> ...
> (gdb)
> 
> works on BSD but fails on GNU/Linux.  When doing an attach, BSD always 
> generates something for wait4 to consume. GNU/Linux does not, leaving 
> GDB stuck in wait4 :-(

Yes, I've known about this problem for a long time.  We've [I, Roland,
a couple of other people I can't recall] talked about changing it and
decided that, really, the current behavior makes more sense.

It's not at all hard to make GDB work in the current system anyway. 
Just have to do it.  It goes something like:
  - attach
  - wait4 WNOHANG, break if succeeds (optimistic, not necessary)
  - check in /proc to make sure the process is in a stopped state
    - If it was:
      - wait4 WNOHANG
        - If we get a status, then the process was running when we attached
        - If no status is available then the process was stopped when
          we attached
    - If it wasn't:
      - The process was running when we attached and hasn't stopped yet
      - wait4 without WNOHANG


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: process attaching gdb to itself

[Andrew Cagney]

>> works on BSD but fails on GNU/Linux.  When doing an attach, BSD always 
>> generates something for wait4 to consume. GNU/Linux does not, leaving 
>> GDB stuck in wait4 :-(
> 
> 
> Yes, I've known about this problem for a long time.  We've [I, Roland,

This explains something.

> a couple of other people I can't recall] talked about changing it and
> decided that, really, the current behavior makes more sense.

Not to me.

GDB sends a message to the kernel asking for the process to stop.  The 
kernel sends a message back indicating that the request has completed.

> It's not at all hard to make GDB work in the current system anyway. 
> Just have to do it.  It goes something like:
>   - attach
>   - wait4 WNOHANG, break if succeeds (optimistic, not necessary)
>   - check in /proc to make sure the process is in a stopped state
>     - If it was:
>       - wait4 WNOHANG
>         - If we get a status, then the process was running when we attached
>         - If no status is available then the process was stopped when
>           we attached
>     - If it wasn't:
>       - The process was running when we attached and hasn't stopped yet
>       - wait4 without WNOHANG

I feel ill.  What happens, for instance, if /proc isn't there?

Andrew

Re: process attaching gdb to itself

[Daniel Jacobowitz]

On Mon, Sep 29, 2003 at 09:21:55AM -0400, Andrew Cagney wrote:
> 
> >>works on BSD but fails on GNU/Linux.  When doing an attach, BSD always 
> >>generates something for wait4 to consume. GNU/Linux does not, leaving 
> >>GDB stuck in wait4 :-(
> >
> >
> >Yes, I've known about this problem for a long time.  We've [I, Roland,
> 
> This explains something.

I beg your pardon?

> >a couple of other people I can't recall] talked about changing it and
> >decided that, really, the current behavior makes more sense.
> 
> Not to me.
> 
> GDB sends a message to the kernel asking for the process to stop.  The 
> kernel sends a message back indicating that the request has completed.

The kernel generates a message at each change of the program's state. 
It isn't changing state; it was already stopped.  This behavior allows
the debugger to determine if the program was stopped before attach; I
can easily picture a multi-threaded daemon design that leaves parts of
itself SIGSTOP'd and would get confused if unexpectedly wakened.

> >It's not at all hard to make GDB work in the current system anyway. 
> >Just have to do it.  It goes something like:
> >  - attach
> >  - wait4 WNOHANG, break if succeeds (optimistic, not necessary)
> >  - check in /proc to make sure the process is in a stopped state
> >    - If it was:
> >      - wait4 WNOHANG
> >        - If we get a status, then the process was running when we attached
> >        - If no status is available then the process was stopped when
> >          we attached
> >    - If it wasn't:
> >      - The process was running when we attached and hasn't stopped yet
> >      - wait4 without WNOHANG
> 
> I feel ill.  What happens, for instance, if /proc isn't there?

At this point in its life, Linux can just assume the /proc filesystem
is available.  Linus has repeatedly refused to duplicate information
available via /proc through another interface.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: process attaching gdb to itself

[Andrew Cagney]

>> I feel ill.  What happens, for instance, if /proc isn't there?
> 
> 
> At this point in its life, Linux can just assume the /proc filesystem
> is available.  Linus has repeatedly refused to duplicate information
> available via /proc through another interface.

Sounds like the GNU/Linux back end should, finally, switch to /proc?

Andrew

Re: process attaching gdb to itself

[Daniel Jacobowitz]

On Mon, Sep 29, 2003 at 10:52:50AM -0400, Andrew Cagney wrote:
> >>I feel ill.  What happens, for instance, if /proc isn't there?
> >
> >
> >At this point in its life, Linux can just assume the /proc filesystem
> >is available.  Linus has repeatedly refused to duplicate information
> >available via /proc through another interface.
> 
> Sounds like the GNU/Linux back end should, finally, switch to /proc?

Don't we just wish?

No one's implemented enough of the BSD-style /proc for it to replace
ptrace.  It would be nice if someone did, but it turned out to be a
bigger task than I had time for.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

process attaching gdb to itself

[Aurelien Chanudet]

Hi all,

How can I have a running process gracefully attach gdb to itself ? I've 
tried something like :

char cmd [256];
sprintf (cmd, "gdb attach %d", getpid ());
system (cmd);

which has the desired effect. However, once in gdb, the debugger is 
stuck in wait4(2) and I cannot  find a way to resume execution.

Thanks,
Aurelien