析构函数末尾的分段错误

Segmentation fault at the end of destructor

本文关键字：分段 错误 析构函数      更新时间：2023-10-16

我不知道这个问题是否会很清楚，因为我不能给出太多细节（我使用的是TPL，自己写了很多行）。但我会试试的。

我遇到了无法理解的分段错误。有一个结构（我没有设计，但应该经过很好的测试），它的析构函数看起来像这个

Data::~Data()
{
  if(A_ != 0) {
    delete A_;
    A_ = 0;
  }
  if(B_ != 0) {
    delete B_;
    B_ = 0;
  }
  if(C_ != 0) {
    delete C_;
    C_ = 0;
  }
} // HERE

困扰我的是，在调试时，我发现segfault发生在标有"HERE"的行。类Data只有A_、B_和C_作为动态分配的属性。我还试图显式地调用其他非动态复合属性的析构函数，看看在它们的销毁过程中是否出现了问题，但segfault再次发生在析构函数的末尾。在这一点上，什么样的错误会导致segfault？。

我希望问题足够清楚，如果需要，我会补充细节。

编辑：谢谢回复。我知道这是一段稀缺的代码，但整个库当然太大了（顺便说一句，它来自Trilinos，但我认为错误不是他们的错，一定是我在处理他们的结构时犯了错误。我使用了简短的名称来使问题更紧凑）。有人在评论中询问的一些评论回复道：

  • 关于删除前的检查和原始指针：正如我所说，这不是我的选择。我想这是一种双重保护，以防出现问题，并且a_、B_或C_已经被数据结构的其他所有者删除。选择原始指针与shared_ptr或其他安全/智能指针可能是因为该类几乎从未直接使用过，而仅由具有指向Data的指针的Map类对象使用。这个类Map是在同一个库中实现的，所以他们可能选择了原始指针，因为他们知道自己在处理什么以及如何处理
  • 是的，数据结构由同一对象的所有副本共享。特别是，有一个Map类，它包含一个指向Data对象的指针。所有互为副本的Map都共享相同的数据。引用计数器跟踪有多少Map持有指向数据的指针。最后一个要销毁的Map会删除数据
  • 数据结构的引用计数器工作正常，我检查了它
  • 我不是在调用这个类的析构函数。它由类Map的对象的析构函数自动调用，该对象具有指向Data的指针作为属性
  • Data继承自BaseData，后者的（虚拟）析构函数不做任何事情，因为它只是一个接口定义类
  • 很难发布重现问题的代码。原因有很多。这个错误只出现在2个以上的进程中（这是一个mpi程序），我猜是一个进程有一些空列表，并试图访问一些元素

  • 关于错误详细信息。我可以在这里给你调试期间错误的回溯中的最后一项（我为错误的格式道歉，但我不知道如何很好地表达它）：

    1. 0x00007ffff432fba5在..处提升（sig=）/nptl/sysdeps/unix/sysv/linux/raise.c:64

    2. 0x00007ffff43336b0在中止时中止（）。c:92

    3. 位于..的__libc_message（do_abort=，fmt=）中的0x00007ffff436965b/sysdeps/unix/sysv/linux/libc_fatal.c:189

    4. malloc.c:6283 处malloc_printerr中的0x00007ffff43736d6（action=3，str=0x7ffff4447780"free（）：损坏的未排序块"，ptr=）

    5. 0x00007ffff4379ea3在malloc.c:3738 的__libc_free（mem=）中

    6. 0x0000000000c21f71在Epetra_BlockMapData:：~位于/home/bartgol/LifeV/trilinos/trilinos-10.6.4-src/packages/Epetra/src/Epetra_2lockMapData.cpp:110 的Epetra_BlockMapData（this=0x1461690，__in_chrg=）中

最后，让我重申我的怀疑：即使所有属性都已经删除，在析构函数的末尾会出现什么样的错误？再次感谢！

在函数出口处可能导致segfault的一个问题是堆或堆栈损坏。

可能是程序的其他部分造成了问题。类似于双重破坏或缓冲区溢出的操作可能会导致内存损坏。

通常，程序的调试构建将包括在函数出口进行检查，以确保堆栈完好无损。如果不是，那么，你可以看到结果。

当类析构函数的显式主体完成时，它会继续执行一些隐式操作：它调用基类和成员析构函数（如果你有基类和成员带有非平凡的析构函数），如果必要，它调用原始内存释放函数operator delete（是的，在典型的实现中，operator delete实际上是从析构函数内部调用的）。显然，这两个隐含过程中的一个导致了您案例中的崩溃。如果没有更多的信息，就无法准确地说出来。

附言：从风格上讲，代码很糟糕。为什么他们在执行delete之前要检查null？将析构函数中删除的指针置零有什么意义？

很难从您显示的稀少代码中分辨出来。很容易，您已经释放了类成员之一或基类在其自己的析构函数中使用的资源。

相关文章：