This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: std::function and shared object libraries
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Nick <nospam at codesniffer dot com>
- Cc: Gabriel Marcano <gabemarcano at yahoo dot com>, "gcc-help at gcc dot gnu dot org" <gcc-help at gcc dot gnu dot org>
- Date: Tue, 16 Jun 2015 14:06:44 +0100
- Subject: Re: std::function and shared object libraries
- Authentication-results: sourceware.org; auth=none
- References: <CAH6eHdSn3gTWmAK-YDg90SqeoAUzuhDQFXv_bx5aOEQp0oiFiA at mail dot gmail dot com> <1638947916 dot 2267157 dot 1434207657547 dot JavaMail dot yahoo at mail dot yahoo dot com> <CAH6eHdSPa5=yEyGJi83TcK805y93cir5qF_6YRDZno6xCmx-xw at mail dot gmail dot com> <1434414075 dot 3436 dot 8 dot camel at nimble dot 325Bayport> <CAH6eHdQHCeuHPmspy9gnQPf7bdPiystE0maJFx2mFKc2Xh9qoA at mail dot gmail dot com> <1434458621 dot 3436 dot 24 dot camel at nimble dot 325Bayport>
On 16 June 2015 at 13:43, Nick wrote:
> By "disappears" I assume you mean the contents of the space are gone,
> not that the actual address space is removed, correct?
I don't understand the distinction. What does "the actual address
space is removed" mean?
> 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.
> 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)?
I'm not sure what you mean by "function template". Do you mean the
variable of type "std::function<void()>"? That is not a template, it's
an object. It's still around.
> 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?
Correct.
It's trying to execute an instantiation of a function template (in the
basic C++ sense of the term, not the "std::function" sense, which
coincidentally has the same name). That instantiation is a piece of
code defined in the shared library. When the shared library is
unloaded the code cannot be called. It's address no longer points to
anything in the process' 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.