id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
4639	boost thread library leaks pthread_key	gleonid@…	viboes	"implementation on Linux of boost::thread_specific_ptr calls pthread_key_create, but never calls pthread_key_delete.

On RHEL 4.6 system pthread_key_create succeeds 1024 times in a row without calling pthread_key_delete. After that point pthread_key_create fails.

Basically there are 2 issues:
1. resource leak - boost thread should release acquired resource
2. When/if pthread_key_create fails - current (1.44.0) implementation completely ignores return code in release version.

I am attaching test case to illustrate/reproduce problem.

Debug version yields:
''attempt 512
boost_thread_test_deb.exe: libs/thread/src/pthread/once.cpp:32: void boost::detail::<unnamed>::create_epoch_tss_key(): Assertion `!pthread_key_create(&epoch_tss_key,delete_epoch_tss_data)' failed.
Aborted
''
While release version results in following:
''attempt 512
Segmentation fault''

Here is a brief explanation of why I need to dlopen/dlclose same shared object repeatedly:

I am working on apache's module and I am using boost::thread_specific_ptr in my module. I am linking with boost thread library statically.

In our organization apache is being gracefully restarted (apachectl graceful) every hour. During every restart my module is being unloaded (along with boost thread) and loaded back again. This usage scenario gives me 512 restarts/reloads, which translates to 21 days before it segfaults.

After closer examination I found out that even if do not boost::thread_specific_ptr use directly - I am still subject to this problem as boost::thread also uses it.
All of the above prevents me from using boost thread library in my project."	Bugs	closed	To Be Determined	thread	Boost 1.44.0	Problem	duplicate	pthread_key_create pthread_key_delete	viboes