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/