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

Simon Marchi via Gdb-patches
2021-05-13T14:30:44Z

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