- changed status to open
Exceptions appear to be broken on EX-arm64-smp-gcc-pshm-opt w/GCC 9.1.0
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)
-
-
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. -
reporter - changed milestone to 2021.3.0 release
Mass roll-over of open issues to next release milestone
-
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.
-
reporter -
reporter - changed status to wontfix
This is pretty clearly a compiler bug which is fixed in the latest
- Log in to comment
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.