Frank Mori Hess wrote:
It seems to me reference-counting usage of the dll and unloading it only when the reference count reaches zero is a good solution. It's the same idea as using shared_ptr to destroy dynamically allocated objects rather than passing out plain old pointers and manually calling delete.
That would make sense, yes. Unfortunately, diving deeper into this, I find I'd misunderstood some of the details. The actual sequence appears to be more like this: 1. Before termination, code in the DLL calls disconnect() on its saved boost::signals2::connection. As we've seen, that doesn't actually clean up the stored slot object. 2. On program termination, the OS implicitly unloads the DLL prior to the executable image. 3. A static object in the main executable has a destructor that deletes the boost::signals2::signal object. 4. Destroying the (not yet cleaned) slot object destroys the underlying boost::function. 5. This calls boost::detail::function::basic_vtable1::clear(), which apparently tries to invoke code in the (now unloaded) DLL. As the original boost::bind() and connect() calls were made in DLL code, perhaps that method was inlined in that object file. Much of the above happens implicitly, in particular the unloading of the DLL relative to the main executable. What I'm trying to say is that I still believe there's a valid use case for forcing slot cleanup in some way.