Re: [boost] [1.43][Serialization] Serialization library serioslybroken

Subject: Re: [boost] [1.43][Serialization] Serialization library serioslybroken
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2010-04-26 07:30:41

> >> You might want to check the change I made as well.  The assert exists
> >> in 1.42 - the only difference in the file - void_cast.cpp is a small
> >> change I made to fix a memory leak.  I'm not confident that my fix
> >> actually fixed it - but of course everything passes here.
> >
> > I'm sorry to say I recompiled everything against Boost trunk (rev.
> > 61561), but the problem still persists.
> >
> > I don't understand what's going on, but I doubt it's a problem
> > directly in void_cast.cpp. For some reason the type I described gets
> > registered more than once (definitely from different modules, although
> > dynamically loaded, none gets unloaded before the assertion). Did you
> > change anything related to auto-type registration?
> 
> There are two collections.
> 
> One is for serialized types.  There is one entry per type per execution
> module.
> That is, in the presence of DLLS, there might be more than one entry for a
> given type.
> 
> The other is for functions which cast pointers between base and derived
> classes.
> It is keyed on the entries above.  The assertion is tripped on this latter
table.

Ok, I understand.
 
> I've checked all the differences between 1.42 and 1.43 and can't see any
> other than those in void_cast.cpp which would explain this behavior.
> Does rolling back void_cast.cpp to 1.42 fix the problem?

I will try that today.

> Also I would be curious to know more about the aplication.  (also compiler
> etc.)

I'm sorry, I should have mentioned this earlier. The application dynamically
loads (and unloads) modules containing code of mostly polymorphic objects
serialized through smart pointers. We see the problem both, on Windows using
vc10 (I did not try with other compilers here) and different Linux systems
using various versions of gcc. 

> Does the application dynamically unload DLLS and continue to execute?

As I said, no module is unloaded before the assertion trips. We see the
issue right at application startup.

> Is it possible to make a small example?

I'm not sure, but I can try.

I'm not sure if this is important, the assertion gets tripped by a symbol
related to smart pointer serialization (see my code example in the initial
mail).

Regards Hartmut

---------------
Meet me at BoostCon
www.boostcon.com