[pclasses-devel] example of dlclose() segfaults

[stephan b. <st...@s1...>]

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. 

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.


-- 
----- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts