From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26280 invoked by alias); 24 Feb 2009 10:52:32 -0000 Received: (qmail 26272 invoked by uid 22791); 24 Feb 2009 10:52:31 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 X-Spam-Check-By: sourceware.org Received: from e28smtp01.in.ibm.com (HELO e28smtp01.in.ibm.com) (59.145.155.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Feb 2009 10:52:25 +0000 Received: from d28relay02.in.ibm.com (d28relay02.in.ibm.com [9.184.220.59]) by e28smtp01.in.ibm.com (8.13.1/8.13.1) with ESMTP id n1OAqIj5015253 for ; Tue, 24 Feb 2009 16:22:18 +0530 Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67]) by d28relay02.in.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n1OAnUR64100270 for ; Tue, 24 Feb 2009 16:19:30 +0530 Received: from d28av05.in.ibm.com (loopback [127.0.0.1]) by d28av05.in.ibm.com (8.13.1/8.13.3) with ESMTP id n1OAqIgQ024843 for ; Tue, 24 Feb 2009 21:52:18 +1100 Received: from [9.124.124.72] (vinaysridhar.in.ibm.com [9.124.124.72]) by d28av05.in.ibm.com (8.13.1/8.12.11) with ESMTP id n1OAqIRf024838; Tue, 24 Feb 2009 21:52:18 +1100 Subject: Re: [RFC][Patch] Fix gdb failure to access tls data for parent thread From: Vinay Sridhar To: Pedro Alves Cc: Daniel Jacobowitz , gdb-patches@sourceware.org, luisgpm@linux.vnet.ibm.com In-Reply-To: <200902232009.58960.pedro@codesourcery.com> References: <20090211155300.GA22689@caradoc.them.org> <1235379059.10038.12.camel@localhost.localdomain> <20090223140812.GA10946@caradoc.them.org> <200902232009.58960.pedro@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Date: Tue, 24 Feb 2009 13:33:00 -0000 Message-Id: <1235472610.4894.14.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-02/txt/msg00456.txt.bz2 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 #include #include #include __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 = 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..