[Boost-bugs] [Boost C++ Libraries] #1154: tss destruction segfaults in conjunction with dlopen/dlclose

Subject: [Boost-bugs] [Boost C++ Libraries] #1154: tss destruction segfaults in conjunction with dlopen/dlclose
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2007-08-09 12:23:52


#1154: tss destruction segfaults in conjunction with dlopen/dlclose
-----------------------------------------------+----------------------------
 Reporter: Zak Kipling <zak_at_[hidden]> | Owner: anthonyw
     Type: Bugs | Status: new
Milestone: To Be Determined | Component: thread
  Version: Boost 1.34.1 | Severity: Regression
 Keywords: |
-----------------------------------------------+----------------------------
 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?

--
Ticket URL: <http://svn.boost.org/trac/boost/ticket/1154>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.


This archive was generated by hypermail 2.1.7 : 2017-02-16 18:49:56 UTC