|
From: Bart V. A. <bar...@gm...> - 2009-02-06 19:29:48
|
On Mon, Jan 26, 2009 at 4:45 PM, Konstantin Serebryany <kon...@gm...> wrote: > Did you ever think that two data race detectors (Helgrind and Drd) is > too much for the Valgrind project? > In fact, I think that two is too few. :) > > Please welcome ThreadSanitizer, yet another data race detector based > on Valgrind. > http://code.google.com/p/data-race-test/wiki/ThreadSanitizer > > I'd appreciate your feedback, Hello Konstantin, I had a quick look at the command line options supported by ThreadSanitizer, and found this: --ignore-in-dtor=yes|no, default yes, Ignore reports with a C++ class Destructor in stack trace. Can you explain why this option defaults to yes, and why it even exists ? Any race I have seen in C++ destructors until now indicated a real problem. A very common cause for data races triggered inside a C++ destructor is the following: - A class has been defined that wraps thread creation and destruction, e.g. CThread. - One of the methods in that class is declared virtual and is run inside the created thread, e.g. CThread::Run(). - There exists methods for starting the thread and waiting until the thread stopped, e.g. CThread::StartRunning() and CThread::WaitUntilStopped(). This last method notifies CThread::Run() that it should stop and then waits until that thread stopped, e.g. via pthread_join(). - Calling CThread::WaitUntilStopped() from the CThread destructor will trigger a race condition on the vtbl pointer of class CThread. This is a real bug and a bug that can cause severe trouble, not something that should be hidden. Bart. |