Re: std::function and shared object libraries

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 16 June 2015 at 01:21, Nick <nospam@codesniffer.com> 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.