From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3422 invoked by alias); 22 Jan 2009 09:18:38 -0000 Received: (qmail 3413 invoked by uid 22791); 22 Jan 2009 09:18:38 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 22 Jan 2009 09:18:30 +0000 Received: from spaceape23.eur.corp.google.com (spaceape23.eur.corp.google.com [172.28.16.75]) by smtp-out.google.com with ESMTP id n0M9IRlm015472 for ; Thu, 22 Jan 2009 09:18:27 GMT Received: from rv-out-0708.google.com (rvfc5.prod.google.com [10.140.180.5]) by spaceape23.eur.corp.google.com with ESMTP id n0M9IMTr015062 for ; Thu, 22 Jan 2009 01:18:23 -0800 Received: by rv-out-0708.google.com with SMTP id c5so4202752rvf.20 for ; Thu, 22 Jan 2009 01:18:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.113.6 with SMTP id q6mr3260117rvm.212.1232615901760; Thu, 22 Jan 2009 01:18:21 -0800 (PST) In-Reply-To: <200901212257.n0LMvkTQ029040@d12av02.megacenter.de.ibm.com> References: <200901212257.n0LMvkTQ029040@d12av02.megacenter.de.ibm.com> Date: Thu, 22 Jan 2009 09:18:00 -0000 Message-ID: Subject: Re: [rfa/gdbserver] Fix crash in thread_db_get_tls_address From: Doug Evans To: Ulrich Weigand Cc: gdb-patches@sourceware.org, drow@false.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-01/txt/msg00445.txt.bz2 On Wed, Jan 21, 2009 at 2:57 PM, Ulrich Weigand wrote: > Hello, > > when debugging remotely using a GDB with private modifcations, I'm running > into a crash in gdbserver, which I believe to be a real bug (even if latent > with mainline GDB). > > The problem occurs when the thread_db_get_tls_address routine is invoked > (as a result of processing a qGetTLSAddr: query) on an inferior that > actually has no threads (or where the thread layer is not initialized yet). > > This is caused by thread_db_get_tls_address calling find_one_thread, > which in the end calls down into the libthread_db td_ta_map_lwp2thr > routine -- at a time libthread_db is not yet initialized, and in fact > the "thread_agent" handle passed to td_ta_map_lwp2thr was not yet > set up. This results in a segfault within libthread_db. > > Now I guess it is debatable whether or not sending a qGetTLSAddr: > query in this situation is a useful thing, but it seems to me that > gdbserver shouldn't just *crash* ... > > The following patch fixes this by returning failure from > thread_db_get_tls_address if called before the thread layer > is properly initialized. > > > Tested on powerpc64-linux (64-bit / 32-bit) using local gdbserver. > > OK for mainline? > > Bye, > Ulrich > > > ChangeLog: > > * thread-db.c (thread_db_get_tls_address): Do not crash if > called when thread layer is not yet initialized. > > > Index: src/gdb/gdbserver/thread-db.c > =================================================================== > --- src.orig/gdb/gdbserver/thread-db.c > +++ src/gdb/gdbserver/thread-db.c > @@ -388,6 +388,10 @@ thread_db_get_tls_address (struct thread > td_err_e err; > struct process_info *process; > > + /* If the thread layer is not (yet) initialized, fail. */ > + if (!all_symbols_looked_up) > + return -1; > + > process = get_thread_process (thread); > if (!process->thread_known) > find_one_thread (process->lwpid); > -- > Dr. Ulrich Weigand > GNU Toolchain for Linux on System z and Cell BE > Ulrich.Weigand@de.ibm.com > Hi. I've run into similar situations with the thread layer not yet initialized. One aspect of this patch is a bit confusing. Maybe a comment is warranted. Returning -1 will cause server.c:handle_query to mark the packet as unknown which will in turn cause remote.c:packet_ok to mark the packet as disabled (on the gdb side). How does the packet get re-enabled if the thread layer is later initialized?