I am aware of the ability to modify the handler for the "pure virtual function called" error message via something like:

namespace __cxxabiv1 {
        extern "C" void
        __cxa_pure_virtual(void) {
                // Print a backtrace, etc...
                std::terminate();
        }
}

It is a great shame that the default, gcc-supplied function declaration does not take an argument of the function pointer that was called, then the RTTI information could be output. Note that the error message comes from a pure virtual base class on which a pure virtual function has been called. Therefore one would suppose that the was guaranteed to be RTTI information regarding that function call, if not the enclosing pure virtual base class. So the default implementation of __cxa_pure_virtual() would be able to call "typeid(ptr_to_mem_fn).name()" to provide actual type information regarding the class and the function that was attempted to be called.

I realise that the declaration could be difficult, because the new argument to __cxa_pure_virtual(...) would need to be able to cope with both void and non-void return types, cv-qualifiers, and arbitrary arguments. i.e. it would need some form of declaration "magic". But the code is within the compiler! At the call site where the canary is being placed, the type of the member function is explicitly known, so the specific declaration (in particular the ptr-to-mem-fn argument) of __cxa_pure_virtual() can be generated for that call site, and therefore typeid(of the ptr-to-mem-fn arg) could be correctly generated.

If I knew how g++ worked internally, I'd do this change. But I don't, I'm sorry.

The issue I face is that I have a multi-threaded program that has a race condition that causes the "pure virtual function call" error very rarely. The code-base is very large, so it is very hard (I have tried) to track down where the bug is. It does not appear in debug builds (-O0) and using my own implementation of __cxa_pure_virtual() and calling set_terminate with my own functions that generate backtraces has not created the backtrace I'd hope for.

I know also that the code I am referring to above is buggy, therefore I should "just not write it". True. But surely improving the quality of the error message with the class name and function name in the "pure virtual method called" message would be og much help to the C++ community at large?