Question

我有以下循环（当使用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默认的虚拟析构函数。

从这段代码中我了解到，对象的第一个DWORD指向一个vtable，而vtable中的第一个DWORD指向析构函数。它是否正确？每次我有虚拟析构函数时都会发生这种情况？
在什么条件下，这个析构函数的调用会在这个确切的行0x086f5371 <+61>: call DWORD PTR [eax]处导致信号11 seg错误？我的猜测是％eax指向的值位于某个未分配区域，但可能的原因是什么？此时我应该拥有SgApp类型的所有24个对象（它们是在构造函数中创建的）。

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

Answer 1

我将推测您没有关注rule of three并最终得到两个或多个指向同一动态分配数组的对象。当他们的析构函数被调用时，第二次调用会导致尝试delete []已经delete[]编辑的内容。

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

1 个答案: