7

我不知道这个问题是否会很清楚，因为我不能提供太多细节（我使用的是 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

困扰我的是，在调试时，我发现段错误发生在标有“这里”的行。Data 类只有 A_、B_ 和 C_ 作为动态分配的属性。我还尝试在其他非动态复合属性上显式调用析构函数，以查看它们在销毁过程中是否出现问题，但段错误再次发生在析构函数的末尾。什么样的错误会在那时产生段错误？

我希望问题足够清楚，如果需要，我会添加详细信息。

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

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

  • 关于错误详情。我可以在这里给你调试期间错误回溯中的最后一项（我为错误的格式道歉，但我不知道如何说得好）：

    1. ../nptl/sysdeps/unix/sysv/linux/raise.c:64 处的 raise (sig=) 中的 0x00007ffff432fba5

    2. 0x00007ffff43336b0 在 abort () at abort.c:92

    3. ../sysdeps/unix/sysv/linux/libc_fatal.c:189 处的 __libc_message (do_abort=, fmt=) 中的 0x00007ffff436965b

    4. malloc_printerr 中的 0x00007ffff43736d6 (action=3, str=0x7ffff4447780 "free(): 损坏的未排序块", ptr=) 在 malloc.c:6283

    5. 0x00007ffff4379ea3 在 __libc_free (mem=) at malloc.c:3738

    6. /home/bartgol/LifeV/trilinos/trilinos-10.6.4-src/packages/epetra/src/Epetra_BlockMapData.cpp:110 中的 Epetra_BlockMapData::~Epetra_BlockMapData ( this=0x1461690, __in_chrg=) 中的 0x0000000000c21f71

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

4

3 回答 3

5

在函数退出时可能导致段错误的一个问题是堆或堆栈损坏。

您的程序的某些其他部分可能会导致问题。诸如双重破坏或缓冲区溢出之类的东西可能会导致内存损坏。

通常，程序的调试版本会在函数退出时进行检查，以确保堆栈完好无损。如果不是，那么，您会看到结果。

于 2012-07-31T02:04:58.120 回答
2

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

PS 风格上的代码很糟糕。为什么他们在做之前检查 null delete？在析构函数中将已删除的指针归零有什么意义？

于 2012-07-31T04:56:15.943 回答
0

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

于 2012-07-30T18:05:38.330 回答