Re: [Boost-bugs] [Boost C++ Libraries] #3014: Assertion on unregistering of extended_type_info

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 =>


 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
 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()?

 extended_type_info::key_register(const char *key) {
     assert(NULL != key);
         if (m_key == NULL) {
         m_key = key;

Ticket URL: <>
Boost C++ Libraries <>
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