Purecall

| 2 Comments

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

StandardPureCall.png

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:

MyPureCall.png

Which leads to much faster debugging...

2 Comments

Thank you for an insightful article. I have a question about a statement you made towards the end of the article. Do you print the call stack programmatically or from Visual Studio? If the former, I would appreciate any pointers to the code that allows me to print the call stack.

Thank you.

I do it programatically. I started with the code on CodeProject from Jochen Kalmbach - StackWalker.

Leave a comment