Boost C++ Libraries: Ticket #10899: symbol visibility: cannot catch an exception thrown by boost::throw_exception on mac OS

attachment set

Fri, 26 Dec 2014 12:57:08 GMT

attachment → visibilibug.tgz

minimalistic example

Emil Dotchevski — Sat, 27 Dec 2014 21:18:16 GMT

I left my mac at the office so I can't run your test right now, but consider that on MSVC the types of exception objects are compared by a "strcmp" of the mangled names from their typeinfo. On GCC (probably on clang too) what's compared is the address of the typeinfos. That's why the visibility matters: when binaries are linked (dynamically or statically), unless two typeinfos get recognized as the same type by the linker, they won't match in a catch statement. Since each catch statement uses exactly one of the possibly many typeinfo objects that exist for the same type, depending on where the exception object originated, it might catch it -- or not.

Things are even more complicated when virtual inheritance is used in exception type hierarchies, which is of course a "best practice". In that case the catch lookup has to consider a whole list of typeinfos, and if even one of them is different, the exception won't get recognized.

P.S. I don't think that your problem has anything to do with the mechanics of boost::throw_exception, but if you feel otherwise you might try to edit that out of your test to verify that.

Mon, 02 Feb 2015 15:03:38 GMT

Hello Emil,

thank you very much for your answer (and sorry for the late reply).

Replying to emildotchevski:

consider that on MSVC the types of exception objects are compared by a "strcmp" of the mangled names from their typeinfo. On GCC (probably on clang too) what's compared is the address of the typeinfos.

See the link below, apparently GCC aligned with MSVC. I don't know about clang, and more specifically about clang on mac os.

http://stackoverflow.com/questions/14268736/symbol-visibility-exceptions-runtime-error

That's why the visibility matters: when binaries are linked (dynamically or statically), unless two typeinfos get recognized as the same type by the linker, they won't match in a catch statement. Since each catch statement uses exactly one of the possibly many typeinfo objects that exist for the same type, depending on where the exception object originated, it might catch it -- or not.

Ok, I have the same understanding of the issue, thank you for the confirmation.

P.S. I don't think that your problem has anything to do with the mechanics of boost::throw_exception, > but if you feel otherwise you might try to edit that out of your test to verify that.

As I explained in the bug report:

we tried to patch boost to make boost::exception_detail::error_info_injector<boost::property_tree::ptree_bad_path> visible, and it did fix the issue.

we also tried to patch boost to make boost::property_tree::ptree_bad_path hidden (removing #pragma GCC visibility push (default)) and it also did fix the issue.

As a consequence, I do think it is releated to the visibility of the templated classes boost::throw_exception is creating.