So long as helgrind has wrapped all your locking primitives (e.g. implements in terms of pthreads) then the Eraser algorithm it uses is very reliable and doesn't give false positives.
Although we have seen at least one such case where this happens -- std::atomic is not implemented in terms of locking primitives that helgrind understands. But std::atomic is the only case I'm aware of where Helgrind should give false positives. Unfortunately, Helgrind was suggested so late in Mir's development that the code base was already full of a large number of races which will be very difficult to get on top of. And while we're not on top of it we can't automate it yet either. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to boost1.53 in Ubuntu. https://bugs.launchpad.net/bugs/1243564 Title: helgrind: dubious: associated lock is not held by any thread: void boost::asio::detail::posix_event::signal_and_unlock<boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex> >(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&) (posix_event.hpp:62) To manage notifications about this bug go to: https://bugs.launchpad.net/mir/+bug/1243564/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs