Hi, I have debugged the problem for hours and found a partial solution. Don't know why this works and whether it finally will solve the problem but at least it is one step further. It seems that at least part of the problem is with pure virtual functions. If there is no implementation of a pure virtual function within the dynamic library that defines A and A the pure virtual function is defined in a base class of A, the serialization library crashes. Let's assume A has yet another base class "ABase": class ABase { protected: virtual void purevirtual() = 0; }; class A : public ABase { ... }; If neither A nor any other class between A and ABase in the inheritance hierarchy implements the function, dynamically loaded derived classes won't serialize. If the function is implemented, everything is fine. The funny thing is that if the pure virtual function is declared in A, serialization will also work. I have tried the following set-ups. P denotes a pure virtual function and V a virtual function that has a definition. N means no definition. Class B is defined in a dynamically loaded DLL. Arrows denote inheritance. The problem is in serializing B (* see note). Dynamic library boundary ________ | V A (P) -> B (V) ABase (P) -> A (V) -> B (V) ABase (P) -> ABase2 (P) -> A (V) -> B (V) ABase (P) -> ABase2 (V) -> A (N) -> B (V) These all work. If there is a definition for the virtual function or the inheritance hierarchy is only one level deep, serializing B works. The following set-ups cause a crash: ABase (P) -> A (P) -> B (V) ABase (P) -> ABase2 (P) -> A (P) -> B (V) I kind of hope this helps someone in debugging the problem. I'm still not too familiar with the internals of the serialization library... Oh, and I have tried BOOST_IS_ABSTRACT. It has no effect on my compiler (gcc 3.4.1). * In all the aforementined cases, serializing just B works fine. But once another similar class (say C) is fetched from another DLL, the library crashes as described in a previous posting. I also noticed that it isn't necessary to load both B and C from DLLs. The same problem occurs if B is in the main executable and C is in a DLL. The problem seems to be in crossing a dynamic library boundary in any way. -Topi- Robert Ramey wrote:
It looks to me that A.dll is being unloaded "too soon" or that A.dll is being loaded mulitple times. If you trap on the ctor / dtor code of extended_type_info you might be able to see what's going on.
If A.DLL is being loaded automatically on using B.DLL or C.DLL it may well be unloaded automatically "too" soon. Or they maybe multiple copies and the "wrong one" gets dropped from the global tables when one DLL is unloaded.
As I've said before - this is a murky area. I may experiment with if I can find the time but I need a good (complete self-contained) test case.
Robert Ramey