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

Reply via email to