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

"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

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

[Pedro Alves]

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

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

[Dmitry Antipov]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

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




[-- Attachment #2: gdbserver_sigio_fix.patch --]
[-- Type: text/x-patch, Size: 976 bytes --]

diff --git a/gdb/gdbserver/remote-utils.c b/gdb/gdbserver/remote-utils.c
index 66e065225b..f686debeaa 100644
--- a/gdb/gdbserver/remote-utils.c
+++ b/gdb/gdbserver/remote-utils.c
@@ -92,6 +92,7 @@ static int readchar_callback = NOT_SCHEDULED;
 static int readchar (void);
 static void reset_readchar (void);
 static void reschedule (void);
+static void input_interrupt (int);
 
 /* A cache entry for a successfully looked-up symbol.  */
 struct sym_cache
@@ -149,6 +150,10 @@ enable_async_notification (int fd)
   fcntl (fd, F_SETOWN, getpid ());
 #endif
 #endif
+  /* Install SIGIO handler.  */
+#ifndef USE_WIN32API
+  signal (SIGIO, input_interrupt);
+#endif
 }
 
 static int
@@ -859,11 +864,6 @@ initialize_async_io (void)
   /* Make sure that async I/O starts blocked.  */
   async_io_enabled = 1;
   disable_async_io ();
-
-  /* Install the signal handler.  */
-#ifndef USE_WIN32API
-  signal (SIGIO, input_interrupt);
-#endif
 }
 
 /* Internal buffer used by readchar.

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

[Pedro Alves]

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