C++ 调试boost:：线程应用程序，高误报率

我已经编写了一个boost:：thread应用程序，其中可能有一些竞争条件。我想调试这个程序。因此，我使用了以下valgrind工具：

哈尔格兰德

drd

不幸的是，他们的假阳性率很高。因此，对于下面这个非常简单的程序，

valgrind--tool=drd

会抱怨94个错误，这是不应该的。因此，通过我的复杂程序，我得到大约15000个错误。所以很难找到实际的误差

我可以用下面的boost库1.46.0和1.47.0重现这种行为。以及valgrind 3.7.0 SVN和valgrind 3.8.0 SVN。我在Ubuntu11.10和MacOSX10.7上试用过的操作系统。编译器，其中包含gcc 4.2.1和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;
}
;

从

数据竞争检测器之前发生的一个重要优点是，这些检测器不会报告任何误报。 DRD是基于发生之前算法的

因此，如果实现只使用POSIX线程，而不是像Linux的futex那样使用非POSIX线程，DRD不会有任何误报

因此，如果DRD报告一个假阳性，在一个像你这样的无种族项目上，它有一个bug。它不应该有假阳性

---

但是，我无法在我的机器上重现您报告的错误（Archlinux/gcc 4.6.2/valgrind 3.6.1/boost 1.47）。

gdb的问题是我的应用程序很少崩溃。因此，用gdb很难捕捉到崩溃的程序。事实上，不规则的崩溃非常令人沮丧，也很难调试。使用kdbg，一个GUI调试器，也许通过这种方式更容易发现错误。问题是错误很可能是一种竞争条件。用gdb或kdbg检测竞争条件是非常困难的。因为它通常不会崩溃，工作正常。可以使用信号灯来防止这种情况。当然，这使得程序依赖于操作系统：）我有一个互斥锁，用于所有需要从多个线程访问的变量。所以它应该是线程安全的。但我似乎忽略了一些事情。我查看了我的代码好几次，都没有弄清楚是什么，因此我需要一个调试器来找出我的竞争条件。你自己编译过boost和valgrind吗？@tune2fs No。ArchLinux正在发布。这意味着它拥有所有东西的最新稳定版本。使用Ubuntu 10.04、valgrind 3.6.0和gcc 4.4.3再次检查，没有错误。您确定没有为valgrind使用-v选项吗？因为我使用了valgrind 3.6.1，所以不再有错误。在SVN最近的valgrind版本构建中，它有以下错误。

==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)