Re: [pclasses-devel] example of dlclose() segfaults

[Christian P. <cp...@se...>]

Am Samstag 25 Dezember 2004 08:07 schrieb Christian Prochnow:
> Am Freitag 24 Dezember 2004 23:59 schrieb stephan beal:
> > No, i didn't do this on purpose: while testing the plugins layer i found
> > a very simple case where dlclose() causes a problem:
> >
> > i just tried out the libdl impl of SharedLib on an arbitrary test. At
> > shutdown i delete the SharedLib objects, which causes dlcose() to be
> > called in the dtor:
> >
> > #0  0x4001272b in strlen () from /lib/ld-linux.so.2
> > #1  0x4000ce20 in _dl_signal_error () from /lib/ld-linux.so.2
> > #2  0x40331947 in _dl_close () from /lib/tls/libc.so.6
> > #3  0x40370d1a in dlclose_doit () from /lib/libdl.so.2
> > #4  0x4000cd56 in _dl_catch_error () from /lib/ld-linux.so.2
> > #5  0x40371085 in _dlerror_run () from /lib/libdl.so.2
> > #6  0x40370cf0 in dlclose () from /lib/libdl.so.2
> > #7  0x400398eb in ~SharedLib (this=0x8053c60) at SharedLib.dl.cpp:77
> > #8  0x0804c9d8 in ~PluginCleaner (this=0x8051ec4) at Plugin.h:43
> > #9  0x0804ea7c in ~PluginManager (this=0x8051ec0) at Plugin.h:106
> > #10 0x0804d8cf in ~Phoenix (this=0x8051ec0) at Phoenix.h:196
> > #11 0x0804bce5 in __tcf_1 () at Phoenix.h:161
> > #12 0x40271820 in exit () from /lib/tls/libc.so.6
> > #13 0x4025cb1a in __libc_start_main () from /lib/tls/libc.so.6
> > #14 0x0804a1f1 in _start () at start.S:119
> >
> > The libltdl-based SharedLib does not do a dlcose, and does not exhibit
> > this behaviour. Also, taking out the dlclose() causes the segfault to
> > go away.
> >
> > If i put the dlclose() back in, i get segfaults again.
>
> It's OK for me to not close shared libraries upon destruction. However, if
> we do so, we should cache and re-use sharedlib handles. Simply not closing
> the handle is not an option.
>
> I've added a SharedLibCache to dl, shl and win32 implementations. Please
> have a look at it.

For the ltdl impl to work we have to templatize the handle type in the 
SharedLibCache class as well.

> > Quasi-related:
> >
> > In the SharedLib ctors i have REMOVED the part which automatically adds
> > ".so". It took me 1/2 hour to figure out why SharedLib kept throwing
> > when i passed it a valid file name, and that was why. This convention
> > doesn't belong in SharedLib, because it is possible to use shared libs
> > with any extension. e.g., in one project i worked on we compiled
> > mini-libs into *.gcom. The plugin layer can put these extensions on
> > them - and will if they are needed - there is no reason to do this in
> > SharedLib ctor.
>
> Agreed.
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> pclasses-devel mailing list
> pcl...@li...
> https://lists.sourceforge.net/lists/listinfo/pclasses-devel