<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 7, 2016, at 10:52 AM, Viacheslav Nikolaev <<a href="mailto:viacheslav.nikolaev@gmail.com" class="">viacheslav.nikolaev@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Two threads may both pass this condition:</div><div class=""> if (Size > (size_t)(OutBufEnd - OutBufCur))</div><div class=""> return write(Str.data(), Size);</div><div class=""><br class=""></div><div class="">Then they both appear at this point.</div><div class="">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></div></blockquote><div><br class=""></div><div>I mentioned in my original email that I don’t believe this can happen for unbuffered stream, they will always call write.</div><div><br class=""></div><div>— </div><div>Mehdi</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""> if (Size) {</div><div class=""> memcpy(OutBufCur, Str.data(), Size);1</div><div class=""> OutBufCur += Size;</div><div class=""> }</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Dec 7, 2016 at 9:47 PM, Mehdi Amini <span dir="ltr" class=""><<a href="mailto:mehdi.amini@apple.com" target="_blank" class="">mehdi.amini@apple.com</a>></span> wrote:<br class=""><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" class=""><br class=""><div class=""><span class="gmail-"><blockquote type="cite" class=""><div class="">On Dec 7, 2016, at 10:27 AM, Viacheslav Nikolaev <<a href="mailto:viacheslav.nikolaev@gmail.com" target="_blank" class="">viacheslav.nikolaev@gmail.com</a><wbr class="">> wrote:</div><br class="gmail-m_4427020782046183870Apple-interchange-newline"><div class=""><div dir="ltr" class=""><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 class=""></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 class=""><br class=""></div></span><div class="">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 class=""><br class=""></div>— </div><span class="gmail-HOEnZb"><font color="#888888" class=""><div class="">Mehdi</div></font></span><div class=""><div class="gmail-h5"><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><br class=""></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 class=""></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 class=""></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 class=""><div class="gmail_quote">On Wed, Dec 7, 2016 at 9:12 PM, Rui Ueyama <span dir="ltr" class=""><<a href="mailto:ruiu@google.com" target="_blank" class="">ruiu@google.com</a>></span> wrote:<br class=""><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" class=""><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" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""><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=""><br class="">
> On Dec 7, 2016, at 1:52 AM, Viacheslav Nikolaev via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class="">
><br class="">
> This code from raw_ostream.h is really racy:<br class="">
><br class="">
> raw_ostream &operator<<(StringRef Str) {<br class="">
> // Inline fast path, particularly for strings with a known length.<br class="">
> size_t Size = Str.size();<br class="">
><br class="">
> // Make sure we can use the fast path.<br class="">
> if (Size > (size_t)(OutBufEnd - OutBufCur))<br class="">
> return write(Str.data(), Size);<br class="">
><br class="">
> if (Size) {<br class="">
> memcpy(OutBufCur, Str.data(), Size);<br class="">
> OutBufCur += Size;<br class="">
> }<br class="">
> return *this;<br class="">
> }<br class="">
<br class="">
</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 class=""><br class=""></div></span><div class="">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=""><br class=""></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 class=""><br class="">
<br class="">
> Of course, one might wonder why someone would need to output to a stream from multiple threads at the same time.<br class="">
><br class="">
> But imagine someone might get logs to dbgs() or errs() running the backend for a target in multiple threads.<br class="">
<br class="">
</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 class="">
<br class="">
—<br class="">
Mehdi<br class="">
<br class=""></span>
______________________________<wbr class="">_________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class="">
</blockquote></div><br class=""></div></div>
</blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></body></html>