信号11在析构函数调用中的可能原因是什么

What are the possible reasons for signal 11 on destructor call?

本文关键字：是什么 析构 函数调用 信号      更新时间：2023-10-16

我有以下循环（当使用delete[]删除24个SgApp类型对象的数组时，会发生这种情况）

   0x086f5361 <+45>:    cmp    ebx,DWORD PTR [esi+0x4]
   0x086f5364 <+48>:    je     0x86f5375 <PSM::~PSM()+65>
   0x086f5366 <+50>:    sub    ebx,0xd4
   0x086f536c <+56>:    mov    eax,DWORD PTR [ebx]
   0x086f536e <+58>:    mov    DWORD PTR [esp],ebx
=> 0x086f5371 <+61>:    call   DWORD PTR [eax]
   0x086f5373 <+63>:    jmp    0x86f5361 <PSM::~PSM()+45>

在这段代码中，%ebx的作用就像迭代器%esi指向数组的开头，sizeof（SgApp）=0xd4。在数组的开头，前4个字节表示数字24。0x086f5371 <+61>: call DWORD PTR [eax]行调用SgApp默认的虚拟析构函数。

  1. 从这段代码中，我了解到对象的第一个DWORD指向vtable，vtable中的第一个DWORD指向析构函数。这是正确的吗？每次我有一个虚拟析构函数时都会发生这种情况？

  2. 在什么条件下，析构函数的调用将导致信号11seg在这个确切的线路0x086f5371 <+61>: call DWORD PTR [eax]上发生故障？我的猜测是%eax所指的值在某个未分配的区域，但可能的原因是什么？在这一点上，我应该拥有所有24个SgApp类型的对象（它们是在构造函数中创建的）。

我提到这个信号11只发生过一次，我得到的只是一个糟糕的核心转储。在正常情况下，这是不可复制的，所以我正在寻找所有可能的解释，包括一些硬件故障或一些奇异的场景。

我推测您没有遵循三规则，最终会有两个或多个对象指向同一个动态分配的数组。当它们的析构函数被调用时，第二个调用会导致尝试delete []——已经是delete[]的东西。

相关文章：