<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - TSan data races with freed_pool_t's |top| data member" href="https://bugs.freedesktop.org/show_bug.cgi?id=90318#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - TSan data races with freed_pool_t's |top| data member" href="https://bugs.freedesktop.org/show_bug.cgi?id=90318">bug 90318</a> from <a class="email" href="mailto:dvyukov@google.com" title="Dmitry Vyukov <dvyukov@google.com>"> Dmitry Vyukov</a> <pre>A data race cannot be intentional (unless you intention is to spread exploits in software). The C standard is pretty clear that any data race results in undefined behavior of the program. Even a read or a write of an int variable can corrupt memory and crash the program. See the following for some examples: <a href="https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong">https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong</a> <a href="http://hboehm.info/boehm-hotpar11.pdf">http://hboehm.info/boehm-hotpar11.pdf</a> In this case a very real possibility is overflow/underflow of the index. E.g. compiler can compile update of top in increment in _freed_pool_put, then you can easily get overflow and corrupt memory. Or compiler can re-read top after the if (i < 0) check, then you get underflow and corrupt memory again. There is already _cairo_atomic_int_get. Please add _cairo_atomic_int_set and use these for top manipulation.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>