Exceptions appear to be broken on EX-arm64-smp-gcc-pshm-opt w/GCC 9.1.0

Issue #404 wontfix
Dan Bonachea created an issue

Nightly CI results on cfarm config EX-arm64-smp-gcc-pshm-opt are showing a failure on the recently-enabled bad-alloc.cpp test that I cannot explain.

This test is validating that allocation failures generate a user-catchable exception:

    try {
      std::cout << "Making an absurd shared heap request..." << std::endl;
      upcxx::global_ptr<double> p = upcxx::new_array<double>((size_t)-4);
      std::cout << "ERROR: upcxx::new_array failed to throw exception!" << std::endl;
    } catch (std::bad_alloc const &e) {
      std::cout << "\nCaught exception: \n" << e.what() << std::endl;
    }

Observed behavior:

--- stdout ---
Making an absurd shared heap request...

--- stderr ---
terminate called after throwing an instance of 'upcxx::bad_shared_alloc'
  what():  upcxx::bad_shared_alloc: new_array(18446744073709551612) requested more bytes than can be represented by size_t!
*** Caught a fatal signal (proc 0): SIGABRT(6)

It looks like this particular C++ compiler config is calling std::terminate, bypassing the matching catch clause that should be invoked. Strangely, it doesn't happen in threadmode=seq or codemode=debug, which smells like a compiler bug or possibly a problem with the compiler installation.

Comments (6)

  1. Paul Hargrove
    • changed status to open

    In anticipation of this report, I built GCC 10.2.0 on the problematic system overnight.
    I will know in a few hours if the problem is reproducible with this compiler.

  2. Paul Hargrove

    With the provided GCC 9.1.0 build, I can reproduce the error with test-bad-alloc-par-opt-smp in 5 out of 5 trials.

    With a GCC 10.2.0 I've just built, 5 of 5 trials are error-free.
    make dev-check is also error-free (smp and udp).

    I agree with Dan's diagnosis of this as a compiler bug.
    Independent of how we want to resolve this issue, I am shifting our nightly tester on this system to use my GCC 10.2.0.

  3. Paul Hargrove

    I believe this issue should be resolved as "wontfix" based on the evidence that a sufficiently new GCC install on the same platform does not exhibit the reported mis-behavior.

  4. Log in to comment