Re: [Boost-bugs] [Boost C++ Libraries] #3926: thread_specific_ptr + dlopen library causes a SIGSEGV.

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #3926: thread_specific_ptr + dlopen library causes a SIGSEGV.
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2010-06-07 19:29:54

#3926: thread_specific_ptr + dlopen library causes a SIGSEGV.
  Reporter: pluto@… | Owner: anthonyw
      Type: Bugs | Status: reopened
 Milestone: Boost 1.43.0 | Component: thread
   Version: Boost 1.42.0 | Severity: Problem
Resolution: | Keywords:
Changes (by pluto@…):

  * status: closed => reopened
  * resolution: wontfix =>


 Replying to [comment:1 anthonyw]:
> When you dlclose a library, you must ensure that no code references that
 library afterwards. If you have a live thread_specific_ptr with a
 destructor that belongs to that library then the library must be loaded
 when the destructor is called. You must therefore ensure that the
 thread_specific_ptr does not have a value on any thread when the library
 is unloaded.

 the thread_specific_ptr dtor called from dlclose() calls set_tss_data()
 with boost default cleanup function and *NULL* new_value. what's the point
 of deleting NULL pointer in cleanup function? this accidentally works in
 shared libs enviroment beacause the cleanup function exists in memory and
 'delete 0' is valid in c++. with dynamically loaded libs glibc tries to
 call useless cleanup callback from dl-unloaded code and ends with gpf.
 solution: the thread_specific_ptr dtor should delete current_value and
 call set_tss_data() in the same way as the release() does.

Ticket URL: <>
Boost C++ Libraries <>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:03 UTC