请注意,我不想用我的问题解决任何问题 - 我在考虑事情发生的概率,因此想知道一些事情:
如果删除对象并使用 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 中删除“虚拟”,程序将被 glibc 中止,因为它检测到双重释放。 对于“虚”,在对析构函数进行间接函数调用时会发生崩溃,因为指向虚函数表的指针无效。
在 amd64 和 i686 上,指针指向一个有效的内存区域(堆),但是那里的值是无效的(一个计数器?它非常低,例如 0x11 或 0x21)所以 'call'(或 'jmp'当编译器进行返回优化时)跳转到无效区域。
Program received signal SIGSEGV,
Segmentation fault. 0x0000000000000021
in ?? () (gdb)
#
0 0x0000000000000021 in ?? ()
#
1 0x000000000040083e in main ()
所以在上述条件下,指向虚函数表的指针总是被第一次删除覆盖,所以如果类有虚析构函数,下一次删除将跳转到必杀技。
最佳答案
它非常依赖于内存分配器本身的实现,更不用说任何依赖于应用程序的故障,如覆盖某些对象的 v-table。有许多内存分配器方案,它们在功能和对双重 free() 的抵抗力方面各不相同,但所有这些都有一个共同的特性:您的应用程序将在第二次 free() 之后的某个时间崩溃。
崩溃的原因通常是内存分配器在每个分配的内存块之前(页眉)和之后(页脚)专用少量内存来存储一些实现特定的细节。 header 通常定义 block 的大小和下一个 block 的地址。页脚通常是指向 block 头的指针。删除两次通常至少涉及检查相邻 block 是否空闲。因此,如果出现以下情况,您的程序将崩溃:
1) 指向下一个 block 的指针已被覆盖,第二个 free() 在尝试访问下一个 block 时导致段错误。
2) 前一个 block 的页脚被修改,访问前一个 block 的头部导致段错误。
如果应用程序存活下来,则意味着 free() 要么在多个位置损坏了内存,要么将添加与已经空闲的 block 之一重叠的空闲 block ,从而导致 future 数据损坏。最终,您的程序将在以下涉及损坏内存区域的 free() 或 malloc() 之一发生段错误。
关于c++ - 如果删除一个对象,究竟会发生什么? (gcc)(当双删除崩溃时?),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/3378759/