Re: Unloading providers (again)

The only generic soluton I know is to destroy the thread pool first and
dlclose() providers after that. Looking at ProviderAgent.cpp, it looks
like lot of work since one ProviderAgent.cpp may handle multiple
providers and they can be unloaded dynamically, not only at cimprovgt
shutdown, right? (Note that OpenLMI uses only one provider per
cimprovagt process so it might be a bit easier in our case).


You are correct that the providers will be dynamically loaded and unloaded
from the agent, just as they would be if the providers are unloaded from
the server itself.

Is there a way to force the agent to get all the callbacks set at its startup
and would that same instance of libglib2 be used by is dlopened providers?

If that were the case, then would not the cleanup callbacks be within the
provagt threads, not the provider threads.

I do not know, just asking at this point.

Karl



On 10/24/2013 08:48 AM, Jan Safranek wrote:
> Hi,
>
> I've stumbled upon strange crashes when onloading OpenLMI providers:
>
> 1. at startup, cimprovagt:
>    1.1 creates a thread pool
>    1.2 dlopens our provider
>       1.2.1 the dlopen() loads all dependencies, libglib-2.0 among others
>
> 2. the provider servers various CIM methods
>    2.1 as we use libglib2, it registers some cleanup functions as thread
> local storage destructors (see man pthread_key_create).
>
> 3. at cimprovagt shutdown:
>    3.1 cimprovagt dlcloses our provider
>       3.1.1  which unloads libglib-2.0
>    3.2 cimprovagt closes all threads in its threadpool
>      3.2.1 thread local storage destructor callbacks are called, but
> libglib2 is already unloaded from memory -> SIGSEGV
>
> Now, is there a way how to fix it?
>
> It's not possible to un-register the glib2 callbacks - the local storage
> destructors must be removed from the thread which registered them and
> only cimprovagt has access to the threads.
>
> The only generic soluton I know is to destroy the thread pool first and
> dlclose() providers after that. Looking at ProviderAgent.cpp, it looks
> like lot of work since one ProviderAgent.cpp may handle multiple
> providers and they can be unloaded dynamically, not only at cimprovgt
> shutdown, right? (Note that OpenLMI uses only one provider per
> cimprovagt process so it might be a bit easier in our case).
>
> Any other idea?
>
> Of course, I can try to prevent libglib from being unloaded on dlclose()
> using some dirty hacks in our provider. But that's just a workaround.
>
>
> Jan
>
>