On 16 June 2015 at 14:01, johnsfine wrote:
> On Tue, 2015-06-16 at 09:43 +0100, Jonathan Wakely wrote:
>> So in the case of the OP, that would amount to allocated objects
>> (ex. function template)
N.B. I didn't write this, Nick did. You've misattributed the quote.
> I'm pretty sure that is NOT the case. The relevant chunk of memory was created at compile time within a module that was part of the .so file. It is code that was loaded and unloaded as part of that .so file.
>
> The run-time allocated object is not lost by unloading the .so file.
>
>> isn't the function template still around in memory (assuming it was
>> allocated by the app's mem mgr)?
>
> That is the wrong assumption. The template is instantiated at compile time within the compilation of a module in the .so, not at run time.
>
> An object of a templated type might be allocated at run time in the single heap shared by both the main module and the .so. But the type itself is instantiated at compile time and ends up being in one place or the other (main image or .so) depending on exactly how things are coded.
Right. I think Nick is confusing "instantiation of a function
template" (i.e. code generated from a C++ function template) with
"object of type std::function<void()>".
>> 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?
>
> Not exactly. That dtor itself (not just things it might call) is code in the shared object.
That's misleading.
The std::function::<void()>::~function dtor is also in the main
executable (it's instantiated from a template, so it's in a comdat
section). The dtor itself can run fine, the problem is that it calls
the function pointed to by the _M_manager member, and that refers to
code in the shared library.
You can prove this is true because the destructor runs OK if you do
"fun = nullptr" or "fun = {}" before unloading the shared library,
because in that case when the destructor runs (after the shared
library is unloaded) _M_manager is null and so there is no call to
unloaded code.
