On Tue, 2015-06-16 at 09:43 +0100, Jonathan Wakely wrote: > On 16 June 2015 at 01:21, Nick <nospam@xxxxxxxxxxxxxxx> wrote: > > I expect the application has a single memory space and so an *address* > > from one module is the same across the entire process. The main issue > > is which memory manager served it up. Am I wrong? > > Yes, you are wrong. > > There is a single address space, but when you unload a shared library > with dlclose() part of that address space disappears. Any pointers > into that part of the address space become invalid. Thanks for the follow-up. A few more questions and I think I'll have it straight. By "disappears" I assume you mean the contents of the space are gone, not that the actual address space is removed, correct? So in the case of the OP, that would amount to allocated objects (ex. function template) 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)? 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? > 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.
