From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 823 invoked by alias); 23 Feb 2009 20:09:58 -0000 Received: (qmail 815 invoked by uid 22791); 23 Feb 2009 20:09:57 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 23 Feb 2009 20:09:52 +0000 Received: (qmail 7047 invoked from network); 23 Feb 2009 20:09:50 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 23 Feb 2009 20:09:50 -0000 From: Pedro Alves To: Daniel Jacobowitz Subject: Re: [RFC][Patch] Fix gdb failure to access tls data for parent thread Date: Tue, 24 Feb 2009 07:11:00 -0000 User-Agent: KMail/1.9.10 Cc: Vinay Sridhar , gdb-patches@sourceware.org, luisgpm@linux.vnet.ibm.com References: <20090211155300.GA22689@caradoc.them.org> <1235379059.10038.12.camel@localhost.localdomain> <20090223140812.GA10946@caradoc.them.org> In-Reply-To: <20090223140812.GA10946@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902232009.58960.pedro@codesourcery.com> X-IsSubscribed: yes 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/msg00452.txt.bz2 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. 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. Vinay, could you tell us some more details about your system? -- Pedro Alves