<div dir="ltr"><div>Two threads may both pass this condition:</div><div> if (Size > (size_t)(OutBufEnd - OutBufCur))</div><div> return write(Str.data(), Size);</div><div><br></div><div>Then they both appear at this point.</div><div>But one of them might update OutBufCur in such a way that the subsequent memcpy of the other one will overrun the buffer.</div><div> if (Size) {</div><div> memcpy(OutBufCur, Str.data(), Size);</div><div> OutBufCur += Size;</div><div> }</div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 7, 2016 at 9:47 PM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class="gmail-"><blockquote type="cite"><div>On Dec 7, 2016, at 10:27 AM, Viacheslav Nikolaev <<a href="mailto:viacheslav.nikolaev@gmail.com" target="_blank">viacheslav.nikolaev@gmail.com</a><wbr>> wrote:</div><br class="gmail-m_4427020782046183870Apple-interchange-newline"><div><div dir="ltr"><div class="gmail_extra">> I believe it’ll always forward directly to raw_fd_ostream::write_impl(), which is calling the libc ::write().</div><div class="gmail_extra"><br></div><div class="gmail_extra">Do you mean raw_fd_ostream somehow overrides the operator<< the code for which I extracted?</div><div class="gmail_extra">I cannot see if that is so. And I really saw it didn't albeit in a very old master.</div></div></div></blockquote><div><br></div></span><div>No, I meant I didn’t see the race in the code you showed for the operator<<(). It is very possible I missed something, but you’ll need to help me figuring out where the race is.</div><div><br></div>— </div><span class="gmail-HOEnZb"><font color="#888888"><div>Mehdi</div></font></span><div><div class="gmail-h5"><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">> I agree. Acquiring a lock on each write to a buffered raw_ostream is too expensive. You can always explicitly use std::mutex if you have shared raw_ostreams.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Of course you can do it in your code. But there's a lot of "dbgs() <<" in the backends.</div><div class="gmail_extra">And e.g. if you want to have multithread invocation of a debug version of the lib, but without changing the backend... you might get the race condition.</div><div class="gmail_extra"><br></div><div class="gmail_extra">That's why I'm asking if there's a good way to avoid a problem like that.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 7, 2016 at 9:12 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-m_4427020782046183870gmail-">On Wed, Dec 7, 2016 at 10:02 AM, Mehdi Amini via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span><br>
> On Dec 7, 2016, at 1:52 AM, Viacheslav Nikolaev via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> This code from raw_ostream.h is really racy:<br>
><br>
> raw_ostream &operator<<(StringRef Str) {<br>
> // Inline fast path, particularly for strings with a known length.<br>
> size_t Size = Str.size();<br>
><br>
> // Make sure we can use the fast path.<br>
> if (Size > (size_t)(OutBufEnd - OutBufCur))<br>
> return write(Str.data(), Size);<br>
><br>
> if (Size) {<br>
> memcpy(OutBufCur, Str.data(), Size);<br>
> OutBufCur += Size;<br>
> }<br>
> return *this;<br>
> }<br>
<br>
</span>I don’t believe "the is racy” is an appropriate qualification, “buffered raw_ostream are not providing a thread-safe API" seems more accurate to me.</blockquote><div><br></div></span><div>I agree. Acquiring a lock on each write to a buffered raw_ostream is too expensive. You can always explicitly use std::mutex if you have shared raw_ostreams.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-m_4427020782046183870gmail-"><span><br>
<br>
> Of course, one might wonder why someone would need to output to a stream from multiple threads at the same time.<br>
><br>
> But imagine someone might get logs to dbgs() or errs() running the backend for a target in multiple threads.<br>
<br>
</span>These are unbuffered, I wouldn’t expect a race in the code you list above. I believe it’ll always forward directly to raw_fd_ostream::write_impl(), which is calling the libc ::write().<br>
<br>
—<br>
Mehdi<br>
<br></span>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br></div></div>
</blockquote></div><br></div></div>
</div></blockquote></div><br></div></div></div></blockquote></div><br></div></div>