> I don't see any way to avoid this, you're taking a pointer to code > defined in the shared library, then unloading the shared library, then > using the code that was just unloaded. That's what I figured was happening. I do find it a bit strange that the function needs to be called at destruction. I've been looking through the source code for libstdc++ trying to figure out what's happening at a lower level, and I'm actually a bit more confused. In particular, I'm confused by the fact that _M_manager itself is causing the segfault. Looking at the library code, > Manager_type _M_manager; > ... > typedef bool (*_Manager_type)(_Any_data&, const _Any_data&, > _Manager_operation); _M_manager seems to be a function pointer to a specific type of management code. The segfault is happening because whatever _M_manager was, it was invalidated. It seems _M_manager is set somewhere deep in the code. From what I can tell, _M_manager is set to something in shared.cpp, some internal pointer defined by _Function_base::_M_manager. There is also some sort of inheritance going on, but at the end of the day the core of the handler function seems to be the one defined by _Function_base::_M_manager. Why is accessing this function causing a segfault? As far as I can trace with GDB my function is NOT being called at destruction, so it's not the one to blame for the segfault. Unless I'm misunderstanding something?
