带有G 的破坏者con C (中止(核心倾倒））

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

本文关键字：中止 核心 破坏者 con 带有      更新时间：2023-10-16

我对带有g 的destructor遇到了一些问题，mingw上的工作正常...看来问题是当我随意销毁对象时，让程序销毁它们...

我编译此代码

#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;
}

我得到了回应，我不知道这是什么... 

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)

有帮助吗？

您不应直接调用灾难函数（仅在某些罕见的特殊场合）。当功能返回并在堆栈上分配对象时，它被称为自动称为（您在做什么），或者在堆上调用delete时。

正在发生的事情是〜Alumno（）称为std :: string的破坏者。尽管校友不做任何自定义内存管理，但std :: string却做到了，所以第二次〜Alumno（）被称为双重。

尝试运行此代码。它类似于您的代码中发生的事情，其中A类是校友的立场，B类是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;
}

它应该产生此输出... 

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

一般而言，这有两个大的东西...

1）不要手动调用驱动器（有一个例外，是当使用放置新时，它非常晦涩难懂）。

2）有一个很酷的工具，称为Linux的 valgrind 。我不知道您是否可以访问它，但是如果您确实有奇怪的内存问题时使用它。它倾向于照明。

相关文章：