Re: [RFC][Patch] Fix gdb failure to access tls data for parent thread

Vinay Sridhar
2009-02-24T10:52:32Z

On Mon, 2009-02-23 at 20:09 +0000, Pedro Alves wrote:
> On Monday 23 February 2009 14:08:12, Daniel Jacobowitz wrote:
> > On Mon, Feb 23, 2009 at 02:20:59PM +0530, Vinay Sridhar wrote:
> > > > If they are, and they do not have private info set, what added them to
> > > > the thread list? I missed one function; maybe they were added by
> > > > add_thread_silent?
> > > >
> > >
> > > yes, add_thread_silent () is called on the threads. Its called for the
> > > parent from fork_inferior () and for the child threads from
> > > add_thread_with_info ()
> >
> > Thanks, now we're making progress.
> >
> > Pedro, copying you because this is related to always-a-thread.
> >
> > What's happening here is that we go to look up a TLS variable.
> > We have some threads in the thread list with thread->private set, but
> > the main thread does not have it set - thread_db never added it,
> > fork_inferior did. So we don't really know about it.
> >
> > Vinay, thread_db_find_new_threads should have been called when the
> > program started up. Was find_new_threads_callback called for
> > the main thread during that process? If so, was ti_tid == 0?
> > That shouldn't happen unless the program is staticly linked.
> >
>
> I haven't had a chance to investigate this yet, other than building
> Vinay's testcase (which doesn't build BTW. Please confirm if there
> isn't anything important missing), and noticing I can't reproduce.

Pedro,

Please try this test and let me know if you're able to get a recreate:

ï»¿$ cat test.c

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <omp.h>

__thread int thr;

void initTlsData() {
printf("Initialising thread %d\n",thr);
}

int main(int argc, char *argv[]) {
#pragma omp parallel
{
thr = omp_get_thread_num();
initTlsData();
}
return(0);
}

0. export OMP_NUM_THREADS = <X>
1. gcc -g test.c -fopenmp -o test
2. gdb ./test
3. break initTlsData
4. thread 1 (Switch to main thread)
5. print thr (You should see the error after this)

> Sounds like there's a race somewhere that one of the calls that
> look like this:
>
> if (!have_threads ())
> thread_db_find_new_threads_1 ();
>
> ... is finding that we already have a ->private field set for
> some thread not the main, and hence, we're not filling it
> for the main thread.

A race? I'm able to get this error each time I run the test...

>
> Vinay, could you tell us some more details about your system?

I'm running SLES11 on a ppc64 machine using gdb-6.8.50.20090216.
Standard OMP, gcc etc..