我有一个并发程序，当我正常运行时，一切正常。但是，当使用valgrind时，我遇到（可能是死锁）问题，很可能是因为valgrind导致程序运行得慢得多。我尝试使用gdb调试程序，但我再也无法重现错误。我想知道是否有某种方法可以使gdb运行得更慢，以便我可以重现并找到错误。该程序在远程服务器上运行。
程序庞大且并发性很强，因此纯代码分析在这一点上并不现实。
答案 0 :(得分：4)
使用valgrind时，我遇到（可能是死锁）问题，
有一种方法可以在valgrind下运行程序时分析问题。使用gdbserver中的valgrind功能来分析此死锁。在valgrind下运行程序，获得死锁，然后附上gdb并调查您的死锁。这是来自valgrind doc：
在Valgrind下运行的程序不是由CPU直接执行的。 相反，它运行在Valgrind提供的合成CPU上。这就是为什么一个 调试器在Valgrind上运行时无法调试程序。
本节介绍GDB如何与Valgrind进行交互 gdbserver在Valgrind下提供完全可调试的程序。
所以你需要以这种方式在valgrind下运行你的程序：
valgrind --vgdb=yes --vgdb-error=0 prog
一旦遇到死锁，请按照此处的说明在gdb下附加：http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver。
我认为如果确实存在死锁，那么你需要在gdb中运行thread apply all backtrace。
答案 1 :(得分：3)
您可以尝试使用helgrind valgrind plugin。它是一个线程错误检测器，可以帮助您发现不一致的锁定顺序（死锁源）。
另一种方法是将sleep调用放在关键部分的源代码中。但它有点脏。
答案 2 :(得分：0)
另一种同时运行gdb和valgrind的方法，由valgrind在启动时建议，尽管我最初没有注意到它：
==16218== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==16218== /path/to/gdb ./ha3_qdqx.exe
==16218== and then give GDB the following command
==16218== target remote | /path/to/valgrind/bin/vgdb --pid=16218
==16218== --pid is optional if only one valgrind process is running