On 16 June 2015 at 01:21, Nick <nospam@xxxxxxxxxxxxxxx> wrote: > On Sat, 2015-06-13 at 20:48 +0100, Jonathan Wakely wrote: >> When you do "fun = shared" you instantiate a function template. >> >> The instantiation is in your shared library. >> >> The address of that instantiation is assigned to fun._M_manager >> >> When you unload the shared library that address becomes invalid. > > I've witnessed & experienced this type of issue a fair number of times > in the past, but mainly in Windows w/ VC++. So I'd like to confirm if > the same problem is happening here, because based on this last reply I > wonder if there's more that I don't understand. > > What I'm accustomed to seeing is that the main app + shared libraries > (regardless if they're manually/explicitly loaded or implicitly via the > loader) are built w/ a static runtime. When this is done, the app + > each library has its own separate heap as maintained by its own separate > memory manager, so cross-module allocations + deallocations don't work > (attempting to take memory from one allocator and return to another). That doesn't apply on unix-like systems, you don't get separate heaps for each shared object. > Is the same happening here? No. It's completely different. > Is this problem only present when linking > the runtime statically? No. > Or is there more to it such that even using the > shared runtime will cause this problem? It has nothing to do with the runtime. > I ask because this statement > suggests there's a slightly different constraint: > >> When you unload the shared library that address becomes invalid. > > 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. Look at https://gcc.gnu.org/ml/gcc-help/2015-06/msg00079.html which demonstrates the same problem without touching the heap at all.
