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

[Pedro Franco de Carvalho via Gdb-patches <gdb-patches@sourceware.org>]

Hi Carl,

Another thing, regarding pthread_barrier_wait solution that Simon
suggested.  I'm not sure, but I think the idea would be to initialize a
barrier with a count of as many threads as are created in the test, plus
the main thread.  Then you'd put a call to pthread_barrier_wait before
the exit from the thread_function, and remove the busy loop.  This will
be called by all the created threads shortly after they are created, but
they won't exit until the main itself thread also calls thread_function
and then pthread_barrier_wait.  Assuming the breakpoint in /* Break here
*/ for main happens before that, all threads will be alive for the test
when threadapply.exp calls 'thread apply detach', and they will only
exit after the detach, which would obviate the need for the busy loop.

This would however probably break the previous test with the backtraces,
like Simon said, because the backtrace could put the threads somewhere
in the call to ptrace_barrier_wait, and it might be deeper than one call
depending on the implementation.  If you can find a way to make it also
work with the barriers, and make sure that the other tests in
threadapply also work, that would allow removing the busy loops for all
test.

But if that isn't possible to do for the other tests, if you just want
to avoid having dangling threads, then one idea is to separate the
detach part of the test into another test entirely, that uses the
barrier and no busy loop, just for testing the detach case, or use
another .c for this part of the threadapply test. Not sure if it would
be acceptable to make a separate test.  But the barrier would avoid
having to deal with the pid recycling issue.

Thanks!
--
Pedro Franco de Carvalho

Pedro Franco de Carvalho via Gdb-patches <gdb-patches@sourceware.org>
writes:

> Hello,
>
> I didn't review the patch in detail, but one concern is that this could
> cause a pid recycling issue. After expect gets the pid from the stopped
> inferior, and the gdb under expect detaches from the inferior, it could
> happen that the inferior finishes, there's lots and lots of processes in
> the test system, and that same pid might get reused for a completely
> different process, which GDB would attach to and kill, assuming it has
> ptrace privileges over it. This might be unlikely, but it would be bad
> for the testsuite to kill a random process in the system. I'm not sure
> if there's an easy and portable solution to this.
>
> Apart from that, it might be simpler to do the attaching and killing
> inside proc thr_apply_detach.
>
> Thanks,
> Pedro Franco de Carvalho