RFC: C++ PATCH to support dynamic initialization and destruction of C++11 and OpenMP TLS variables

Jason Merrill jason@redhat.com
Wed Oct 10 01:16:00 GMT 2012


On 10/09/2012 04:36 PM, Dominique Dhumieres wrote:
> ==36994==  Address 0x1003cd2e0 is 16 bytes inside a block of size 536 free'd
> ==36994==    at 0x10001252D: free (vg_replace_malloc.c:430)
> ==36994==    by 0x1003B5CB2: emutls_destroy (in /opt/gcc/gcc4.8p-192219/lib/libgcc_s.1.dylib)

Aha.  So the problem is that we're destroying the TLS data from one 
pthread key destructor, and then a later destructor tries to use it. 
Hmm, that's awkward.  And surprising, since we do TLS lookup before 
creating the key for the atexit list, so the emutls_destroy destructor 
should have been registered sooner, and so run later.  Does the Darwin 
pthread_tsd_cleanup not run destructors in reverse order of registration?

Jason



More information about the Gcc-patches mailing list