Re: Unloading providers (again)

As you have mentioned, threads should exit first and followed by dlclose().
I was under the impression that's the design we used. Need to check again
on this.

Are the threads in provider exited cleanly within the stipulated time of
`shutDowntimeout`.
It might also be possible that it was not exiting and server wrote an entry
in the syslog, and dlclose() pitched in


On Thu, Oct 31, 2013 at 1:49 PM, Jan Safranek <[email protected]> wrote:

> 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
> >
> >
> >
>
>


-- 
Warm Regards
--Dev
OpenPegasus Developer/Committer

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