Re: [Valgrind-developers] valgrind and thread-local storage

[Konstantin S. <kon...@gm...>]

On Tue, Mar 31, 2009 at 2:03 PM, Julian Seward <js...@ac...> wrote:
> On Tuesday 31 March 2009, Konstantin Serebryany wrote:
>> The problem seems to be even worth.
>> I've got a false positive on a stack object. Both Helgrind and
>> ThreadSanitizer are affected.
>> The scenario is the same:
>>
>>   - Thread1 starts
>>   - Thread1 touches stack
>>   - Thread1 ends
>>   - Thread2 starts (and there is no happens-before relation between it
>> and Thread1)
>>   - Thread2 touches stack
>> It may happen so that Thread2 will have it's stack in the same address
>> as Thread1.
>> Since there is no happens-before relation between threads,
>> ThreadSanitizer & Helgrind report a race.
>
> I know that libpthread re-uses stacks from finished threads for new
> threads, so as to avoid the overhead of munmapping them and then mmaping
> them for the new thread.  But I don't see how it can reuse a stack for a
> new thread without knowing that the old thread is finished.  In other words
> libpthread must know there is a h-b dependency there, even if TS and H don't
> see it.

Oh, sure there is a h-b dependency somewhere inside pthread lib. But
we don't see it.
Since H is pure h-b, this h-b dependency is not done by pthread_mutex_lock.

--kcc

>
> Do you think this is a correct analysis?
>
> J
>