[thread] Testing with Sanitisers (ASAN, TSAN, MSAN)
I'm going to be bringing up some more testers, and I wondered if the results are meaningful, or can be made meaningful. The tester is "BenPope x86_64 Ubuntu", first available results are for TSAN, and it shows some failures. I'm under the impression that some of the sanitisers may need to be taught about certain constructs in order to be effective (e.g. boost::detail::atomic_increment: http://www.boost.org/development/tests/develop/developer/output/BenPope%20x8...) Other failures look legitimate at first glance (e.g. Cycle in lock order graph: http://www.boost.org/development/tests/develop/developer/output/BenPope%20x8...) I shall endeavour to get nicer stack traces, I think I need to tell it about llvm-symbolizer, althouh I haven't always had success in the past, any advice or suggestions are welcome. Ben
Le 09/03/15 15:16, Ben Pope a écrit :
I'm going to be bringing up some more testers, and I wondered if the results are meaningful, or can be made meaningful.
The tester is "BenPope x86_64 Ubuntu", first available results are for TSAN, and it shows some failures.
I'm under the impression that some of the sanitisers may need to be taught about certain constructs in order to be effective (e.g. boost::detail::atomic_increment: http://www.boost.org/development/tests/develop/developer/output/BenPope%20x8...)
Other failures look legitimate at first glance (e.g. Cycle in lock order graph: http://www.boost.org/development/tests/develop/developer/output/BenPope%20x8...)
Thanks for this report.
I shall endeavour to get nicer stack traces, I think I need to tell it about llvm-symbolizer, althouh I haven't always had success in the past, any advice or suggestions are welcome.
yes, this will be even better. Vicente
On 9 Mar 2015 at 23:16, Vicente J. Botet Escriba wrote:
I'm under the impression that some of the sanitisers may need to be taught about certain constructs in order to be effective (e.g. boost::detail::atomic_increment: http://www.boost.org/development/tests/develop/developer/output/BenPope%20x8...)
Other failures look legitimate at first glance (e.g. Cycle in lock order graph: http://www.boost.org/development/tests/develop/developer/output/BenPope%20x8...)
Thanks for this report.
I shall endeavour to get nicer stack traces, I think I need to tell it about llvm-symbolizer, althouh I haven't always had success in the past, any advice or suggestions are welcome.
yes, this will be even better.
AFIO uses the following tsan suppressions for libstdc++ and Boost: # Stuff from libstdc++ not understood by tsan race:include/c++/*/bits/shared_ptr_base.h race:std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_add_ref_loc k() race:std::string::_Rep::_M_refdata() # Stuff from Boost not understood by tsan race:boost/exception/detail/exception_ptr.hpp race:boost/exception/exception.hpp race:void std::swap<boost::exception_detail::clone_base const*> race:boost/smart_ptr/detail/shared_count.hpp race:boost::detail::shared_count::swap(boost::detail::shared_count&) race:boost::detail::shared_count::~shared_count() I don't remember seeing anything actually originating from Boost.Thread itself, in so far as AFIO makes use of Boost.Thread. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Le 09/03/15 23:16, Vicente J. Botet Escriba a écrit :
Le 09/03/15 15:16, Ben Pope a écrit :
Other failures look legitimate at first glance (e.g. Cycle in lock order graph: http://www.boost.org/development/tests/develop/developer/output/BenPope%20x8...)
Thanks for this report. Fixed. https://svn.boost.org/trac/boost/ticket/11090
I have created some tickets to track some of the multiple reports. Thanks again to setup this testers. I have a question. There is a "ThreadSanitizer: thread leak" on a program that must finish calling std::terminate and don't join a thread. I think that this can be considered a false positive. Best, Vicente
On Friday, March 13, 2015 05:12 AM, Vicente J. Botet Escriba wrote:
Le 09/03/15 23:16, Vicente J. Botet Escriba a écrit :
Le 09/03/15 15:16, Ben Pope a écrit :
Other failures look legitimate at first glance (e.g. Cycle in lock order graph: http://www.boost.org/development/tests/develop/developer/output/BenPope%20x8...)
Thanks for this report. Fixed. https://svn.boost.org/trac/boost/ticket/11090
I have created some tickets to track some of the multiple reports. Thanks again to setup this testers.
You're welcome.
I have a question. There is a "ThreadSanitizer: thread leak" on a program that must finish calling std::terminate and don't join a thread. I think that this can be considered a false positive.
Which test? I'll ask over on the clang newsgroup. Ben
Le 13/03/15 03:48, Ben Pope a écrit :
On Friday, March 13, 2015 05:12 AM, Vicente J. Botet Escriba wrote:
I have a question. There is a "ThreadSanitizer: thread leak" on a program that must finish calling std::terminate and don't join a thread. I think that this can be considered a false positive.
Which test? I'll ask over on the clang newsgroup.
It added a ticket for it from the https://svn.boost.org/trac/boost/ticket/11098 Vicente
Le 13/03/15 07:49, Vicente J. Botet Escriba a écrit : Other report this issue WARNING: ThreadSanitizer: data race (pid=4677) ... Location is global 'std::__1::cout' of size 160 at 0x7f6d813c1b40 (libc++.so.1+0x0000002b8bd8) See the full report here [1]. The test is using std::cout in a multi-threaded env. Is this telling that the standard library has a data race? Best, Vicente [1] http://www.boost.org/development/tests/develop/developer/output/BenPope%20x8...
On Friday, March 13, 2015 02:54 PM, Vicente J. Botet Escriba wrote:
Le 13/03/15 07:49, Vicente J. Botet Escriba a écrit :
Other report this issue
WARNING: ThreadSanitizer: data race (pid=4677) ....
Location is global 'std::__1::cout' of size 160 at 0x7f6d813c1b40 (libc++.so.1+0x0000002b8bd8)
See the full report here [1].
The test is using std::cout in a multi-threaded env.
Is this telling that the standard library has a data race?
std::cout isn't thread safe, is it? And boost test isn't thread safe either. I think it means you have to dispatch the BOOST_CHECK on the main thread. Ben
On Friday, March 13, 2015 04:01 PM, Ben Pope wrote:
On Friday, March 13, 2015 02:54 PM, Vicente J. Botet Escriba wrote:
Le 13/03/15 07:49, Vicente J. Botet Escriba a écrit :
Other report this issue
WARNING: ThreadSanitizer: data race (pid=4677) ....
Location is global 'std::__1::cout' of size 160 at 0x7f6d813c1b40 (libc++.so.1+0x0000002b8bd8)
See the full report here [1].
The test is using std::cout in a multi-threaded env.
Is this telling that the standard library has a data race?
std::cout isn't thread safe, is it?
Oh, I just checked... There shouldn't be a race, but the output may be garbled, which messes up the boost test log files (so you need to serialise access to BOOST_CHECK anyway). I'm not currently linking the executables to a sanitised version of libc++, I'm not sure if that affects the reporting of the results, but I'll reduce it and confirm with clang dev list. Ben
participants (3)
-
Ben Pope -
Niall Douglas -
Vicente J. Botet Escriba