Re: [Qemu-devel] [PULL v4 00/35] Misc patches for 2018-12-21

[Paolo Bonzini]

On 04/01/19 11:06, Peter Maydell wrote:
> On Fri, 4 Jan 2019 at 07:59, Paolo Bonzini <address@hidden> wrote:
>>
>> On 03/01/19 19:37, Peter Maydell wrote:
>>> On Sat, 22 Dec 2018 at 08:41, Paolo Bonzini <address@hidden> 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.