Re: [boost] [exception] get_error_info with dynamic libraries

Subject: Re: [boost] [exception] get_error_info with dynamic libraries
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2011-09-19 17:49:45

On Mon, Sep 19, 2011 at 11:20 AM, Pavel Lebedev <cygnus_at_[hidden]> wrote:
> Hi, I believe there is a problem with boost::get_error_info
> when used to retrieve error info objects added to exceptions in a module (exe/dll)
> different from the one making the call to this function under MSVC++ 2010 SP1.
>
> The problem appears to be introduced in SVN revision 68792 with a
> fix for ticket #5178 that changed struct boost::exception_detail::type_info_
> from storing a reference to type info to a pointer in member type_.
> There's an assertion in function
> boost::exception_detail::error_info_impl_container::get
> that checks these members for equality which now does pointer comparison
> instead of calling std::type_info::operator== (for the case of enabled RTTI).
> This fails when used on error info added in the different module from the
> one trying to access it because each module gets its own copy of std::type_info
> object for the same type with different addresses, even though
> std::type_info::operator= does string comparison of class names and would
> have returned true, as it did before this change. Other compilers/platforms that
> don't provide process-unique type info objects are most likely affected too.
> The following patch appears to fix this problem for me by reverting to
> compiler-provided way of comparing type info objects.
>
> Index: info.hpp
> ===================================================================
> --- info.hpp    (revision 74465)
> +++ info.hpp    (working copy)
> @@ -97,7 +97,7 @@
>                     {
>                     shared_ptr<error_info_base> const & p = i->second;
>  #ifndef BOOST_NO_RTTI
> -                    BOOST_ASSERT( BOOST_EXCEPTION_DYNAMIC_TYPEID(*p).type_==ti.type_ );
> +                    BOOST_ASSERT( *BOOST_EXCEPTION_DYNAMIC_TYPEID(*p).type_==*ti.type_ );
>  #endif
>                     return p;
>                     }
>
> Is this fix correct?

Indeed this was a bug, thanks for reporting it. Your fix is correct,
I've committed it in trunk revision 74471.

It's worth noting that the bug is limited to this assert, that is, the
library was working correctly, only the assert was triggered
incorrectly under MSVC in the presence of DLLs.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode