Subject: Re: [Boost-bugs] [Boost C++ Libraries] #3014: Assertion on unregistering of extended_type_info
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2009-05-31 14:33:41
#3014: Assertion on unregistering of extended_type_info
-----------------------------------+----------------------------------------
Reporter: mazay0_at_[hidden] | Owner: ramey
Type: Bugs | Status: reopened
Milestone: Boost 1.39.0 | Component: serialization
Version: Boost Release Branch | Severity: Problem
Resolution: | Keywords:
-----------------------------------+----------------------------------------
Changes (by Mazay0_at_[hidden]):
* status: closed => reopened
* resolution: worksforme =>
Comment:
Replying to [comment:6 ramey]:
> I've built and tested this minimal example on my VC 7.1 system and it
compiles, links and runs without error.
I have traced the exmaple on VC 7.1. It runs without errors because
singleton<detail::ktmap> dies between destructions of extented_type_info
instances for Foo and Bar classes (after Bar, before Foo). Therefore, the
check if(! singleton<detail::ktmap>::is_destroyed()) in
extended_type_info::key_unregister() saves the program from attempt to do
something with ktmap, which contains "invalid" extented_type_info
instance.
AFAIU in this case destruction order is undefined. Hence I suppose that
this is UB.
Is it safe to try to avoid multiple insertion of the same
extended_type_info instances in ktmap? It seems that m_key value can be
used as an indicator if this extended_type_info is registered in ktmap. It
is used in this manner in ~extended_type_info(). May be we can do the
similar check in key_register()?
{{{
BOOST_SERIALIZATION_DECL(void)
extended_type_info::key_register(const char *key) {
assert(NULL != key);
if (m_key == NULL) {
m_key = key;
singleton<detail::ktmap>::get_mutable_instance().insert(this);
}
}
}}}
-- Ticket URL: <https://svn.boost.org/trac/boost/ticket/3014#comment:7> 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:00 UTC