Is there a known issue with throwing exceptions in g++ with Purify causing SIGABRT?

Actually, my real question is: is there anything wrong with the indicated line in the following code ("Causes 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();
}

I'm trying to come up with a minimal test case to send to IBM/Rational to prove that there's an issue with their purify software, so I'm running it by the S.O. community first. Yes, I'm intentionally leaking memory on the 2nd line, and yes, I know the pointer "leaked" is unitialized when the 开发者_Go百科exception is thrown.

The above code runs normally outside of purify when compiled with g++, but causes a core dump when run inside of purify. Did I make a rookie mistake in the above code (making the SIGABRT my fault), or can I point the finger at IBM/Rational Purify?

Edit: (clarifications)

Run on the command line without purify, the above complete program prints:

Test succeeded!

Run inside of purify, purify reports:

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]

Note that after prerequisite includes and such, line 9 winds up being the line I indicated.

Except for the missing return statement in myFunc I don't see anything wrong in the above code. Before however putting the blame on code by others (especially widely used code) I'd double check that nothing bad happened BEFORE this (as you know if something summoned UB daemons one million executed instructions ago may still be possible that only now there will be visible effects).

Only if compiling just the shown code with main just calling test_non_happy_myFunc and without fancy stuff like custom global allocators still shows the problem then I'd move the search to your tools (i.e. purity, compiler, etc.) and I wouldn't stop before being 100% positive the problem is there.