Jeff Darcy over at “Canned Platypus” writes about “How to add locking to a program”. He laments the lack of a reasonably priced deadlock detection tool. I assume, from his backgrond, that he’s interested in an Linux tool, so my deadlock detection tool wont help him much but it’s good to know that it’s not just me that thinks such a tool would be useful…
Jeff links to some expensive static code analysis tools that do deadlock detection.
Ned Batchelder has written about the code he uses to get a call stack out of a windows program (thanks for the link Barry). I’ve added a snippet of the code I use as a comment to his post.
Note: the deadlock detector mentioned in this blog post is now available for download from www.lockexplorer.com.
I started looking into working with windows call stacks a while ago when I was working on my deadlock detection tool.
I’ve been working on my deadlock detection and lock monitoring tool quite a lot this week; that and fixing the issues that it’s been highlighting. Yesterday I decided that I was drowning in data and that I really needed a GUI and, as I thought about how the GUI should work, I realised that I really didn’t have enough data.
Note: the deadlock detector mentioned in this blog post is now available for download from www.
I have some code that launches another process in a suspended state, does some stuff (tm) and then resumes the process. This uses CreateProcess() and works fine on unmanaged exes. When I try and launch a manged exe with the same code the process starts up in a running state rather than in a suspended state. The docs for CreateProcess() don’t mention any strangeness. Does anyone know of any docs that explain what’s going on?
I added some more monitoring to the deadlock tool. You can now view the entire life cycle of the locks, from initialisation, through usage to destruction. The lock usage figures put the contention figures in context as you can see how often the lock was acquired by each thread and compare that to how often there was contention…
Note: the deadlock detector mentioned in this blog post is now available for download from www.
The deadlock detection tool that I was working on last week is coming on nicely. I managed to locate two potential deadlocks that had never caused any problems in code that is running live on a client’s site. Once I had a report from my tool it was relatively easy to fix the problems. Both of these were real bugs that just hadn’t bitten yet.
Today I added some rudimentary lock contention monitoring to the tool and the results seem to be quite useful…
As I mentioned in an earlier posting I’ve been working on a tool this week. I’m too lazy to do a job manually and so I decided to write a tool to help me do it…
Note: the deadlock detector mentioned in this blog post is now available for download from www.lockexplorer.com.
The tool is designed to help me track down deadlocks in code. I decided I needed this tool because I wrote a piece about debugging deadlocks in Visual C++ and realised that using trial and error to locate deadlocks in some client code simply wasn’t good enough.
Last week I posted an entry about the simple, hand built, mocks that I use for testing in C++. Whilst I stand by my previous assertion that writing the mocks yourself gives you an further insight into your design from a client perspective I think the discussion that I had with Roy Osherove after last week’s posting has made me appreciate the power of having mocks that support the programmatic specification of ’expected’ behaviour.
