"The target is not responding to interrupt requests" after re-attach

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

"The target is not responding to interrupt requests" after re-attach

Dmitry Antipov
I'm trying a "remote" (both gdb and gdbsever are on the same GNU/Linux x86_64 target)
debugging of the following program:

#include <time.h>

int
main (int argc, char *argv[])
{
   struct timespec ts = { .tv_sec = 1, .tv_nsec = 0 };
   while (1)
     nanosleep (&ts, NULL);
   return 0;
}

with 'gdbserver --attach :8888 [PID]' and 'extended-remote' target.
During first debugging session, Ctrl-C works as expected, for example:

$ gdb -q
(gdb) set sysroot /
(gdb) target extended-remote :8888
Remote debugging using :8888
Reading symbols from /tmp/t-nanosleep...done.
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
0x00007eff44c65420 in __nanosleep_nocancel () from /lib64/libc.so.6
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x00007eff44c65420 in __nanosleep_nocancel () from /lib64/libc.so.6
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x00007eff44c65420 in __nanosleep_nocancel () from /lib64/libc.so.6
(gdb) q
A debugging session is active.

        Inferior 1 [process 9320] will be detached.

Quit anyway? (y or n) y
Detaching from program: /tmp/t-nanosleep, process 9320

But it doesn't work for the next time:

$ gdb -q
(gdb) set sysroot /
(gdb) target extended-remote :8888
Remote debugging using :8888
(gdb) attach 9320
Attaching to process 9320
Reading symbols from /tmp/t-nanosleep...done.
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
0x00007eff44c65420 in __nanosleep_nocancel () from /lib64/libc.so.6
(gdb) c
Continuing.
^C
^CThe target is not responding to interrupt requests.
Stop debugging it? (y or n) y

Even if it works as expected, what are the reasons for being inconsistent here?

Dmitry
Reply | Threaded
Open this post in threaded view
|

Re: "The target is not responding to interrupt requests" after re-attach

Pedro Alves-7
On 10/17/2017 03:02 PM, Dmitry Antipov wrote:

> But it doesn't work for the next time:
>
> $ gdb -q
> (gdb) set sysroot /
> (gdb) target extended-remote :8888
> Remote debugging using :8888
> (gdb) attach 9320
> Attaching to process 9320
> Reading symbols from /tmp/t-nanosleep...done.
> Reading symbols from /lib64/libc.so.6...(no debugging symbols
> found)...done.
> Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols
> found)...done.
> 0x00007eff44c65420 in __nanosleep_nocancel () from /lib64/libc.so.6
> (gdb) c
> Continuing.
> ^C
> ^CThe target is not responding to interrupt requests.
> Stop debugging it? (y or n) y
>
> Even if it works as expected, what are the reasons for being
> inconsistent here?
>

No good reason.  Sounds like you found a bug.

Thanks,
Pedro Alves

Reply | Threaded
Open this post in threaded view
|

Re: "The target is not responding to interrupt requests" after re-attach

Dmitry Antipov
On 10/19/2017 02:39 PM, Pedro Alves wrote:

> No good reason.  Sounds like you found a bug.

Currently gdbserver installs SIGIO handler just once, in initialize_async_io ()
called from captured_main (), and this handler is removed when remote_desc
is closed in remote_close (). Next, when a new instance of remote_desc is
fetched from accept () and has '\003' arrived, input_interrupt () is never
called because it is not registered as SIGIO handler.

Probably the fix is to (re)install SIGIO handler each time when a new
async-served descriptor gets hooked into an event loop, for example,
in enable_async_notification ().

Dmitry




gdbserver_sigio_fix.patch (1011 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: "The target is not responding to interrupt requests" after re-attach

Pedro Alves-7

On 10/19/2017 12:57 PM, Dmitry Antipov wrote:

> On 10/19/2017 02:39 PM, Pedro Alves wrote:
>
>> No good reason.  Sounds like you found a bug.
>
> Currently gdbserver installs SIGIO handler just once, in
> initialize_async_io ()
> called from captured_main (), and this handler is removed when remote_desc
> is closed in remote_close (). Next, when a new instance of remote_desc is
> fetched from accept () and has '\003' arrived, input_interrupt () is never
> called because it is not registered as SIGIO handler.
>
> Probably the fix is to (re)install SIGIO handler each time when a new
> async-served descriptor gets hooked into an event loop, for example,
> in enable_async_notification ().

Thanks much for tracking that down.

We could instead not uninstall the handler in remote_close, but
block the signal instead, putting us back in the original
state?   Like:

 @@ -403,10 +403,7 @@ remote_close (void)
  {
    delete_file_handler (remote_desc);

 -#ifndef USE_WIN32API
 -  /* Remove SIGIO handler.  */
 -  signal (SIGIO, SIG_IGN);
 -#endif
 +  disable_async_io ();

I wrote a gdb testsuite/gdb.server/ test exposing this, and
sent a patch to the patches list, after running that through
the testsuite:
  https://sourceware.org/ml/gdb-patches/2017-10/msg00606.html

Thanks,
Pedro Alves