id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
4885	Access violation in set_tss_data at process exit due to invalid assumption about TlsAlloc	Chris Newbold	viboes	"We've recently upgraded to Boost 1.44 and have started seeing Access Violations from set_tss_data during process exit under various conditions. We are building with Visual Studio 2008 and are seeing the problems on both 32- and 64-bit architectures.

Here's an example stack trace from a crash:
{{{
	boost_thread-vc90-mt-1_44.dll!boost::detail::heap_new_impl<boost::detail::tss_data_node,void const * __ptr64 & __ptr64,boost::shared_ptr<boost::detail::tss_cleanup_function> & __ptr64,void * __ptr64 & __ptr64,boost::detail::tss_data_node * __ptr64 & __ptr64>(const void * & a1=, boost::shared_ptr<boost::detail::tss_cleanup_function> & a2={...}, void * & a3=0x00000000003a6c40, boost::detail::tss_data_node * & a4=0x9b0d8d481675c085)  Line 208 + 0x20 bytes	C++
 	boost_thread-vc90-mt-1_44.dll!boost::detail::set_tss_data(const void * key=0x000000005d009600, boost::shared_ptr<boost::detail::tss_cleanup_function> * func=0x00000000001efc28, void * tss_data=0x0000000000000000, bool cleanup_existing=true)  Line 590	C++
 	libut.dll!`anonymous namespace'::`dynamic atexit destructor for 'ticTocPrevTotalsVector''()  + 0x38 bytes	C++
>	libut.dll!_CRT_INIT(void * hDllHandle=0x0000000000000001, unsigned long dwReason=0, void * lpreserved=0x0000000000000000)  Line 449	C
 	libut.dll!__DllMainCRTStartup(void * hDllHandle=0x000000000038f180, unsigned long dwReason=3757760, void * lpreserved=0x000000005cfa6b48)  Line 560 + 0xd bytes	C
 	ntdll.dll!0000000077b33801() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
 	ntdll.dll!0000000077b33610() 	
 	msvcr90.dll!00000000660a1b8b() 	
 	test_manager.dll!runTests(int argc=1, char * * argv=0x00000000006a6890)  Line 768 + 0x8 bytes	C++
 	pkgtest.exe!main(int argc=0, char * * argv=0x0000024d06b13a83)  Line 14 + 0x59 bytes	C++
 	pkgtest.exe!__tmainCRTStartup()  Line 586 + 0x19 bytes	C
 	kernel32.dll!0000000077a0f56d() 	
 	ntdll.dll!0000000077b43281() 	
}}}


After some digging, it appears that there is an invalid assumption about TlsAlloc in thread/src/win32/thread.cpp: namely that it cannot return zero. The tss implementation uses zero as a sentinel value for initialization. As far as I can tell, however, the only ""illegal"" return value for TlsAlloc is the constant TLS_OUT_OF_INDEXES, which is defined as -1.

It appears that TlsAlloc happily returns zero as a valid index when called during process shutdown.

I looked at the solution for #4736 which is on the trunk, but it appears to make the same assumption that TlsAlloc cannot return zero."	Bugs	closed	Boost 1.51.0	thread	Boost 1.44.0	Showstopper	fixed	tss	jonathan.jones@…