Re: Unloading providers (again)

I believe the bug would have to be in glib2 if it would rely on thread local storage destructor callbacks.
But more likely is that elements added to glib2 data structures by the provider, were just not properly released first by the provider, before the provider shut down.

You can't expect the library that provides data structures to implicitly delete the objects you add to the data structures.

 
Kirk Augustin
11821 NW McNamee Rd
Portland, OR 97231


HM: 503-289-4356



On Thursday, October 24, 2013 7:38 AM, Jan Safranek <[email protected]> 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
>
>
>
>