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

Pedro Alves <[email protected]>
Newsgroups gmane.comp.sysutils.dejagnu.general
Message-ID <[email protected]>
On 03/30/2016 04:03 PM, Yvan Roux 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.

The questions I'm not seeing answered are:

 - How did this work before?

 - What exactly in the patch causes the regression?

AFAICS, before my patch we had:

- if { $pid > 0 } {
-    verbose "doing kill, pid is $pid"
-    # This is very, very nasty. SH, instead of EXPECT, is used
-    # to run this in the background since, on older CYGWINs, a
-    # strange file I/O error occures.
-    set pgid "-[join $pid { -}]"

while my patch changed it to:

+    if { $pid > 0 } {
+       # Tcl has no kill primitive, so we have to execute an external
+       # command in order to kill the process.
+       verbose "doing kill, pid is $pid"
+       # Prepend "-" to generate the "process group ID" needed by
+       # kill.
+       set pgid "-$pid"

I probably did that change just assuming pid is a number, given
the pid > 0 check.

So if you replace:

 + set pgid "-$pid"

with:

 - set pgid "-[join $pid { -}]"

I imagine it would get things back to how they were for you?

Thanks,
Pedro Alves
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.