[review v3] [gdb/threads] Fix hang in stop_all_threads after killing inferior

["Tankut Baris Aktemur (Code Review)" <gerrit at gnutoolchain-gerrit dot osci dot io>]

Tankut Baris Aktemur has posted comments on this change.

Change URL: https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/759
......................................................................


Patch Set 3:

I've tried this patch in two scenarios.  One is when multi-threading is
enabled (executable is multi.out), and the other is when the program is
single-threaded (executable is named single1.out and single2.out -- exactly
the same copies just to distinguish the processes).  The test program is
sleep.c from the PR.

I start the multi-threaded case as follows:

  $ gdb -ex "set prompt (master-gdb) " -ex "b stop_all_threads" -ex r -ex \
  "shell killall -9 multi.out" -ex c --args gdb -ex "set debug infrun 1" \
  -ex r  --args multi.out

When gdb stops, I try "info inferiors" and "info threads" commands:

  Thread 1 received signal SIGINT, Interrupt.
  0x00007ffff78a99d0 in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
  infrun: infrun_async(0)
  (gdb) i inferiors
    Num  Description       Connection           Executable
  * 1    process 12979     1 (native)           /path/to/multi.out
  (gdb) i threads
    Id   Target Id                         Frame
  * 1    Thread 0x7ffff7fe3740 (LWP 12979) 0x00007ffff78a99d0 in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
    2    Thread 0x7ffff77c4700 (LWP 12996) Couldn't get registers: No such process.
  (gdb) thread 2
  [Switching to thread 2 (Thread 0x7ffff77c4700 (LWP 12996))]
  Couldn't get registers: No such process.
  (gdb) i threads
  Couldn't get registers: No such process.
  (gdb) thread 1
  Couldn't get registers: No such process.

The second scenario is similar, except that instead of a multi-threaded
single process, we have two single-threaded processes.  Started as

  $ gdb -ex "set prompt (master-gdb) " -ex "b stop_all_threads" -ex r -ex c \
  -ex c -ex "shell killall -9 single1.out" -ex c --args gdb -ex "set debug infrun 1" \
  -ex start -ex "add-inferior -exec ./single2.out" -ex "inferior 2" -ex "start" \
  -ex "set schedule-multiple on" -ex c --args ./single1.out

The behavior is this:

  (gdb) info inferiors
    Num  Description       Connection           Executable
    1    process 2266      1 (native)           /path/to/single1.out
  * 2    process 2282      1 (native)           /path/to/single2.out
  (gdb) info threads
    Id   Target Id                  Frame
    1.1  process 2266               Couldn't get registers: No such process.
  (gdb) inferior 1
  [Switching to inferior 1 [process 2266] (/path/to/single1.out)]
  [Switching to thread 1.1 (process 2266)]
  Couldn't get registers: No such process.
  (gdb) info inferiors
    Num  Description       Connection           Executable
  Couldn't get registers: No such process.
  (gdb) info threads
  Couldn't get registers: No such process.
  (gdb)

So, I think at this point it boils down to the discussion covered in
https://sourceware.org/ml/gdb-patches/2020-01/msg00212.html
and
https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/133
GDB is not able to handle disappeared processes gracefully.  The 
maintainers may consider the fix for the hanging behavior (i.e.  the
infinite loop) OK and the weird post-behavior above as a separate problem
to be addressed later, but my understanding from Pedro's comment was that
the deeper problem of GDB not handling already-gone processes well shall be
addressed.

Thanks
-Baris


-- 
Gerrit-Project: binutils-gdb
Gerrit-Branch: master
Gerrit-Change-Id: Ibe1f29251fe2ff1c1991f041babbe18373c113b1
Gerrit-Change-Number: 759
Gerrit-PatchSet: 3
Gerrit-Owner: Tom de Vries <tdevries@suse.de>
Gerrit-Reviewer: Pedro Alves <palves@redhat.com>
Gerrit-Reviewer: Tom de Vries <tdevries@suse.de>
Gerrit-CC: Mihails Strasuns <mihails.strasuns@intel.com>
Gerrit-CC: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Gerrit-Comment-Date: Mon, 03 Feb 2020 14:30:20 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: No
Gerrit-MessageType: comment