Purifyでg ++で例外をスローしてSIGABRTを引き起こす既知の問題はありますか？

Question

は実は、私の本当の問題は、次のコード（「SIGABRTが発生する」）で示された行に何か問題があります：

char* myFunc(char *param) { 
    char* leaked = new char[80]; // Intentionally leaked 
    if (param == NULL) throw logic_error("Parameter was null!"); // Causes SIGABRT 
    strcpy(leaked, param); 
    // Missing return, but never gets this far, so should be okay. 
} 

void test_non_happy_myFunc() 
{ 
    try { 
    myFunc(NULL); 
    } catch (logic_error&) { 
    cout << "Test succeeded!" << endl; 
    return; 
    } 

    cout << "Test FAILED!" << endl; 
} 

int main() 
{ 
    test_non_happy_myFunc(); 
} 

私はに送信する最小限のテストケースを思い付くしようとしていますIBM/Rationalがソフトウェアの精製に問題があることを証明するために、私はSO最初にコミュニティ。はい、私は故意に2行目にメモリをリークしています。はい、例外がスローされたときにポインタが「リークされました」がユニット化されていることがわかります。

上記のコードは、g ++でコンパイルすると通常はpurifyの外側で実行されますが、purifyの内部で実行されるとコアダンプが発生します。私は上記のコードで新人の間違いを犯しましたか（SIGABRTを私のせいにしました）、またはIBM/Rational Purifyで指を指すことができますか？

編集：（明確化）

Purifyのなしのコマンドラインで実行、上記の完全なプログラムを印刷：

COR: Fatal core dump 
This is occurring while in thread 1299: 
     _p450static [rtlib.o] 
     abort   [libc.so.6] 
     uw_init_context_1 [unwind-dw2.c:1256] 
     _Unwind_RaiseException [unwind.inc:88] 
     __cxa_throw [eh_throw.cc:78] 
     myFunc(char*) [exception_test.cc:9] 
     test_non_happy_myFunc() [exception_test.cc:17] 
     main   [exception_test.cc:28] 

：Purifyの内部

Test succeeded! 

ランは、レポートを浄化

前提条件を満たしていれば、9行目が私が指定した行になることに注意してください。

Answer 1

myFuncのreturn文がないことを除いて、私は上記のコードに間違いはありません。しかし、他者（特に広く使われているコード）によるコードに責任を負う前に、私はこの前に何も悪いことがないことを二重にチェックしたいと思います（UBデーモンを呼び出す何かが、目に見える効果）。

メインコードがちょうどtest_non_happy_myFuncであり、カスタムグローバルアロケータのような面白いものがない場合にのみ、私はあなたのツール（純度、コンパイラなど）に検索を移動します100％肯定的になる前に止めておいて問題がある。