There’s an interesting article by Tomer Abramson in this month’s Dr Dobb’s Journal about deadlock detection. He provides a compile in tool that works in a similar way to my deadlock detection tool and reports on potential deadlocks in code even if they never occur during the program run in question. His architecture is considerably different to mine but the idea is the same. By recording the sequence of lock acquisition and release on all threads in the program you can then examine the sequence that locks are taken out and spot potential deadlocks.

I’ve just finished the first cut of the code that handles the Win32 Thread Naming “API”. This means that my debugging tools can now report the name of a thread (if it has been named) rather than just its thread ID. Having implemented the code in the debugger to deal with the exception I find myself wondering about API design and why the original designer of this particular facility decided to make it hard on themselves.

Dennis Forbes talks about “Edit and Continue” in VS 2005 and asks “Is it, coupled with similar tool advances, making programmers sloppier, though?” I think so… In the Visual C++ debugger we’ve had “Edit and Continue” for years but I turned it off a long time ago as I didn’t find it that helpful. It enables and encourages quick hacky experimental fixes to running code. I never really liked that idea, I usually prefer to think about the problem rather than just hacking in a fix, and back in the early days of VC6 the whole incremental link/edit and continue thing sometimes introduced interesting bugs that seemed to go away if you did a full clean build.

Ben takes the “throw as an exception dispatcher” idiom to its logical conclusion by presenting a pluggable exception handler. As Ben says “I’m not sure how many situations something like this would be useful in, but it fit the testing problem well and was fun to write anyway”. It’s not the kind of code you need every day, but it’s useful stuff if you’re working on a test framework, or if you’re interested in how you can use the “throw as an exception dispatcher” idiom.

I’m in the process of testing some of my code with Visual Stuio 2005 and the first thing I found that I needed to do was to upgrade my STLPort installation from 4.6.2 to 5.0.0 to get a version that built with VC8. Given that I like to test one change at a time I first upgraded my VC6 build to use STLPort 5; STLPort built fine with VC6 and all my tests passed.

In case you missed it the first time around… We’re doing the old “assert is evil”/“Oh no it isn’t” thing over at Ned Batchelder’s place.

I’ve been using the SetThreadName() function from the MSDN docs for ages to provide a way of distinguishing between threads in the VC debugger. I always thought it was a bit of a weird ‘API’ but had never really thought to wonder why. Steve over at “Bug Babble” explains how the ‘API’ works from the debugger’s point of view and, well, then it all becomes obvious. For some reason I’d always thought that the ‘API’ was communicating with the OS in some weird and wacky manner; I hadn’t twigged that in fact it was just communicating with the debugger using the only method it could, via raising an exception which gets routed through the Win32 debug API.

A couple of days ago I mentioned that I was having some problems with loading symbols for a common controls dll. I’m now pretty sure that it was my problem, as usual, rather than someone elses. I’ve reworked my process startup controlling code and now set and clear the breakpoints in a more reliable (i.e. less hacky) way and things are behaving themselves again. I think I was failing to stop one of the threads properly and that was later causing problems.

I was using one of my home made debugging tools recently and it kept crashing :( I assumed it was something I was doing but I’ve eventually tracked it down to where I load the symbols for the loaded modules in the target process. Attempting to load the symbols for x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9\\comctl32.dll leads to dbghelp.dll generating a BEX event (which appears to be either buffer overrun or data execution prevention related).

Ned Batchelder reminds us of the value of the C++ FAQ (Lite). It’s been a long while since I’ve looked at it yet Ned’s example shows that I’ve still a lot to learn about the subtleties of C++. I can think of a few places where I could use that throw; as an exception dispatcher example to replace some rather ugly macros.