-
Notifications
You must be signed in to change notification settings - Fork 2.2k
[BUG] register_exception_translator have different behaviour when building with different STL. #2847
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I also verified that simply combing the default Python (libstdc++) and a binding built with libc++ works fine. So this seems not a compatibility issue between different STL. Thus I wonder what's the expected behavior here. |
You're using gcc to include libc++ and then aren't linking the standard library at all? At least when compiling |
Specifically, what exactly are you trying to accomplish? There's weird things going on with standard libs, so I can't see how pybind11 would be to blame. By playing around with things, you probably just ended up with 2 different types? |
Thanks for your reply!
That's really a very good point. I didn't try it and it turns out to have no differrence: clang++ and -stdlib=libc++
clang++ -I/usr/include/pybind11/ -I/usr/include/python2.7 \
-stdlib=libc++ \
-fPIC -fvisibility=hidden -flto -fno-fat-lto-objects -std=gnu++11 \
-o bar.o -c bar.cc
clang++ -fPIC \
-stdlib=libc++ \
-flto -shared \
-o bar.so bar.o
clang++ -I/usr/include/pybind11/ -I/usr/include/python2.7 \
-stdlib=libc++ \
-fPIC -fvisibility=hidden -flto -fno-fat-lto-objects -std=gnu++11 \
-o _foo.o -c foo.cc
clang++ -fPIC \
-stdlib=libc++ \
-flto -shared \
-o _foo.so _foo.o
python -c "import foo; foo.bar.thr()" || true
clang++ -I/usr/include/pybind11/ -I/usr/include/python2.7 \
-fPIC -fvisibility=hidden -flto -fno-fat-lto-objects -std=gnu++11 \
-o bar.o -c bar.cc
clang++ -fPIC \
-flto -shared \
-o bar.so bar.o
clang++ -I/usr/include/pybind11/ -I/usr/include/python2.7 \
-fPIC -fvisibility=hidden -flto -fno-fat-lto-objects -std=gnu++11 \
-o _foo.o -c foo.cc
clang++ -fPIC \
-flto -shared \
-o _foo.so _foo.o
python -c "import foo; foo.bar.thr()" || true still gives (warning omitted)
I'm not trying to blame pybind11 at all. |
Okay, I can repro with just But then, when |
Oh, that rings a bell. Could this be related to pybind11 explicitly taking the stdlib into account for the internals ABI version? pybind11/include/pybind11/detail/internals.h Lines 186 to 194 in fe84587
|
Okay... I don't get this at all. py::register_exception_translator([](std::exception_ptr p) {
puts("called");
try {
puts(p?"has exception":"no exception");
puts("Name of struct e:");
puts(typeid(struct e).name());
if (p) std::rethrow_exception(p);
} catch (const e &_e) {
puts("caught e");
PyErr_SetString(PyExc_KeyError, _e.what());
} catch (const std::exception& ee) {
puts("caught something");
puts("Name of something:");
puts(typeid(ee).name());
throw;
}
}); As you might expect (but probably not), the output of
|
But I'm compiling both modules with libc++... |
Could it be the ABI mismatch between modules and Python interpreter? |
Not likely? CPython doesn't link against any C++ library. I also tried to do something like this: /// foo.cpp
void catch_e(std::exception_ptr p) {
try {
if(p) std::rethrow_exception(p);
} catch(const e& e) {
puts("e");
} catch(const std::exception&) {
puts("not e");
}
}
/// bar.cpp
auto throw_e() {
throw e("");
}
/// main.cpp
int main() {
std::exception_ptr e;
try {
throw_e();
} catch(...) {
e = std::current_exception();
}
catch_e(e);
} With |
I confirm that's also the case on macOS, so seems related to libc++. |
The issue may be caused by the way libc++ handles hidden visibility and type_info. With See this Maybe try add struct __attribute__((visibility("default"))) e : public std::runtime_error { |
Issue description
If I have a module
a
who have an exception translator and moduleb
who throws an exception,and import
a
,b
in order in another python module.With libstdc++, when
b
throws an error, it will be catched by the registered translator,while with libc++, it won't.
Output1:
Output2:
See below for detailed information.
Reproducible example code
This repro requires additional dependencies. I recommend you run it from a docker container (
debian:buster
has been verified to work).Install dependencies
Generate test files
Build and run
The text was updated successfully, but these errors were encountered: