Re: [PATCH] kill all threadapply processes at end of test

[Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>]

Hi Carl,

On 2021-05-12 12:36 p.m., Carl Love via Gdb-patches wrote:
> The threadapply test performs a number of tests to detatch and attach
> threads.  When the test is all done, some detatched threads are left
> running.  The following patch adds code to the end of the patch to kill
> the processes that are still running.

From what I can see, there is not attach in that test, only detach.  GDB
starts some processes itself, and tests that detaching in a "thread
apply" command is correctly handled.  It's these processes that are
detached that are left running.  Fortunately, they exit when the
threads' counters go past INT_MAX, making the condition `*myp > 0`
false.  Unfortunately, it means they consume a lot of CPU for some time
after the test.

> Please let me know if this patch is acceptable.  Thanks.
> 
>                      Carl Love
> 
> --------------------------------------
> 
> gdb/testsuite/ChangeLog:
> 
> 2021-05-12  Carl Love  <cel@us.ibm.com>
> 
> 	* gdb.threads/threadapply.exp: Add foreach loop to kill all remaining
> 	threadapply processes.
> ---
>  gdb/testsuite/gdb.threads/threadapply.exp | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/gdb/testsuite/gdb.threads/threadapply.exp b/gdb/testsuite/gdb.threads/threadapply.exp
> index ebc1cf15ad6..b3457121e76 100644
> --- a/gdb/testsuite/gdb.threads/threadapply.exp
> +++ b/gdb/testsuite/gdb.threads/threadapply.exp
> @@ -229,3 +229,11 @@ proc kill_and_remove_inferior {thread_set} {
>  foreach_with_prefix thread_set {"all" "1.1"} {
>      kill_and_remove_inferior $thread_set
>  }
> +
> +# Make sure all of the threadapply processes are terminated
> +set data [exec ps -e | grep threadapply]
> +
> +foreach line [split $data \n] {
> +    scan $line {%d %s} threadid junk
> +    exec kill -9 $threadid
> +}

We could use "kill" if we had no other choice, but it's a bit of a
rabbit hole to make that portable to all targets.  Instead, could we
redesign the test so there isn't this CPU-consuming loop?  Maybe use
a pthread barrier, such that when we detach, the all threads are
released and the program ends immediately.  I don't know if that will
cause complications because the threads' backtraces won't be exactly
predictable, but it would good to give this a try.

Simon