relay log problem

Michael Stefaniuc mstefani at
Fri Jan 29 04:24:00 CST 2010

Ken Thomases wrote:
> On Jan 28, 2010, at 5:21 PM, Michael Stefaniuc wrote:
>> On 01/28/2010 10:59 PM, Henri Verbeet wrote:
>>> On 28 January 2010 22:39, Stefan Leichter<Stefan.Leichter at>  wrote:
>>>> Is this a know problem? Is a work around available?
>>> Yeah, that's a known problem. As a workaround you can use ">>"
>>> (append) instead of ">" to redirect to the file. You'll still need the
>>> "2>&1" to redirect stderr to stdout, of course.
>> That won't workaround the problem. The problem is that there are
>> multiple threads/programs that write at the same time to
>> stdout/stderr.  I have seen it with fixme/err/warn messages too; even
>> with crash dumps.
> Using >> in the shell causes the stdout file descriptor to be opened
> with O_APPEND.  Using 2>&1 makes stderr dup the file descriptor, so it
> gets the same flag.
> With O_APPEND, the kernel ensures that all writes append to the file.
> Multiple threads or programs using an O_APPEND descriptor can't
> overwrite each other.  If the code uses multiple writes for a single
> line, then those multiple writes can be interleaved, but can't
> overwrite.
Right, Henri and I talked about that on irc. The "overwrite" corruption
is fixed by using ">>". So yes, when writting to a log file redirecting
with ">>" is better.

> And, for the most part, Wine's debug logging uses single
> writes so it won't even interleave.
Incorrect. Wine doesn't use write(2) but vfprintf(3) which operates on
FILE handles; the output is buffered aka a vfprintf call won't translate
1:1 to a write(2) system call. But even if it would directly use
write(2), that system call isn't atomic. A lot of people consider a
write smaller/equal the PAGE_SIZE to be atomic but it isn't; one can get
a short write because of an EINTR.

The ">>" redirection fixes the overwriting corruption but not the
interleaving one. With multiple threads and enough debug output the
chances are high to get a few interleaving corruption; i see it
regularly in the output of winetest.exe runs.


More information about the wine-devel mailing list