Debug boost :: thread application, high false positive rate

Question

I programmed a boost :: thread application where I may have some race conditions. I want to debug this program. Therefore, I used the following valgrind tools:

• Halgrind
• DRD

Unfortunately, they have a very false positive rate. So with a really simple program below valgrind --tool=drd complains about 94 errors where it shouldn't be. Therefore, with my complex program, I get about 15,000 errors. Therefore, it is really difficult to find the actual error.

I could reproduce this behavior with the following boost files 1.46.0 and 1.47.0. And with valgrind 3.7.0 SVN and valgrind 3.8.0 SVN. I tried operating systems where Ubuntu 11.10 and Mac OS X 10.7. A compiler in which gcc 4.2.1 and gcc 4.6.1.

 #include <iostream> #include <boost/thread.hpp> void run() { //do some stuff here } int main(int argc, char* argv[]) { boost::thread thread(run); thread.join(); std::cerr << "main: done" << std::endl; return 0; } ; 

How do you debug your streaming programs? Are there other tools that might be better suited?

Decision

Valgrind seems to be broken after version 3.6.1. If I use valgrind 3.6.1 everything works fine.

Here's the error report from valgrind --tool=drd :

 ==60767== Thread 1: ==60767== Conflicting store by thread 1 at 0x100026ec0 size 8 ==60767== at 0x2A316E: pthread_mutex_lock (in /usr/lib/system/libsystem_c.dylib) ==60767== by 0x2A82FA: _pthread_cond_wait (in /usr/lib/system/libsystem_c.dylib) ==60767== by 0x32A4E: boost::condition_variable::wait(boost::unique_lock<boost::mutex>&) (in /usr/local/lib/libboost_thread.dylib) ==60767== by 0x2BE5A: boost::thread::join() (in /usr/local/lib/libboost_thread.dylib) ==60767== by 0x10000195C: main (in ./playgroudThreads) ==60767== Address 0x100026ec0 is at offset 144 from 0x100026e30. Allocation context: ==60767== at 0xC5B3: malloc (vg_replace_malloc.c:266) ==60767== by 0x9968D: operator new(unsigned long) (in /usr/lib/libstdc++.6.0.9.dylib) ==60767== by 0x1000069ED: boost::detail::thread_data<void (*)()>* boost::detail::heap_new_impl<boost::detail::thread_data<void (*)()>, void (*&)()>(void (*&)()) (in ./playgroudThreads) ==60767== by 0x100006A87: boost::detail::thread_data<void (*)()>* boost::detail::heap_new<boost::detail::thread_data<void (*)()>, void (*)()>(void (*&)()) (in ./playgroudThreads) ==60767== by 0x100006ACA: boost::shared_ptr<boost::detail::thread_data_base> boost::thread::make_thread_info<void (*)()>(void (*)()) (in ./playgroudThreads) ==60767== by 0x100006B08: boost::thread::thread<void (*)()>(void (*)(), boost::disable_if<boost::is_convertible<void (*&)(), boost::detail::thread_move_t<void (*)()> >, boost::thread::dummy*>::type) (in ./playgroudThreads) ==60767== by 0x100001950: main (in ./playgroudThreads) ==60767== Other segment start (thread 2) ==60767== at 0x2A7B68: thread_start (in /usr/lib/system/libsystem_c.dylib) ==60767== Other segment end (thread 2) ==60767== at 0x3E667A: mach_msg_trap (in /usr/lib/system/libsystem_kernel.dylib) ==60767== by 0x3DED38: semaphore_create (in /usr/lib/system/libsystem_kernel.dylib) ==60767== by 0x2A50F7: new_sem_from_pool (in /usr/lib/system/libsystem_c.dylib) ==60767== by 0x2A6199: _pthread_exit (in /usr/lib/system/libsystem_c.dylib) ==60767== by 0x2A48C9: _pthread_start (in /usr/lib/system/libsystem_c.dylib) ==60767== by 0x2A7B74: thread_start (in /usr/lib/system/libsystem_c.dylib) 

Answer 1

From the DRD Guide

An important advantage is that they do not report any false positives over data race detectors. DRD is based on an algorithm that occurs earlier.

Thus, DRD has no false positives if the implementation uses only POSIX streams and not elements other than POSIX, such as Linux futex.

Therefore, if DRD reports a false result, in a non-racing program such as yours, it has an error. It should not have false positives.

However, I could not reproduce the errors you reported on my machine (Archlinux / gcc 4.6.2 / valgrind 3.6.1 / boost 1.47).