【问题标题】:What exactly happens if you delete an object? (gcc) (When double-delete crashes?)如果你删除一个对象,究竟会发生什么? (gcc) (当双重删除崩溃时?)
【发布时间】:2011-03-23 16:01:19
【问题描述】:

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

如果你删除对象并使用 gcc 作为编译器会发生什么?

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

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

第一次delete会覆盖虚函数指针吗?

如果不是,那么第二次删除是否安全,只要在此期间没有进行新的内存分配?

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

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


编辑/更新:

我做了一个测试,以下代码因段错误(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 中删除 'virtual',程序会被 glibc 中止,因为它检测到双重释放。 使用 'virtual' 在对析构函数进行间接函数调用时会发生崩溃,因为指向虚函数表的指针无效。

在 amd64 和 i686 上,指针都指向一个有效的内存区域(堆),但那里的值无效(计数器?它非常低,例如 0x11 或 0x21)所以“调用”(或“jmp”当编译器进行返回优化时)跳转到无效区域。

节目收到信号SIGSEGV,

分段错误。 0x0000000000000021

在?? () (gdb)

#0 0x0000000000000021 在?? ()

#1 0x000000000040083e in main()

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

【问题讨论】:

  • 听起来你也需要投资一些互斥体或关键部分
  • 0A0D:这是我的初步解决方案(解决方法)。实际上有一个设计缺陷,因为没有意图有两个线程可以删除对象。

标签: c++ gcc probability delete-operator postmortem-debugging


【解决方案1】:

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

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

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

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

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

【讨论】:

  • 如果删除后没有malloc,删除的元素会怎样?
  • 我用gcc 4.4做了一些测试:确实好像第一次delete覆盖了虚函数表,所以第二次调用虚析构函数时就崩溃了。使用非虚拟析构函数,glibc 会检测到 double-free 并中止程序。
  • 我将我所做的测试及其结果添加到我的问题中。
  • 嗯,这意味着当标记块空闲时,glibc 使用一些释放的内存来实现某种数据结构(例如根据块的大小对块进行排序)。
【解决方案2】:

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

【讨论】:

  • 了解删除对象可能发生的情况以及对核心转储分析没有帮助的情况。
  • @Ian 首先我不喜欢核心转储。此外,除非您对内存分配系统有深入的了解,否则您真的无法判断会发生什么,这很少有人知道,并且很可能会随着编译器的发布而变化。
  • 我宁愿完全没有错误,但它们会发生 - 崩溃也是如此。那么了解可能发生的事情(以及发生的原因可能是什么)和不发生的事情是非常有用的。在长期运行的项目中,您通常不会经常更改编译器。希望编译器和它的 libc 不会在不注意的情况下更改内存分配器。
【解决方案3】:

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

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

BaseClass* obj_ptr = new DerivedClass;  // Allowed due to polymorphism.
...
delete obj_ptr;  // this will call the destructor ~Parent() and NOT ~Child()

【讨论】:

  • 查看我上面的更新:至少使用新的 gcc,即使同时没有 new/malloc,双重删除也会立即崩溃。而且我知道为什么析构函数 almos 总是需要是虚拟的。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2022-06-27
  • 2011-05-09
  • 2015-05-10
  • 1970-01-01
  • 2017-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多