On 16 June 2015 at 13:43, Nick wrote: > By "disappears" I assume you mean the contents of the space are gone, > not that the actual address space is removed, correct? I don't understand the distinction. What does "the actual address space is removed" mean? > So in the case > of the OP, that would amount to allocated objects (ex. function > template) Template instantiations are not allocated. They are code, not data. > as well as code from the shared object are potentially wiped > (but certainly invalid regardless) and therefore any access to them is > undefined. > > If that's all correct, and if the shared object and the main app are > using the same memory manager, then in the OP, isn't the function > template still around in memory (assuming it was allocated by the app's > mem mgr)? I'm not sure what you mean by "function template". Do you mean the variable of type "std::function<void()>"? That is not a template, it's an object. It's still around. > And so the problem is that the shared object's *code* is gone > and so the std::function dtor segfaults because it's trying to execute > code that's no longer in the address space? Correct. It's trying to execute an instantiation of a function template (in the basic C++ sense of the term, not the "std::function" sense, which coincidentally has the same name). That instantiation is a piece of code defined in the shared library. When the shared library is unloaded the code cannot be called. It's address no longer points to anything in the process' address space. >> Look at https://gcc.gnu.org/ml/gcc-help/2015-06/msg00079.html which >> demonstrates the same problem without touching the heap at all. > > Right, I think this is confirming one of my questions above.
