【发布时间】:2018-07-18 14:19:14
【问题描述】:
因此,当遇到死锁、互斥、锁反转等问题时,在 OSX 上,spindump 工具非常有用。它只是转储所有系统(用户态和内核)上的线程堆栈,并且对于哪些线程被阻塞是相当可见的。
现在使用 Devstudio 在第二个 VM 上进行内核调试,我遇到了死锁。我看到我可以使用“!process 0 0”来转储所有进程。而且我相信我可以切换到一个进程,并转储线程(?),然后选择一个带有“!thread”和“k”的线程来查看堆栈。但是实际上有数千个线程,肯定有一种方法可以在不手动执行的情况下将它们全部转储吗?
"!process 0 7" 运行了大约 40 分钟,并且设置的堆栈中没有我的函数。
spindump 输出看起来像
Thread 0x8ab 1000 samples (1-1000) priority 81 (base 81)
*1000 call_continuation + 23 (kernel.development + 1927415)
*1000 arc_reclaim_thread + 2391 (arc.c:5095,11 in zfs + 131367)
*1000 cv_timedwait_hires + 206 (spl-condvar.c:172,14 in spl + 8125)
*1000 msleep + 98 (kernel.development + 7434066)
*1000 _sleep + 219 (kernel.development + 7432603)
*1000 lck_mtx_sleep_deadline + 147 (kernel.development + 2362339)
*1000 thread_block_reason + 286 (kernel.development + 2407438)
所以没有什么神奇的,只是它遍历所有线程。
【问题讨论】:
-
"!process 0 0" 并找到系统进程地址,然后 "!process 0xdeadbeef 7" 似乎至少列出了内核中的线程以及堆栈中的函数。不过在我的虚拟机上需要将近 12 分钟。
-
你想解决什么问题?在我看来,您似乎知道存在死锁,但您不知道它是在内核中还是在用户模式中,并且您不知道哪个应用程序受到影响。在我看来,您似乎想要一个通用的解决所有问题的死锁工具。如果您发现 Microsoft Office 与 Adobe Reader 陷入僵局,您会怎么做?那么下一步是什么?
-
我知道有一个死锁,因为等待新 vnode 的线程永远等待,所以我需要查看堆栈以了解谁拥有该互斥锁,以便我可以找出它没有返回的原因。是的,这些堆栈中的大多数都在内核中,但有些可以是用户态(调用内核的命令行工具)。是的,自旋锁非常接近通用死锁工具,但就我而言,我正在研究文件系统驱动程序。
标签: windows visual-studio kernel windbg