On Tue, Oct 09, 2012 at 09:13:06PM -0400, Jason Merrill wrote:
> 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,
Have you tried a gcc trunk build on linux configured to use emutls instead
of tls to confirm that this issue is really darwin-specific? These failures
might
also appear on sparc-sun-solaris2.9 but we don't have recent gcc trunk
testresults
for that. Perhaps Rainer can try a build of current gcc trunk and see if it
impacts sparc-sun-solaris2.9's use of emutls as well.
Jack
>
> Jason
