次のループがあります (これは、タイプ SgApp の 24 個のオブジェクトの配列が delete[] で削除されたときに発生します)
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 がデストラクタを指していることがわかります。これは正しいです?これは、仮想デストラクタを使用するたびに発生しますか?
このデストラクタの呼び出しにより、この正確な行でシグナル 11 セグメント障害が発生するのはどのような状況
0x086f5371 <+61>: call DWORD PTR [eax]
ですか? 私の推測では、%eax が指す値は未割り当てゾーンにあると思われますが、これにはどのような理由が考えられますか? この時点で、タイプ SgApp の 24 個のオブジェクトすべてが必要です (それらはコンストラクターで作成されました)。
このシグナル 11 が発生したのは 1 回だけであり、お粗末なコア ダンプしか得られませんでした。通常の状況ではこれを再現することはできないため、ハードウェアの障害や風変わりなシナリオなど、考えられるすべての説明を探しています。