6

请注意，我不想解决我的问题的任何问题 - 我正在考虑事情发生的概率，因此想知道一些事情：

如果您删除对象并使用 gcc 作为编译器，究竟会发生什么？

上周我正在调查一次崩溃，其中竞争条件导致对象的双重删除。

调用对象的虚析构函数时发生崩溃，因为指向虚函数表的指针已经被覆盖。

虚函数指针是否被第一次删除覆盖？

如果不是，那么第二次删除是否安全，只要同时没有进行新的内存分配？

我想知道为什么我之前没有识别出我遇到的问题，唯一的解释是虚拟函数表在第一次删除期间被立即覆盖，或者第二次删除没有崩溃。

（第一个意味着如果“比赛”发生，崩溃总是发生在同一个位置 - 第二个，当比赛发生时通常什么都不会发生 - 并且只有在第三个线程覆盖删除对象时才会发生问题。 )

编辑/更新：

我做了一个测试，以下代码因段错误（gcc 4.4、i686 和 amd64）而崩溃：

class M
{
private:
  int* ptr;
public:
  M() {
  ptr = new int[1];
  }
  virtual ~M() {delete ptr;}
};

int main(int argc, char** argv)
{
  M* ptr = new M();
  delete ptr;
  delete ptr;
}

如果我从 dtor 中删除“虚拟”，程序会被 glibc 中止，因为它检测到双重释放。对于“虚拟”，在对析构函数进行间接函数调用时会发生崩溃，因为指向虚拟函数表的指针无效。

在 amd64 和 i686 上，指针都指向一个有效的内存区域（堆），但是那里的值是无效的（一个计数器？它非常低，例如 0x11 或 0x21）所以编译器时的“调用”（或“jmp”做了返回优化）跳转到无效区域。

程序接收信号 SIGSEGV，

分段故障。0x0000000000000021

在 ？？() (gdb)

#0 0x0000000000000021 在?? ()

#1 0x000000000040083e 在 main ()

所以在上面提到的条件下，指向虚函数表的指针总是被第一次删除覆盖，所以如果类有虚析构函数，下一次删除将跳转到必杀技。

4

3 回答 3

6

删除两次是未定义的行为 - 您不需要任何进一步的解释，而且寻找一个通常是徒劳的。它可能会导致程序崩溃，也可能不会，但这始终是一件坏事，并且在您完成之后程序将始终处于未知状态。

于 2010-07-31T15:48:00.350 回答
6

它非常依赖于内存分配器本身的实现，更不用说任何依赖于应用程序的故障作为覆盖某些对象的 v-table。有许多内存分配器方案，它们的功能和对双 free() 的抵抗力各不相同，但所有这些都有一个共同的属性：您的应用程序将在第二个 free() 之后的某个时间崩溃。

崩溃的原因通常是内存分配器在每个分配的内存块之前（页眉）和之后（页脚）专用少量内存来存储一些特定于实现的细节。标头通常定义块的大小和下一个块的地址。页脚通常是指向块头的指针。删除两次通常至少涉及检查相邻块是否空闲。因此，如果出现以下情况，您的程序将崩溃：

1) 指向下一个块的指针已被覆盖，第二个 free() 在尝试访问下一个块时会导致段错误。

2）前一个chunk的footer被修改，访问前一个chunk的header导致segfault。

如果应用程序幸存下来，则意味着 free() 在各个位置都损坏了内存，或者将添加与已经空闲块之一重叠的空闲块，从而导致将来数据损坏。最终，您的程序将在涉及损坏的内存区域的以下 free() 或 malloc() 之一处发生段错误。

于 2010-07-31T16:15:35.950 回答
1

通过执行delete两次（或什至free），内存可能已经被重新分配，delete再次执行可能会导致内存损坏。分配的内存块的大小通常保存在内存块本身之前。

如果您有派生类，请不要在派生类（子类）上调用 delete。如果它没有被声明为虚拟的，那么只有~BaseClass()析构函数被调用，留下任何分配的内存DerivedClass来持久化和泄漏。这假设在必须释放DerivedClass的内存之上和之外分配了额外的内存。BaseClass

IE

BaseClass* obj_ptr = new DerivedClass;  // Allowed due to polymorphism.
...
delete obj_ptr;  // this will call the destructor ~Parent() and NOT ~Child()
于 2010-08-01T01:14:42.737 回答