Boost C++ Libraries: Ticket #4639: boost thread library leaks pthread_key

attachment set

Wed, 08 Sep 2010 21:14:17 GMT

attachment → tss_test_case.tar.gz

owner, status changed; cc set

viboes — Sun, 04 Dec 2011 17:08:49 GMT

cc viboes added
owner changed from Anthony Williams to viboes
status new → assigned

When the pthread_key_delete should be called? At exit?

anonymous — Sun, 04 Dec 2011 20:05:59 GMT

If I am not mistaken, pthread_key_create is called from 2 places:

pthread_key_create(&epoch_tss_key...
pthread_key_create(&current_thread_tls_key, ... )

(at the moment I am looking at code from 1.48.0 release)

I guess that for both keys appropriate point to call pthread_key_delete would be at moment when boost thread library is being unloaded (or process is being terminated).

viboes — Fri, 09 Dec 2011 17:50:17 GMT

I'm not aware of library load/unload interfaces.

In another ticket, someone has proposed to use attribute(destructor) or something like that when using gcc. How can a function be called when the library is unloaded with other compilers? Could you give me a pointer or better yet, could you prepare a patch? Which compiler are you using?

anonymous — Fri, 09 Dec 2011 19:07:19 GMT

if you have a global object, which has a dtor. that dtor will get called when module is unloaded, regardless of a compiler.

viboes — Sun, 11 Dec 2011 01:47:57 GMT

Do you mean something like adding this to once.cpp

  namespace
  {
    const pthread_once_t pthread_once_init_value=PTHREAD_ONCE_INIT;
    struct BOOST_THREAD_DECL delete_epoch_tss_key_on_dlclose_t
    {
      ~delete_epoch_tss_key_on_dlclose_t()
      {
        if(memcmp(&epoch_tss_key_flag, &pthread_once_init_value, sizeof(pthread_once_t)))
        {
          pthread_key_delete(epoch_tss_key);
        }
      }
    };
    delete_epoch_tss_key_on_dlclose_t delete_epoch_tss_key_on_dlclose;
  }

status changed; resolution set

viboes — Sun, 11 Dec 2011 02:06:45 GMT

status assigned → closed
resolution → duplicate

Even if the problem doesn't manifest in the same way, it seems the solution should be be same. Duplicate of #3926 thread_specific_ptr + dlopen library causes a SIGSEGV.