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 LeichterStefan.Leichter@camline.com 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.
bye michael