On 30 March 2016 at 17:37, Christophe Lyon <christophe.l...@linaro.org> wrote: > On 30 March 2016 at 17:28, Yvan Roux <yvan.r...@linaro.org> wrote: >> On 30 March 2016 at 17:18, Christophe Lyon <christophe.l...@linaro.org> >> wrote: >>> On 30 March 2016 at 17:03, Yvan Roux <yvan.r...@linaro.org> 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? >> >> yes, that's it, only the first element of the pid list gets the "-" >> for the group pid for instance, but it has no real impact, at least on >> the cases I looked at. My on-going fix cleans that as well. >> > I meant: what does this do: > if { $pid > 0 } > when pid is actually a list?
it works as expected when it's not a list, it's true >>>> 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 >>>> DejaGnu@gnu.org >>>> https://lists.gnu.org/mailman/listinfo/dejagnu _______________________________________________ DejaGnu mailing list DejaGnu@gnu.org https://lists.gnu.org/mailman/listinfo/dejagnu
