3

newを呼び出すたびにコンパイラによって追加されるコードの一部からスローされる例外を追跡しています。これは標準の C++ newであり、ヒープからメモリを取得し、クラスのコンストラクターを呼び出す必要があります。

SH4プロセッサでGCC 2.95（または2.96は不明）でVxWorks 5.5.1を実行しています。SNiFF+ 4.1 パッチ 1 内でコンパイルされています。

C++ コードは次のようになります。

CBlocksFile* pBlockFile = new CBlocksFile(szHeaderFile, szDataFile);

また、生成されたアセンブラー コードには、newの呼び出しの後に終了/削除/スロー処理があります。このパターンは、 newへのすべての呼び出しに適用されるようです。

// call to "new"
c4d6000  d14d        mov.l      @(0x134,pc),r1 (= 0x0c06c1e0 = ___builtin_new)
c4d6002  410b        jsr        @r1
c4d6004  e414       (mov        #20,r4)
...
// compiler generates throw path address
c4d6022  d246        mov.l      @(0x118,pc),r2 (= 0x0c4d6034)
...
// and pushes it to the stack
c4d602c  1121        mov.l      r2,@(4,r1)
...
c4d6030  a002        bra        +4       (==> 0x0c4d6038 : GOOD_PATH)
...
// throw path (there is no visible jump to this address)
c4d6034  a088        bra        +272       (==> 0x0c4d6148 : THROW_PATH)
...
GOOD_PATH:
...
// call to constructor
c4d6058  d139        mov.l      @(0xe4,pc),r1 (= 0x0c4d1730 T ___Q211CBlocksFilePCcT1bUcl)
...
c4d6060  410b        jsr        @r1
...
// normal path
return

THROW_PATH:
...
// same pattern again, compiler generates terminate path address
c4d6164  d22f        mov.l      @(0xbc,pc),r2 (= 0x0c4d6172)
...
// and pushes it to the stack
c4d616a  1121        mov.l      r2,@(4,r1)
...
c4d616e  a002        bra        +4       (==> 0x0c4d6176 : NO_TERMINATE)
...
c4d6172  a039        bra        +114       (==> 0x0c4d61e8 : TERMINATE_A)
...
NO_TERMINATE:
...
// delete handling
if ( ?? )
c4d617c  2118        tst        r1,r1
c4d617e  8d04        bt/s       +8       (==> 0x0c4d618a)
...
{
    delete ??
...
c4d6184  d128        mov.l      @(0xa0,pc),r1 (= 0x0c06be20 = ___builtin_delete)
c4d6186  410b        jsr        @r1
...
}
c4d618a  9044        mov.w      @(0x88,pc),r0 (= 0x0000028c)
c4d618c  02ee        mov.l      @(r0,r14),r2
c4d618e  5121        mov.l      @(4,r2),r1
c4d6190  6112        mov.l      @r1,r1
c4d6192  1211        mov.l      r1,@(4,r2)
c4d6194  d125        mov.l      @(0x94,pc),r1 (= 0x0c06a880 = ___sjthrow)
c4d6196  410b        jsr        @r1

この切り取られたコードは何に役立ちますか? スローが新しい関数内にないため、メモリがない状態のようには見えません。

なぜスローが呼び出されるのですか？そして誰から？コード アドレスをスタックに置くこのパターンは 2 回あり、後で実行するために使用される可能性があります。

ありがとう

4

2 に答える 2

2

コンストラクターがスローした場合、オブジェクトのメモリを解放する必要があるのは c++ の要件であるため、このパターンが適用されると推測されます。そのため、コンストラクター内から例外がスローされた場合、新しく割り当てられたオブジェクトは削除されます。

オブジェクトのコンストラクターから何かを明示的にスローして、この回答が有用かどうかを確認するために実行するパスを確認することができます。

于 2010-12-22T09:36:51.710 に答える
0

問題が解決した後、私自身の質問に簡単に答えたいと思います。

呼び出されるかどうかを確認するために、新しい失敗ハンドラーを追加しました。そして、前述の例外がスローされる直前に呼び出されました。そのため、「メモリ不足状態」になり、数時間以内にメモリリークが発生しました。

VxWorksでは、メモリ不足状態の後に例外がスローされた場合に、スタックトレースに「new」関数呼び出しが表示されないようです。

DumpCoderとvillintehaspamのおかげで、私は正しい方向に考えさせられました。

于 2011-02-24T10:09:30.483 に答える