[atomic] ThreadSanitizer reports a data race when using the code from "reference counting" example
Hi Boosters! I'd like to draw your attention to an issue with Boost.Atomic that I encountered when using ThreadSanitizer. The problem is that when using the code shown in "reference counting" example [1] from the docs, the ThreadSanitizer reports a data race. Everything is described in detail in a StackOverflow thread [2] so I don't want to repeat all that here. Please help me determine whether it's a false positive, an issue in Boost.Atomic or a wrong usage of the code. Additionally, I don't understand this: Write of size 1 at 0x7d040000f7f0 by thread T2: #0 operator delete(void*) <null>:0 (a.out+0x00000004738b) What kind of write does ThreadSanitizer might refer to? WBR, Adam Romanek [1] http://www.boost.org/doc/libs/1_55_0/doc/html/atomic/usage_examples.html#boo... [2] http://stackoverflow.com/questions/24446561/threadsanitizer-reports-data-rac...
On 29 Jun 2014 at 21:16, Adam Romanek wrote:
I'd like to draw your attention to an issue with Boost.Atomic that I encountered when using ThreadSanitizer. The problem is that when using the code shown in "reference counting" example [1] from the docs, the ThreadSanitizer reports a data race. Everything is described in detail in a StackOverflow thread [2] so I don't want to repeat all that here.
Please help me determine whether it's a false positive, an issue in Boost.Atomic or a wrong usage of the code.
I'd try replacing boost::atomic with std::atomic and see if the same thing happens. Oh, and use a recent libstdc++. If it's only happening in Boost, report it as a bug.
Additionally, I don't understand this:
Write of size 1 at 0x7d040000f7f0 by thread T2: #0 operator delete(void*) <null>:0 (a.out+0x00000004738b)
What kind of write does ThreadSanitizer might refer to?
ThreadSanitiser tracks bounds of change, so if only one byte of change overlaps the raced bounds then it'll get reported as one byte. tl;dr I wouldn't worry about it. ThreadSanitiser has many weirdness due to its design and straight out bugs. I am currently awaiting clang 3.5 release because 3.4 won't fully backtrace when libstdc++'s reference counted std::string has false positived a race, and I have dozens of workaround suppressions for it. Roll on libstdc++ 4.10 and its new std::string implementation!!! Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 30.06.2014 19:07, Niall Douglas wrote:
On 29 Jun 2014 at 21:16, Adam Romanek wrote:
I'd like to draw your attention to an issue with Boost.Atomic that I encountered when using ThreadSanitizer. The problem is that when using the code shown in "reference counting" example [1] from the docs, the ThreadSanitizer reports a data race. Everything is described in detail in a StackOverflow thread [2] so I don't want to repeat all that here.
Please help me determine whether it's a false positive, an issue in Boost.Atomic or a wrong usage of the code.
I'd try replacing boost::atomic with std::atomic and see if the same thing happens. Oh, and use a recent libstdc++. If it's only happening in Boost, report it as a bug.
The same happens with std::atomic from both libstdc++ [1] and libc++ [2] (I should be using pretty recent versions of these as I'm on Ubuntu 14.04). So this is not a Boost-only issue.
Additionally, I don't understand this:
Write of size 1 at 0x7d040000f7f0 by thread T2: #0 operator delete(void*) <null>:0 (a.out+0x00000004738b)
What kind of write does ThreadSanitizer might refer to?
ThreadSanitiser tracks bounds of change, so if only one byte of change overlaps the raced bounds then it'll get reported as one byte.
tl;dr I wouldn't worry about it. ThreadSanitiser has many weirdness due to its design and straight out bugs. I am currently awaiting clang 3.5 release because 3.4 won't fully backtrace when libstdc++'s reference counted std::string has false positived a race, and I have dozens of workaround suppressions for it. Roll on libstdc++ 4.10 and its new std::string implementation!!!
Niall
I'm not that worried. I just wanted to understand this situation and determine whether I need to correct my code somehow or I should just add a new suppression. Thanks, WBR, Adam Romanek [1] http://pastebin.com/56TLxpSR [2] http://pastebin.com/STPbwbTS
On 1 Jul 2014 at 9:12, Adam Romanek wrote:
I'd try replacing boost::atomic with std::atomic and see if the same thing happens. Oh, and use a recent libstdc++. If it's only happening in Boost, report it as a bug.
The same happens with std::atomic from both libstdc++ [1] and libc++ [2] (I should be using pretty recent versions of these as I'm on Ubuntu 14.04). So this is not a Boost-only issue.
In this situation I'd report it to the clang thread sanitiser bug tracker. The chances are low that both Boost and a recent STL are simultaneously wrong. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
participants (2)
-
Adam Romanek -
Niall Douglas