On 04/01/19 11:06, Peter Maydell wrote:
> On Fri, 4 Jan 2019 at 07:59, Paolo Bonzini <pbonz...@redhat.com> wrote:
>>
>> On 03/01/19 19:37, Peter Maydell wrote:
>>> On Sat, 22 Dec 2018 at 08:41, Paolo Bonzini <pbonz...@redhat.com> wrote:
>>> Interestingly, I have today run into "make: write error: stdout"
>>> with the existing make check infrastructure. [...]
>>> I presume that something in one of the tests we're running,
>>> likely QEMU itself, ends up setting stdout to non-blocking.
>>> This while rune *used* to be entirely reliable, so maybe
>>> something recent has changed ?
>>
>> I don't know... I tried running make check under "strace -e fcntl" and I
>> didn't find any occurrences of fcntl(1, O_SETFL, ...|O_NONBLOCK).
>> Perhaps you can add a check after every invocation of a test executable.
>
>> Are you going to apply the pull request since the bug is preexisting?
>
> The pull request takes the problem from "occasionally shows up
> in by-hand running of make check in a while loop" to "reliably
> causes my automated tests to fail every time". I can't apply
> a pullreq that does that, so we need to find at least a workaround.
The certain workaround is to clear O_NONBLOCK before invoking make,
possibly by placing a wrapper in ~/bin:
import os
from fcntl import *
fcntl(1, F_SETFL, fcntl(1, F_GETFL) & ~os.O_NONBLOCK)
If you're using --output-sync, *not* using it might work, but not if the
write error occurs when writing the command (as opposed to the output).
For what it's worth, I think the latest version of Make is still
susceptible when using --output-sync. The loop that flushes the
temporary buffer to stdout or stderr is as follows:
while (1)
{
int len;
EINTRLOOP (len, read (from, buffer, sizeof (buffer)));
if (len < 0)
perror ("read()");
if (len <= 0)
break;
if (fwrite (buffer, len, 1, to) < 1)
{
perror ("fwrite()");
break;
}
fflush (to);
}
Maybe it's one of the dependencies of QEMU that is causing it.
Paolo
> I'm not sure why your test harness makes it much more likely
> that the problem manifests.
