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). Is the same happening here? Is this problem only present when linking the runtime statically? Or is there more to it such that even using the shared runtime will cause this problem? 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?
