Destructor con C++ with g++ (Aborted (core dumped))

Question

I am having a little problems with the destructor with g++, on MinGW works fine... it looks like the problem is when i destroy the objects at will, insted leting the program destroy them...

i compile this code

#include <iostream>
#include <string.h>
using namespace std;

class Alumno{
public:
    Alumno(string, int);
    ~Alumno();
    void Print();
private:
    string name;
    int age;
};

Alumno::Alumno(string n="------", int e=0)
{
    name = n;
    age = e;
}

Alumno::~Alumno()
{
    cout << "Done" << endl;
}
void Alumno::Print()

{
    cout << "Name: " << name << endl;
    cout << "Age:   " << age << endl;
}

int main()
{
    Alumno a;
    a.Print();
    cout << endl;
    a.~Alumno();
    cout << endl;

    Alumno a2("john",20);
    Alumno *ptrA=&a2;
    a2.Print();
    cout << endl;
    a2.~Alumno();
    ptrA->~Alumno();

    Alumno a3("Ana");
    a3.Print();


    return 0;
}

and i get this in response and i have no idea what is this...

Name: ------
Age:   0

Done

Name: john
Age:   20

Done
Done
*** Error in `./a.out': double free or corruption (fasttop): 0x00000000022e8010 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3ebde7d0b8]
/lib64/libstdc++.so.6(_ZNSsD1Ev+0x1f)[0x3ec82ba00f]
./a.out[0x400cd5]
./a.out[0x400e80]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x3ebde21b45]
./a.out[0x400b79]
======= Memory map: ========
00400000-00402000 r-xp 00000000 fd:02 1581527                            /home/ekiim/Documents/POO/a.out
00601000-00602000 r--p 00001000 fd:02 1581527                            /home/ekiim/Documents/POO/a.out
00602000-00603000 rw-p 00002000 fd:02 1581527                            /home/ekiim/Documents/POO/a.out
022e8000-02309000 rw-p 00000000 00:00 0                                  [heap]
3ebda00000-3ebda21000 r-xp 00000000 fd:00 1835646                        /usr/lib64/ld-2.17.so
3ebdc20000-3ebdc21000 r--p 00020000 fd:00 1835646                        /usr/lib64/ld-2.17.so
3ebdc21000-3ebdc22000 rw-p 00021000 fd:00 1835646                        /usr/lib64/ld-2.17.so
3ebdc22000-3ebdc23000 rw-p 00000000 00:00 0 
3ebde00000-3ebdfb6000 r-xp 00000000 fd:00 1835999                        /usr/lib64/libc-2.17.so
3ebdfb6000-3ebe1b6000 ---p 001b6000 fd:00 1835999                        /usr/lib64/libc-2.17.so
3ebe1b6000-3ebe1ba000 r--p 001b6000 fd:00 1835999                        /usr/lib64/libc-2.17.so
3ebe1ba000-3ebe1bc000 rw-p 001ba000 fd:00 1835999                        /usr/lib64/libc-2.17.so
3ebe1bc000-3ebe1c1000 rw-p 00000000 00:00 0 
3ebee00000-3ebef01000 r-xp 00000000 fd:00 1839117                        /usr/lib64/libm-2.17.so
3ebef01000-3ebf100000 ---p 00101000 fd:00 1839117                        /usr/lib64/libm-2.17.so
3ebf100000-3ebf101000 r--p 00100000 fd:00 1839117                        /usr/lib64/libm-2.17.so
3ebf101000-3ebf102000 rw-p 00101000 fd:00 1839117                        /usr/lib64/libm-2.17.so
3ebfe00000-3ebfe15000 r-xp 00000000 fd:00 1843105                        /usr/lib64/libgcc_s-4.8.2-20131212.so.1
3ebfe15000-3ec0014000 ---p 00015000 fd:00 1843105                        /usr/lib64/libgcc_s-4.8.2-20131212.so.1
3ec0014000-3ec0015000 r--p 00014000 fd:00 1843105                        /usr/lib64/libgcc_s-4.8.2-20131212.so.1
3ec0015000-3ec0016000 rw-p 00015000 fd:00 1843105                        /usr/lib64/libgcc_s-4.8.2-20131212.so.1
3ec8200000-3ec82e6000 r-xp 00000000 fd:00 1839064                        /usr/lib64/libstdc++.so.6.0.19
3ec82e6000-3ec84e5000 ---p 000e6000 fd:00 1839064                        /usr/lib64/libstdc++.so.6.0.19
3ec84e5000-3ec84ed000 r--p 000e5000 fd:00 1839064                        /usr/lib64/libstdc++.so.6.0.19
3ec84ed000-3ec84ef000 rw-p 000ed000 fd:00 1839064                        /usr/lib64/libstdc++.so.6.0.19
3ec84ef000-3ec8504000 rw-p 00000000 00:00 0 
7ff36bfa5000-7ff36bfa6000 rw-p 00000000 00:00 0 
7ff36bfa6000-7ff36bfa8000 rw-p 00000000 00:00 0 
7ff36bfa8000-7ff36bfa9000 rw-p 00000000 00:00 0 
7ff36bfa9000-7ff36bfaa000 rw-p 00000000 00:00 0 
7ff36bfcc000-7ff36bfcd000 rw-p 00000000 00:00 0 
7ff36bfcd000-7ff36bfce000 rw-p 00000000 00:00 0 
7ff36bfce000-7ff36bfcf000 rw-p 00000000 00:00 0 
7fff4d4e7000-7fff4d508000 rw-p 00000000 00:00 0                          [stack]
7fff4d5fe000-7fff4d600000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Aborted (core dumped)

any help ?

Answer 1

You should not call the destructor directly (only in some rare special occasions). It is called automatically when the function returns and the object was been allocated on the stack (what you are doing) or when you call delete when on the heap.

Answer 2

What's happening is ~Alumno() is calling the the destructor for std::string. Although Alumno doesn't do any custom memory management, std::string does, so that's causing a double free the second time ~Alumno() is called.

Try running this code. It is similar to what's happening in your code, where class A is a standin for alumno and class B is a standin for std::string.

#include <iostream>

class B
{
  public:
  ~B() { std::cout << "~B()" << std::endl; }
};

class A
{
  public:
  ~A() { std::cout << "~A()" << std::endl; }

  B myB;
};

void foo (void)
{
  A myA;

  myA.~A();
}

int main(int argc, char * argv[])
{
  foo();

  system("pause");

    return 0;
}

It should produce this output...

~A()
~B()
~A()
~B()

In general, there are two big takeaways from this...

1) Don't manually call the destructor (there is one exception to this, it's when using placement new which is incredibly obscure).

2) There's a cool tool called valgrind for Linux. I don't know if you have access to it, but if you do then use it when you have weird memory issues. It tends to be illuminating.