dejagnu
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PID-reuse races fix, introduced GCC validation brakage


From: Christophe Lyon
Subject: Re: PID-reuse races fix, introduced GCC validation brakage
Date: Wed, 30 Mar 2016 17:18:39 +0200

On 30 March 2016 at 17:03, Yvan Roux <address@hidden> wrote:
> Hi,
>
> https://lists.gnu.org/archive/html/dejagnu/2015-07/msg00000.html
>
> this patch introduced  a new failure related to GDB testing, but this
> time in GCC guality part of the testsuite.  When
> gcc/testsuite/gcc.dg/guality/example.c is executed we have this set of
> processes started
>
> PID  PPID     command
> 100  99          ./example.exe
> 101  99          cat
> 102  100        sh -c gdb -nx -nw --quiet > /dev/null 2>&1 ./example.exe
> 103  102        gdb -nx -nw --quiet ./example.exe
>
> The issue is that when close_wait_program is called pid="100 101" and
> when the "wait" returns none of these 4 processes is actually killed,
> and the killing of the "kill pipeline" made these pids untouched and
> the validation hangs forever.
>

It seems to me that close_wait_program assumes that pid is a number,
while it can be list.

Or am I mistaken?

> I not sure what's the best way to fix this issue without
> re-introducing the pid race in GDB.  I'm testing a solution which
> first gather all the childs processes of the close_wait_program pid
> input (with a recursive call of pgrep -P) and then kill them all with
> a -15, my assumption is that killing explicitly all the processes
> (maybe in the child -> parent order) will avoid the need of stdin
> closing and the pid re-use race, but I might be wrong, and all
> comments are welcome.  It works so far on a subset of the testsuite,
> but I'm still validating this approach.  Now, maybe just the reducing
> the sleeping time might workaround the issue....
>
> Cheers,
> Yvan
>
> _______________________________________________
> DejaGnu mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/dejagnu



reply via email to

[Prev in Thread] Current Thread [Next in Thread]