From: Scott (cheesy4poofs_at_[hidden])
Date: 2006-02-17 11:26:20
> My guess is that the DLL is getting unloaded "too soon". You
> might put a break point in the unload code of the DLL and see
> if that trips before the assertion. There have been problems
> with code explictly unloaded while the type is still "in use"
> in a non-obvious way.
>
> Robert Ramey
I'm really at a loss as to why this is happening. Here's the call stack:
NwNetworkD.dll!_onexit(int (void)* func=0x0012fa94) Line 81 + 0x2e
C
ffffffff()
boost_serialization-vc71-mt-gd-1_33_1.dll!0032aa2e()
NwNetworkD.dll!boost::archive::detail::interface_oarchive<boost::archive::te
xt_oarchive>::operator<<<nw::Manager::ManagerNode const >(const
nw::Manager::ManagerNode & t={...}) Line 78 + 0x4a C++
NwNetworkD.dll!nw::Manager::save(const
std::basic_string<char,std::char_traits<char>,std::allocator<char> > &
filename={...}) Line 236 C++
After calling my method "save", it walks a map and serializes my ManagerNode
classes. As you can see from the call stack, it then enters a function in
the serialization DLL.
>From there, something goes horribly wrong. What is ffffffff()? It seems
like a bad pointer is getting dereferenced or something. Then the very next
action is NwNetworkD.dll!_onexit(). I can tell you that our code is NOT
unloading that DLL. At the current time, our code is single threaded and
the DLL in question is not actually dynamically loaded/unloaded ever. It's
statically loaded by the runtime on application start (we just link against
the .lib for that DLL).
Scott