Re: [Boost-users] [Serialization] Serializing classes defined in DLLs

From: Topi Mäenpää (topi.maenpaa_at_[hidden])
Date: 2005-09-23 07:39:23

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
>