/* Rambling comments... */

Purecall

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.

Unfortunately, often the standard error report of a "purecall" is less than useful. So I decided to fix that.

The code that handles a "purecall" is part of the Visual Studio runtime library. I imagine that the compiler fills in each entry in a virtual function table as a call to "purecall" when it first constructs the table and as objects are constructed they overwrite these function pointers with the real one. Likewise on destruction the compiler can fill in the invalid slots with a pointer to the "purecall" function and trap such calls for you.

The runtime library implementation of purecall displays "R6025 - pure virtual function call" to the console or pops up the following dialog box

Unfortunately, the "retry" button often doesn't end up with me in the debugger solving the problem. Luckilly it's easy to replace the standard implementation of purecall with your own. Simply provide a function with this signature int __cdecl _purecall(void) and link with it before you link with the CRT. This usually just means adding this function to your code somewhere, such as in the same file as main() which will cause the linker to find it before it finds the standard one. Once you do this you can take control over what happens when a purecall situation arises. I decided to take a snapshot of the call stack and display that:

Which leads to much faster debugging...