哪种调试工具(如果有)允许我识别持有文件锁的线程?
我正在调试一个定期引发 IOException 的测试,指出无法删除文件,因为它正在被另一个进程使用。我怀疑该进程确实是我的测试工具,并且该进程中的其他一些线程尚未按照我的预期处置其文件资源。
是否有一个工具可以用来确定哪个线程持有阻碍锁?如果我可以识别线程,那么我可以检查其调用堆栈,并至少尝试确定资源尚未释放的原因。 SOS 调试工具看起来很有前途,但我没有看到任何功能这将消除我的调查中的大量猜测。
一种想法是识别本机操作系统线程 ID,然后可以通过 SOS 将其映射到托管线程 ID。我该如何完成前者?
I'm debugging a test that periodically raises an IOException
, noting that a file can not be deleted because it is being used by another process. I suspect that the process is indeed my test harness, and that some other thread in the process hasn't disposed of its file resources when I expected it to.
Is there a tool that I can use to determine which thread holds the impeding lock? If I can identify the thread, then I can inspect its call stack and at least try to determine why the resource is not yet disposed. The SOS debugging tool looks promising, but I don't see any feature that would remove a fair amount of guesswork from my investigation.
One thought is to identify the native OS thread-ID, which then can be mapped to a managed thread ID via SOS. How would I accomplish the former?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
您可以使用 SysInternals 工具中的 Process Explorer。 http://technet.microsoft.com/en-us/sysinternals/bb896653
只需打开它并搜索您的文件名即可。它会告诉你哪些进程有锁。
编辑:
哦,我刚刚重读了一遍,注意到您询问了特定的主题。我不知道 ProcessExplorer 是否可以做到这一点。对不起!
编辑2:
第二个答案,扩展了agent-j的答案:
如果您可以编辑代码并在其周围添加try/catch以获取IOException,您还可以记录堆栈跟踪,因为听起来这就是您想要检查的内容:
编辑 3
使用上面的方法,您还可以记录进程中所有线程的线程和堆栈跟踪,从而更容易查看日志和弄清楚尸检后发生了什么。更新的代码:
You can use Process Explorer from the SysInternals tools. http://technet.microsoft.com/en-us/sysinternals/bb896653
Just open it and search for your file name. it will show you what processes have a lock on it.
Edit:
Oh I just re-read that and noticed you asked for the specific thread. I dont know if ProcessExplorer can do that. Sorry!
Edit 2:
A second answer, that expands on agent-j's answer:
If you can edit the code and add a try/catch around it to get the IOException, you can also log the stack trace, since it sounds like that is what you want to inspect:
Edit 3
Using the approach above, you could also log the threads and stack traces for all threads in the process, making it easier to look through a log and figure out what happened postmortem. Updated code:
如果您在
try{delete();}catch(IOException)
catch 子句中放置断点。那么你不能查看每个线程的调用堆栈吗?If you put a breakpoint in a
try{delete();}catch(IOException)
catch clause. Can't you then look at the callstack of each thread?线程不持有文件锁(至少操作系统不持有锁)。考虑以下示例。线程
t
创建一个文件并锁定该文件。主线程写入流并关闭它。这表明该线程不拥有该锁。这个过程确实如此。打印
stopped
,因此打开文件的线程不再运行,但它创建的文件句柄仍然打开。这是上述文件的 FxCop 结果的相关部分
Threads do not hold locks on files (at least not as the operating system is concerned). Consider the following example. The thread
t
creates a file and locks the file. The main thread writes to the stream and closes it. This shows that the thread doesn't own the lock. The process does.Prints
stopped
, so the thread that opened the file is not running anymore, but the file handle it created is still open.Here is the relevant part of result of FxCop for the above file