I’ve been plugging away at my multi-process Win32 debugger code this week and one of my test harnesses had started to suffer from intermittent “R6025 - pure virtual function call” errors. These tend to crop up if you call a virtual function from a constructor or destructor or if there’s a race condition between calling a method on an object from one thread and destroying the object in another thread. For me, at least, they tend to be simple mistakes to fix once I know where the problem lies.
A while back Chris Baus wrote a little rant about prototypes. I started to write a piece that defended prototypes when correctly used and ran out of steam; or, more to the point, couldn’t really say very much except they’re OK except when they’re not, try not to get to the point where they’re not.
Having just recently been bitten by a prototype that was trying to rise above its station, I now have more to say.
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.
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).
Every now and then I come across a situation where encapsulation has been taken slightly too far. Usually, or at least most recently, these over encapsulated designs have had problems because they’ve blocked access to an event handle. It’s great to wrap up a bunch of Win32 primitives into a nice coherent class but if you expose a method that allows the user of the class to wait for something to happen then it’s probably also a good idea to expose a handle they can wait on as well.
Recently I finished developing a high performance ISO-8583 financial transaction authorisation server for a client using The Server Framework and whilst I was running the final black-box tests against the server I realised that these particular tests were dependant on the system date of the machine running the server. The server uses the current time and date to make some decisions on whether it can authorise a particular transaction or not.
It seems to be stack walking week; what with Ned’s posting earlier about walking an unmanaged stack and now this excellent piece by David Broman on doing the same in with managed code.
