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

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

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.

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