Regression: Julia 1.9.0 on MacOS: Dynamic library catching std::exception does not catch std::domain_error

[WardBrian]

Given the following C++ file:

// file dummy.cpp
#include <stdexcept>
#include <iostream>

void maybe_throw(int should_throw) {
  if (should_throw)
    throw std::domain_error("exception in C++: dummy");
}

extern "C" int some_fn(int should_throw) {
  try {
    maybe_throw(should_throw);
  } catch (const std::exception& e) {
    std::cerr << e.what() << '\n';
    return 1;
  }
  return 0;
}

And this Julia file:

run(`g++ dummy.cpp -shared -fPIC -o dummy.so`)

dummy = Libc.Libdl.dlopen("./dummy.so")

println(ccall(Libc.Libdl.dlsym(dummy, "some_fn"), Cint, (Cint,), 0))
println(ccall(Libc.Libdl.dlsym(dummy, "some_fn"), Cint, (Cint,), 1))

The expected output of julia dummy.jl is

0
exception in C++: dummy
1

However, the actual output with Julia 1.9 on MacOS is:

0
libc++abi: terminating due to uncaught exception of type std::domain_error
[traceback]

Julia versionInfo():

Julia Version 1.9.0
Commit 8e630552924 (2023-05-07 11:25 UTC)
Platform Info:
  OS: macOS (x86_64-apple-darwin22.4.0)
  CPU: 8 × Intel(R) Core(TM) i7-8559U CPU @ 2.70GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-14.0.6 (ORCJIT, skylake)
  Threads: 1 on 8 virtual cores

This is not an issue for earlier Julia versions (1.6 - 1.8) or on Ubuntu or Windows

[WardBrian]

Note: this is not actually std::domain_error specific, it seems that any built in exception which inherits from std::exception will fail in this way.

Additionally, I should note that catch (...) { /* */} does still work, but obviously this is quite bad behavior either way.

[vtjnash]

If we link against our copy of libstdc++.6.dylib, the problem reverses itself with clang++ dummy49772.cpp -shared -fPIC -o dummy49772.dylib -g ../usr/lib/libstdc++.6.dylib. The difference seems to be where this symbol is assumed to be located. In our copy, exceptions live in libstdc++, but in the system libraries, they are in libc++ instead. This is a bit confusing, as we compile our libraries with -stdlib=libc++ (which is also our platform default), so it seems incorrect that we are injecting a library that should not be present (libstdc++ is GNU, libc++ is clang/Apple) into our runtime.

dlopen(./dummy49772.dylib, 0x0001): Symbol not found: __ZNSt11logic_errorC2EPKc
  Referenced from: <673FBD62-2FD5-358E-B4DD-74BCDB864049> /Users/jameson/julia/zipyard/dummy49772.dylib
  Expected in:     <C473C61C-2FFF-3171-BD7A-1C0A3B03B3B6> /usr/lib/libstdc++.6.dylib

$ grep -RI __ZTISt12domain_error
./libc++.1.tbd:    weak-symbols:    [ __ZTISt11range_error, __ZTISt12domain_error, __ZTISt12length_error, 
./libc++abi.tbd:    weak-symbols:    [ __ZTISt11range_error, __ZTISt12domain_error, __ZTISt12length_error, 

[gbaraldi]

On 1.9 we started loading CSL by default, you can reproduce this failure in 1.8 by doing using CompilerSupportLibraries before running the code. The bigger issue is why do we load libstdc++ when loading the CSL.

[WardBrian]

It does appear #49842 fixed this, at least for the case I originally found this in.

[WardBrian]

This issue appears to be resolved by 1.9.1