1

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 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.

Ogre Psalm33
  • 21,366
  • 16
  • 74
  • 92
  • Could you tell us how you determined what line was failing? Also, I haven't used Purify in ages, so how do you compile and run inside Purify? Have you already created and tested a minimal version of the above (say, with a `main` function calling `test_non_happy_myFunc`), to eliminate all other possible problems in other code not seen here? – David Thornley Feb 02 '11 at 20:50
  • Thanks for the comment--I added clarifications above. Yes, I can indeed run the above program exactly as show (plus the includes for iostream, stdexcept, and string.h), linking no external libraries or other code, and get the results described. What you see is what you get. – Ogre Psalm33 Feb 03 '11 at 13:16
  • I forgot to mention. Purify is run by prepending "purify" to the link command on the cmd line or in your Makefile. It inserts hooks into your code during the link. Then when you run your app, by default it brings up a GUI window that accumulates a list of potential memory issues in your code as it runs (I think there may be an option to dump this to stdout or a file instead of launching a GUI). – Ogre Psalm33 Feb 04 '11 at 17:47
  • So did you ever find out what caused the core dump? Also, does that also happen even if you add the missing return statement in myFunc? – antred Oct 23 '14 at 08:57
  • 1
    @antred No, I believe I wound up solving my original issue using different tools instead. I don't even recall what version of purify I was using at the time, so I'm not sure if it's a version-specific issue. – Ogre Psalm33 Oct 23 '14 at 12:36
  • 1
    I did locate my original IBM purify forum post, in case the link is helpful to anyone: https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014582515 – Ogre Psalm33 Oct 23 '14 at 12:36

1 Answers1

1

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.

6502
  • 112,025
  • 15
  • 165
  • 265
  • That is actually precisely what I did. We kept narrowing down what was causing the crash until I had a simple test case that was a main() calling test_non_happy_myFunc(). Just as you see above. I'll add more explanation to my original post. – Ogre Psalm33 Feb 03 '11 at 13:06