Re: Unloading providers (again)

Hi Jan
Do you have any syslog msg at the time of error?
and which version of pegasus you are on?




On Mon, Oct 28, 2013 at 2:00 AM, Kirk Augustin <[email protected]>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
>
>
>
>


-- 
Warm Regards
--Dev
OpenPegasus Developer/Committer

(\__/)
(='.'=) This is Bunny. Copy and paste bunny
(")_(") to help him gain world domination.