...

...

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

On 4/25/2010 5:08 PM, Hartmut Kaiser wrote:

...

I'm sorry to say I recompiled everything against Boost trunk (rev. 61561), but the problem still persists. <snip>

Rolling things back now seems like the best strategy. Hartmut, can you rebuild your application against the release branch + the 1.42 version of serialization and let us know if that fixes the problem?

As it turned out the ball is in our court and the problem doesn't seem to be related to serialization (at least it's not a new problem in serialization introduced just recently, but I'll get back to that separately). Please go ahead with the release as planned. I feel foolish and embarrassed as I have raised a false alarm. I sincerely apologize for the noise and the false conclusions stating the serialization library was broken. Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

On Mon, Apr 26, 2010 at 5:09 PM, Eric Niebler <eric@boostpro.com> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 4/26/2010 11:57 AM, Hartmut Kaiser wrote:

...

.. I feel foolish and embarrassed as I have raised a false alarm. I sincerely apologize for the noise and the false conclusions stating the serialization library was broken.

There's no need for that. Raising the (potential) issue before the release went out was the right thing. Better safe than sorry.

I want to second Eric's reply. You did the right thing. Thanks also to Robert for responding promptly to what might have turned out to be a serious issue. --Beman