This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fix libgomp crash without TLS (PR42616)
- From: Varvara Rainchik <varvara dot s dot rainchik at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Richard Henderson <rth at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 2 Sep 2014 14:36:27 +0400
- Subject: Re: Fix libgomp crash without TLS (PR42616)
- Authentication-results: sourceware.org; auth=none
- References: <CAAp9h93CTb_oZ-y4-GgJUN7wTkjUajWMzGD+eyY43wJHQFw5eg at mail dot gmail dot com> <5400BB29 dot 2010205 at redhat dot com> <20140901105136 dot GM17454 at tucnak dot redhat dot com>
May I use gomp_free_thread as a destructor for pthread_key_create?
Then I'll make initial_thread_tls_data global for the first case, but
how can I differentiate thread created by gomp_thread_start (second
case)?
2014-09-01 14:51 GMT+04:00 Jakub Jelinek <jakub@redhat.com>:
> On Fri, Aug 29, 2014 at 10:40:57AM -0700, Richard Henderson wrote:
>> On 08/06/2014 03:05 AM, Varvara Rainchik wrote:
>> > * libgomp.h (gomp_thread): For non TLS case create thread data.
>> > * team.c (create_non_tls_thread_data): New function.
>> >
>> >
>> > ---
>> > diff --git a/libgomp/libgomp.h b/libgomp/libgomp.h
>> > index a1482cc..cf3ec8f 100644
>> > --- a/libgomp/libgomp.h
>> > +++ b/libgomp/libgomp.h
>> > @@ -479,9 +479,15 @@ static inline struct gomp_thread *gomp_thread (void)
>> > }
>> > #else
>> > extern pthread_key_t gomp_tls_key;
>> > +extern struct gomp_thread *create_non_tls_thread_data (void);
>> > static inline struct gomp_thread *gomp_thread (void)
>> > {
>> > - return pthread_getspecific (gomp_tls_key);
>> > + struct gomp_thread *thr = pthread_getspecific (gomp_tls_key);
>> > + if (thr == NULL)
>> > + {
>> > + thr = create_non_tls_thread_data ();
>> > + }
>> > + return thr;
>> > }
>>
>> This should never happen.
>
> I guess it can happen if you mix up explicit pthread_create and libgomp APIs.
> initialize_team will only initialize it in the initial thread, while if you
> use #pragma omp ... or omp_* calls from a thread created with
> pthread_create, in the !HAVE_TLS case pthread_getspecific will return NULL.
>
> Now, the patch doesn't handle that case completely though (and is badly
> formatted), the problem is that if we allocate in the !HAVE_TLS case
> in non-initial thread the TLS data, we want to free them again, so that
> would mean pthread_key_create with non-NULL destructor, and then we need to
> differentiate in between the 3 cases - key equal to &initial_thread_tls_data
> (would need to move out of the block context), no freeing needed, thread
> created by gomp_thread_start, no freeing needed, otherwise free.
>
>> The thread-specific data is set in gomp_thread_start and initialize_team.
>>
>> Where are you getting a call to gomp_thread that hasn't been through one of
>> those functions?
>
> Jakub