What are the possible ways to debug deadlocking threads in a MT program, other than gdb?
除了gdb之外,在MT程序中调试死锁线程的可能方法有哪些?
4 个解决方案
#1
#2
If you're using POSIX, try investigating PTHREAD_MUTEX_ERRORCHECK.
如果您正在使用POSIX,请尝试调查PTHREAD_MUTEX_ERRORCHECK。
#3
I've always invested some time into writing or grafting on a flexible logging facility into projects I've worked on, and it always paid off handsomely in turning difficult bugs into easy ones. At the very least, wrapping locking primitives in functions or methods that log before and after logging, and display the object being locked and the thread that's doing the locking always helped me to zero in on the offending thread in a matter of minutes - assuming that the problem can be reproduced at all, of course.
我总是花一些时间在灵活的测井设备上编写或嫁接到我所参与的项目中,并且总是在将困难的错误变成简单的错误方面获得丰厚回报。至少,在记录之前和之后记录的函数或方法中包装锁定原语,并显示被锁定的对象以及正在执行锁定的线程总是帮助我在几分钟内对违规线程进行归零 - 假设当然,问题可以复制。
Loading the program under a debugger is actually a pretty limited method of determining what happened once a process deadlocks, since all it can give you is a snapshot of how badly you messed up, rather than a step by step explanation of how you screwed up, which I find a lot more helpful.
在调试器下加载程序实际上是一个非常有限的方法来确定一旦进程死锁时发生了什么,因为它可以给你的快照是你搞砸了多少,而不是一步一步解释你如何搞砸了,我发现它更有帮助。
#4
Or get the Intel Thread Checker. Fine work.
或者获取英特尔线程检查器。干得好。
#1
On some platforms deadlock detection tools may help you find already observed and not yet observed deadlocks, as well as other bugs.
在某些平台上,死锁检测工具可以帮助您找到已经观察到的和尚未观察到的死锁以及其他错误。
On Solaris, try LockLint.
On Linux, try Helgrind or DRD.
在Solaris上,尝试LockLint。在Linux上,尝试Helgrind或DRD。
#2
If you're using POSIX, try investigating PTHREAD_MUTEX_ERRORCHECK.
如果您正在使用POSIX,请尝试调查PTHREAD_MUTEX_ERRORCHECK。
#3
I've always invested some time into writing or grafting on a flexible logging facility into projects I've worked on, and it always paid off handsomely in turning difficult bugs into easy ones. At the very least, wrapping locking primitives in functions or methods that log before and after logging, and display the object being locked and the thread that's doing the locking always helped me to zero in on the offending thread in a matter of minutes - assuming that the problem can be reproduced at all, of course.
我总是花一些时间在灵活的测井设备上编写或嫁接到我所参与的项目中,并且总是在将困难的错误变成简单的错误方面获得丰厚回报。至少,在记录之前和之后记录的函数或方法中包装锁定原语,并显示被锁定的对象以及正在执行锁定的线程总是帮助我在几分钟内对违规线程进行归零 - 假设当然,问题可以复制。
Loading the program under a debugger is actually a pretty limited method of determining what happened once a process deadlocks, since all it can give you is a snapshot of how badly you messed up, rather than a step by step explanation of how you screwed up, which I find a lot more helpful.
在调试器下加载程序实际上是一个非常有限的方法来确定一旦进程死锁时发生了什么,因为它可以给你的快照是你搞砸了多少,而不是一步一步解释你如何搞砸了,我发现它更有帮助。
#4
Or get the Intel Thread Checker. Fine work.
或者获取英特尔线程检查器。干得好。