-
Notifications
You must be signed in to change notification settings - Fork 198
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
[BUG] Cannot catch RMM exceptions thrown across DSO boundaries #1652
Comments
See https://www.akkadia.org/drepper/dsohowto.pdf page 22 and https://gcc.gnu.org/wiki/Visibility for some discussion of the issue with exceptions |
Thanks for opening this. First, we should clarify what's meany by "for RMM". #1644 only changed the visibility of symbols for the Cython bits of the I've seen those resources you'd linked, but I was assuming that within the Python package, there wouldn't be cross-DSO throwing of anything not already marked for export via Cython's mechanisms. Could you share a reproducible example of a case that used to work and is now broken? Full disclosure, I did #1644 but this is way at the edge of my C++ understanding, so hopefully @robertmaynard will be able to help as well. |
libcudf |
It looks like the converstation we had #1644 wasn't sufficient ( #1644 (comment) ) . Types such as |
Fixes #1652 Authors: - Robert Maynard (https://github.com/robertmaynard) - James Lamb (https://github.com/jameslamb) - Lawrence Mitchell (https://github.com/wence-) Approvers: - James Lamb (https://github.com/jameslamb) - Mark Harris (https://github.com/harrism) URL: #1654
Describe the bug
Since #1644, the default symbol visibility for RMM is
hidden
.This is a good thing, however, the stick was applied a bit too aggressively.
In particular: exception classes need to have
default
visibility if we want to be able to catch an error thrown from DSO-A in DSO-B (otherwise the linker won't have disambiguated the names and the typeinfos will not compare equal).I'm also worried that we probably need to mark all public non-template classes as
RMM_EXPORT
as well, since again, the two classes will not be the same (though will at least be ABI compatible) when passed between DSOs.The text was updated successfully, but these errors were encountered: