id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
1154,tss destruction segfaults in conjunction with dlopen/dlclose,Zak Kipling <zak@…>,Anthony Williams,"The attached code (a main program that loads a ""plugin"" library with dlopen and calls a function therein, then unloads it with dlclose before exiting normally) works fine with Boost 1.33.1, but segfaults on exit with 1.34.1 (observed on x86_64 with Linux 2.6.20 / glibc 2.5 / gcc 4.1.2).

The segfault appears to occur because, in the new version, the boost::function objects wrapping the cleanup functions are all kept until there no longer any thread_specific_ptr objects of *any* type remaining.

Since the main program keeps a thread_specific_ptr across the dlopen/dlclose calls, and the ""plugin"" library created a thread_specific_ptr to a type that only exists within that library, the boost::function internals for the cleanup function on that local type are only instantiated within the library. Hence delaying its destruction until program exit (after the call to dlclose) leads to a segfault because the internals of this boost::function type have now been unloaded.

The attached Makefile should build the testcase, but you'll probably need to modify the top two lines (LDLIBS and CPPFLAGS) to point to your Boost headers and libraries.


I appreciate that this code has been reworked in order to reduce the use of (potentially limited) thread-local storage slots on the system -- is it possible to retain this while still having each instance of thread_specific_ptr manage and destroy its own cleanup function rather than deferring the destruction of all cleanup functions until program exit?
",Bugs,closed,To Be Determined,thread,Boost 1.34.1,Regression,fixed,,