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

[Vinay Sridhar <vinay at linux dot vnet dot ibm dot com>]

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..