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