Possible memory leak without a virtual destructor?

Question

#include <iostream>
using namespace std;
class base
{
   int a;
 public: 
   base() {a =0;}
 };
 class derv :public base
 {
   int b;
  public:
   derv() {b =1;}
 };
 int main()
 {
    base *pb = new derv();
    delete pb;
 }

I don't have a virtual destructor in derv class, does it delete only base part of derv object??

Answer 1

It might.

Because base does not have a virtual destructor, your code exhibits undefined behavior. Anything might happen. It might appear to work as you expect. It might leak memory. It might cause your program to crash. It might format your hard drive.

A citation was requested. C++11 §5.3.5/3 states that, for a scalar delete expression (i.e., not a delete[] expression):

if the static type of the object to be deleted is different from its dynamic type, the static type shall be a base class of the dynamic type of the object to be deleted and the static type shall have a virtual destructor or the behavior is undefined.

The static type (base) is different from the dynamic type (derv) and the static type does not have a virtual destructor, so the behavior is undefined.

Answer 2

In your source code there is no memory leak, since you don't have any member variable that is created dynamically.

Consider the modified example below Case 1:

#include <iostream>
using namespace std;
class base
{
   int a;
 public: 
   base() {a =0;}
   ~base() 
     {
       cout<<"\nBase Destructor called";

     }
 };
 class derv :public base
 {
   int *b;

  public:
   derv() { b = new int;}
  ~derv()
  {
      cout<<"\nDerv Destructor called"; 
      delete b;
  }
 };
 int main()
 {
    base *pb = new derv();
    delete pb;
 }

In this case the output will be,

   Base Destructor called

In this case there is a memory leak, because 'b' is created dynamically using 'new' which should be deleted using 'delete' keyword. Since derv destructor is not being called it's not deleted so there is memory leak.

Consider the below case 2:

#include <iostream>
using namespace std;
class base
{
   int a;
 public: 
   base() {a =0;}
   virtual ~base() 
     {
       cout<<"\nBase Destructor called";

     }
 };
 class derv :public base
 {
   int *b;

  public:
   derv() { b = new int;}
  ~derv()
  {
      cout<<"\nDerv Destructor called"; 
      delete b;
  }
 };
 int main()
 {
    base *pb = new derv();
    delete pb;
 }

In the case 2 output will be,

Derv Destructor called 
Base Destructor called

In this case there is no memory leak.because derv destructor is called and b is getting deleted.

Destructor can be defined as Virtual in base class to make sure the derived class destructor to be called when we delete base class pointer which is pointing to derived class object.

We can say 'Destructor must be virtual when derived class has dynamically created members'.

Answer 3

To add to the discussion. GCC will throw an error if you ask it to do memory sanitizing on code where the destructor is not defined as virtual. You need to use

-fsanitize=address

as a compile option.

For example

#include <cstdio>

class Base
{
public:
 Base()
 {
    printf("ctor Base\n");
 }

  ~Base()
 {
    printf("dtor Base\n");
 }
};

class Derived : public Base {
private:
  double val;

public:
 Derived(const double& _val)
 : val(_val)
 {
    printf("ctor Derived\n");
 }

 ~Derived()
 {
    printf("dtor Derived\n");
 }
};

int main() {
    Derived* d = new Derived(5);
    Base* p = d;
    // Derived destructor not called!!
    delete p;
    //delete d;
}

when compiled will output the following error

ASM generation compiler returned: 0
Execution build compiler returned: 0
Program returned: 1
=================================================================
==1==ERROR: AddressSanitizer: new-delete-type-mismatch on 0x602000000010 in thread T0:
  object passed to delete has wrong type:
  size of the allocated type:   8 bytes;
  size of the deallocated type: 1 bytes.
    #0 0x7fc6ed4db428 in operator delete(void*, unsigned long) (/opt/compiler-explorer/gcc-13.1.0/lib64/libasan.so.8+0xdc428) (BuildId: c9b24be17e4cbd04bdb4891782c4425e47a9259a)
    #1 0x401177 in main /app/example.cpp:38
    #2 0x7fc6ece58082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
    #3 0x4011fd in _start (/app/output.s+0x4011fd) (BuildId: 2751b7982ec6bd6f9c9092db77c9bfa142055e2d)

0x602000000010 is located 0 bytes inside of 8-byte region [0x602000000010,0x602000000018)
allocated by thread T0 here:
    #0 0x7fc6ed4da528 in operator new(unsigned long) (/opt/compiler-explorer/gcc-13.1.0/lib64/libasan.so.8+0xdb528) (BuildId: c9b24be17e4cbd04bdb4891782c4425e47a9259a)
    #1 0x40112f in main /app/example.cpp:35

SUMMARY: AddressSanitizer: new-delete-type-mismatch (/opt/compiler-explorer/gcc-13.1.0/lib64/libasan.so.8+0xdc428) (BuildId: c9b24be17e4cbd04bdb4891782c4425e47a9259a) in operator delete(void*, unsigned long)
==1==HINT: if you don't care about these errors you may set ASAN_OPTIONS=new_delete_type_mismatch=0
==1==ABO 

See https://godbolt.org/z/aaTrovaPE

If however you declare a virtual destructor on base then the error goes away.

Answer 4

There is no memory leak in your code. There would have been a memory leak if you needed to free some memory in the derived class destructor.