Ian*_*anH 6 c++ gcc probability postmortem-debugging delete-operator
请注意,我不想用我的问题解决任何问题 - 我正在考虑事情发生的可能性,因此想知道一些事情:
如果你删除对象并使用gcc作为编译器会发生什么?
上周我正在调查一次撞车事故,其中一场竞赛条件导致双重删除一个物体.
调用对象的虚析构函数时发生崩溃,因为已经覆盖了指向虚函数表的指针.
虚拟函数指针是否被第一次删除覆盖?
如果没有,那么第二次删除是否安全,只要在此期间没有进行新的内存分配?
我想知道为什么我之前没有识别出的问题,唯一的例外是虚拟功能表在第一次删除时立即被覆盖,或者第二次删除不会崩溃.
(第一个意味着如果发生"竞赛",崩溃总是发生在同一个位置 - 第二个,通常在竞赛发生时没有发生 - 并且只有在第三个线程覆盖删除对象的同时才会出现问题. )
编辑/更新:
我做了一个测试,下面的代码崩溃了一个segfault(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;
}
Run Code Online (Sandbox Code Playgroud)
如果我从dtor中删除'virtual',程序将被glibc中止,因为它检测到双重释放.使用'virtual'时,在对析构函数执行间接函数调用时会发生崩溃,因为指向虚函数表的指针无效.
在amd64和i686上,指针指向一个有效的内存区域(堆),但是那里的值是无效的(一个计数器?它非常低,例如0x11或0x21)所以'call'(或编译时为'jmp')做了返回优化)跳转到无效区域.
程序收到信号SIGSEGV,
分段故障.0x0000000000000021
在??? ()(gdb)
#0 0x0000000000000021?()
#main()中的1 0x000000000040083e
因此,在上述条件下,指向虚函数表的指针总是被第一次删除覆盖,因此如果该类具有虚拟析构函数,则下一次删除将跳转到必杀技.
小智 6
删除两次的东西是未定义的行为 - 你不需要任何进一步的解释,并且寻找一个通常没有用.它可能会导致程序崩溃,但可能不会,但这样做总是一件坏事,程序在完成之后将始终处于未知状态.
小智 6
它非常依赖于内存分配器本身的实现,更不用说任何依赖于应用程序的故障都会覆盖某些对象的v-table.有许多内存分配器方案,它们的功能和对double free()的抵抗力不同,但所有这些都共享一个共同的属性:你的应用程序将在第二个free()之后的某个时间崩溃.
崩溃的原因通常是内存分配器在每个分配的内存块之前(标题)和之后(页脚)专用少量内存来存储某些特定于实现的细节.标头通常定义块的大小和下一个块的地址.页脚通常指向块的标题.删除两次通常至少涉及检查相邻的块是否空闲.因此,如果:
1)指向下一个块的指针已被覆盖,第二个free()在尝试访问下一个块时导致segfault.
2)上一个块的页脚已被修改,并且访问前一个块的标题会导致段错误.
如果应用程序存活,则意味着free()在各个位置都有损坏的内存,或者会添加与已经空闲的块之一重叠的空闲块,从而导致将来数据损坏.最终,您的程序将在以下其中一个涉及损坏的内存区域的free()或malloc()中进行段错误.
| 归档时间: |
|
| 查看次数: |
1778 次 |
| 最近记录: |