https://issues.dlang.org/show_bug.cgi?id=15768
Issue ID: 15768 Summary: std.stdio.trustedStdout accesses __gshared data without synchronization. Product: D Version: D2 Hardware: All URL: http://forum.dlang.org/post/vrchiulmsqxtdeadrrjo@forum .dlang.org OS: All Status: NEW Severity: major Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: marco.le...@gmx.de std.stdio.trustedStdout returns a copy of stdout which invokes the postblit of File. This is done without internal synchronization and so the reference count increment/decrement is prone to race conditions if stdout has been assigned an ordinary file. The following snippet is thus likely to close stdout too early, resulting - for example - in segmentation faults inside Glibc: stdout = File("/dev/null", "w"); foreach(t; 1000.iota.parallel) writeln("Oops"); When Phobos is compiled with assertions, the bug is generally caught within the File struct itself. The compiler did warn that accessing the global data `stdout` would be unsafe (because of potential race conditions). A wrapper `trustedStdout` was written to make stdout usable in @safe code, but it bears no warning as to threading issues. Compare to: https://issues.dlang.org/show_bug.cgi?id=15645 where @trusted was added to silence legitimate compiler warnings about safety, resulting in a Phobos bug. Ultimately I believe that stdout must be a shared resource with a shared postblit and dtor that decrements the ref count in an atomic way or stdout must not be reassignable at all. See also: The situation with thread-safety of std.logger's global stdlog. --