Re: [Boost-bugs] [Boost C++ Libraries] #10899: symbol visibility: cannot catch an exception thrown by boost::throw_exception on mac OS

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #10899: symbol visibility: cannot catch an exception thrown by boost::throw_exception on mac OS
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2015-02-02 15:03:38


#10899: symbol visibility: cannot catch an exception thrown by
boost::throw_exception on mac OS
-------------------------------------------------+-------------------------
  Reporter: Sébastien Barthélémy | Owner:
  <barthelemy@…> | emildotchevski
      Type: Bugs | Status: new
 Milestone: To Be Determined | Component: exception
   Version: Boost 1.55.0 | Severity: Problem
Resolution: | Keywords:
-------------------------------------------------+-------------------------

Comment (by Sébastien Barthélémy <barthelemy@…>):

 Hello Emil,

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

 Replying to [comment:1 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.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/10899#comment:2>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:17 UTC