Where do "pure virtual function call" crashes come from?

I occasionally see programs that crash on my computer system with the mistake: "pure digital function call".

Just how do these programs also compile when an object can not be developed of an abstract class?

117
2022-07-04 14:31:14
Source Share
Answers: 5

I would certainly presume there is a vtbl developed for the abstract class for some inner factor (it could be required for some type of run time type details) and also something fails and also an actual object obtains it. It is a bug. That alone need to claim that something that can not take place is.

Pure supposition

edit: resembles I'm incorrect in case concerned. OTOH IIRC some languages do permit vtbl calls out of the erector destructor.

1
2022-07-04 16:27:17
Source

As well as the standard case of calling a virtual function from the constructor or destructor of an object with pure virtual functions you can also get a pure virtual function call (on MSVC at least) if you call a virtual function after the object has been destroyed. Obviously this is a pretty bad thing to try and do but if you're working with abstract classes as interfaces and you mess up then it's something that you might see. It's possibly more likely if you're using referenced counted interfaces and you have a ref count bug or if you have an object use/object destruction race condition in a multi-threaded program... The thing about these kinds of purecall is that it's often less easy to fathom out what's going on as a check for the 'usual suspects' of virtual calls in ctor and dtor will come up clean.

To help with debugging these kinds of problems you can, in various versions of MSVC, replace the runtime library's purecall handler. You do this by providing your own function with this signature:

int __cdecl _purecall(void)

and linking it before you link the runtime library. This gives YOU control of what happens when a purecall is detected. Once you have control you can do something more useful than the standard handler. I have a handler that can provide a stack trace of where the purecall happened; see here: http://www.lenholgate.com/blog/2006/01/purecall.html for more details.

(Note you can also call _set_purecall_handler() to install your handler in some versions of MSVC).

67
2022-07-04 16:18:01
Source

Usually when you call a digital function via a dangling reminder - - more than likely the instance has actually currently been damaged.

There can be extra "creative" factors, also: possibly you've taken care of to trim the component of your object where the digital function was applied. Yet generally it is simply that the instance has actually currently been damaged.

8
2022-07-04 15:04:33
Source

Here is a stealthy means for it to take place. I had this basically take place to me today.

class A
{
  A *pThis;
  public:
  A()
   : pThis(this)
  {
  }

  void callFoo()
  {
    pThis->foo(); // call through the pThis ptr which was initialized in the constructor
  }

  virtual void foo() = 0;
};

class B : public A
{
public:
  virtual void foo()
  {
  }
};

B b();
b.callFoo();
3
2022-07-04 15:02:41
Source

They can result if you attempt to make a digital function call from an erector or destructor. Given that you can not make a digital function call from an erector or destructor (the acquired class object hasn't been created or has actually currently been damaged), it calls the base class variation, which when it comes to a pure virtual function, does not exist.

class Base
{
public:
    Base() { reallyDoIt(); }
    void reallyDoIt() { doIt(); } // DON'T DO THIS
    virtual void doIt() = 0;
};

class Derived : public Base
{
    void doIt() {}
};

int main(void)
{
    Derived d;  // This will cause "pure virtual function call" error
}

See additionally Raymond Chen is 2 articles on the subject

113
2022-07-04 15:00:40
Source