Greg Clayton wrote:
I have been using the boost::shared_ptr class to add large classes to STL containers as shared pointers. I use many DLLs that all share the same heap (they all use multi-threaded DLL runtimes), and shared_ptr's are passed between DLLs.
I am currently running into an issue where DLL "A" can build up a shared_ptr in a local variable, and hand ownership over to DLL "B" (which stores the shared pointer in a STL container). I get a crash when the STL container class in DLL B later destructs if DLL A has been unloaded. It seems all virtual functions in the vtable of the shared pointers are bogus at this point.
Yes, that's correct. A shared_ptr<X> remembers who created it (DLL A in this case) and attempts to destroy itself using DLL A. This is by design; DLL B may not be aware of the actual type of the shared_ptr, it may hold shared_ptr<void> or shared_ptr<A> (where A is an abstract base of X). It's even possible for X to not even exist outside DLL A. You need to make sure that DLL A is still in memory when DLL B destroys its shared_ptr.