quilt-dev
[Top][All Lists]
Advanced

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

Re: [Quilt-dev] Race in test suite (faildiff.test)


From: Jean Delvare
Subject: Re: [Quilt-dev] Race in test suite (faildiff.test)
Date: Mon, 29 Jan 2018 13:18:48 +0100

On Mon, 29 Jan 2018 09:18:18 +0100, Jean Delvare wrote:
> On Fri, 26 Jan 2018 04:22:09 +0100, Martin Quinson wrote:
> > But I still don't get why 2>&1 does not helps here.  
> 
> I see only 2 pipes created between the client and the server in the run
> script, one in each direction. It's the client which duplicates one
> pipe end to connect it to stderr. Everything from the client back to
> the server goes through a single pipe already, so I suspect it's as
> if 2>&1 was already passed to all commands.
> 
> Anyway, even with 2>&1, stderr and stdout are probably still distinct
> file descriptors each with its own pipe buffer, so it does not help?
> 
> > I cannot fully
> > understand the details of the perl code either, but it seems to me
> > like there is too much pipes going on in the exec_test() function.   
> 
> I remember looking at that code before and not understanding its
> complexity either. At the time I concluded I was not smart enough.

This morning I tried to reproduce the bug outside of the test suite. I
stopped the test at the command which sometimes fails, and from there
continued interactively in a terminal. The command was running in a
loop, printing the output in the terminal as it would happen with a
real user. After 3000 iterations I saved the terminal contents to a
text file for analysis. The result is that the unexpected order DOES
also happen when run interactively. So no matter what we think about
the complexity of the perl "run" script, it is not the cause of the
problem.

My next suspect is the following pipe in diff_file():

>       diff $QUILT_DIFF_OPTS \
>            --label "$old_hdr$old_date" --label "$new_hdr$new_date" \
>            "$old_file" "$new_file" \
>       | if read line                          <--- HERE
>       then

I guess that any pipe opened breaks the assumption of interactivity and
the buffer of the pipe could slowdown the output. But I don't know how
to prove that. Anyone has an idea how to write this part differently
(even if only for the purpose of testing) without a pipe?

-- 
Jean Delvare
SUSE L3 Support



reply via email to

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