On 31 March 2016 at 16:54, Pedro Alves <pal...@redhat.com> wrote:
> On 03/30/2016 04:03 PM, Yvan Roux wrote:
>>
>> 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.
>
> Since the process may ignore SIGTERM/15, seems to me you'd still need
> to wait a bit and kill with SIGKILL/9 if the process doesn't die
> the first time around. So I'm not seeing how, but maybe if you
> showed a snippet it'd be clearer.
Yes, you're right I only used SIGTERM as it was sufficient for the
example.exe issue. Is it correct to think that only SIGKILL is needed
to be passed to all processes the incoming pid is different from -1
(which means got and EOF and stdin can be closed cleanly) ?
The code I've looks more or less to that:
# Return the list of $pids childs
proc get_child_list { pids } {
foreach p $pids {
set cpid [exec sh -c "pgrep -P $p || true"]
append ret $cpid
}
return $ret
}
proc close_wait_program { program_id pid {wres_varname ""} } {
....
if { $pid ne "-1" } {
# Recursively gather child processes pids
set childs [get_child_list $pid]
while {[llength $childs]} {
lappend pid $childs
set childs [get_child_list $childs]
}
exec sh -c "exec > /dev/null 2>&1 && kill -9 $pid"
}
verbose "pid is $pid"
# This closes the program's stdin. This should cause well behaved
# interactive programs to exit. This will hang if the kill
# doesn't work. Nothin' to do, and it's not OK.
catch "close -i $program_id"
# Reap it.
set res [catch "wait -i $program_id" wres]
return $res
}
>> 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....
>
> Thanks,
> Pedro Alves
>
_______________________________________________
DejaGnu mailing list
DejaGnu@gnu.org
https://lists.gnu.org/mailman/listinfo/dejagnu
