Re: std::function and shared object libraries

[Nick <nospam at codesniffer dot com>]

On Wed, 2015-06-17 at 09:35 +0100, Jonathan Wakely wrote:
> On 17 June 2015 at 00:42, Nick wrote:
> >
> > By "removed" I get the impression that it's somehow literally gone.  For
> > example, a 4GB address space is now 3GB.  The address space is still
> > there, it just contains undefined content which naturally will lead to
> > undefined behavior if accessed.
> 
> Maybe it's just another problem with terminology but I would say it's
> literally gone. After the dlclose() there is nothing mapped at the
> address stored in the function pointer f._M_manager. It's not just
> garbage memory that produces undefined behaviour, it is not even a
> valid address. Trying to access that address causes a segmentation
> fault, raised by the operating system, because that address is not
> part of the process' virtual address space.

Now I'm glad I asked.  I wasn't considering this aspect.  Thanks.

> >> >  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.
> >
> > Right, in the case of a basic C++ function template.  From the OP I was
> > thinking about something like std::function which I'd expect (though I
> > didn't look at the implementation) has some data along with it.
> 
> But the problem has nothing to do with that data. The data is in the
> program's stack or heap, which doesn't disappear when you dlclose()
> the shared library. What disappears is the code for the function that
> the object will invoke from its destructor.
> 
> This never had anything to do with memory allocation or where
> variables live in memory, only code.

Right, I get that the problem isn't related to the data.  I was using
this opportunity to understand/confirm the effects of this scenario on
memory.  I think it's clear to me now.  Thanks for explaining and
teaching.