Re: Unloading providers (again)

Yes, as I wrote, it's glib2's 'feature' not to support dlclose(). I was
just wondering if there is anything I can do to work around it on
Pegasus side. It seems it's not, so please consider the problem as
'closed/wontfix' :).

I have another workarounds available, namely the provider can dlopen
glib2 so it won't be garbage collected when Pegasus unloads the provider.

Jan

On 10/27/2013 09:30 PM, Kirk Augustin wrote:
> 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
> 
> 
>