• via Digitalmars-d-bugs (38/38) Mar 05 2016 https://issues.dlang.org/show_bug.cgi?id=15768

via Digitalmars-d-bugs <digitalmars-d-bugs puremagic.com> writes:

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: nobody puremagic.com
          Reporter: Marco.Leise 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.

--