From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25681 invoked by alias); 23 Oct 2008 21:44:27 -0000 Received: (qmail 25671 invoked by uid 22791); 23 Oct 2008 21:44:26 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 23 Oct 2008 21:43:55 +0000 Received: from mailhost4.vmware.com (mailhost4.vmware.com [10.16.67.124]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 9D75713403; Thu, 23 Oct 2008 14:43:52 -0700 (PDT) Received: from [10.20.92.59] (promb-2s-dhcp59.eng.vmware.com [10.20.92.59]) by mailhost4.vmware.com (Postfix) with ESMTP id 80D6AC9A34; Thu, 23 Oct 2008 14:43:52 -0700 (PDT) Message-ID: <4900EEF2.2050405@vmware.com> Date: Thu, 23 Oct 2008 21:44:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Lukasz Lempart CC: "gdb@sourceware.org" Subject: Re: gdb and cloned process References: <4ced24c0810221709u17575bf3s73994724c456e956@mail.gmail.com> <20081023030548.GA21266@caradoc.them.org> <4900C1CC.20002@vmware.com> <4ced24c0810231329w4a1e4788qaeac176afff1fc4e@mail.gmail.com> In-Reply-To: <4ced24c0810231329w4a1e4788qaeac176afff1fc4e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-10/txt/msg00115.txt.bz2 Lukasz Lempart wrote: > On Thu, Oct 23, 2008 at 11:26 AM, Michael Snyder wrote: >> Daniel Jacobowitz wrote: >>> On Wed, Oct 22, 2008 at 05:09:32PM -0700, Lukasz Lempart wrote: >>>> How does gdb (through libthread_db) figure out what threads belong to a >>>> process? >>> The thread library maintains an internal list of threads. If you've >>> cloned the process, without telling the C library about that, you're >>> going to end up with the same list of threads; so the behavior you >>> describe is not surprising. >>> >>>> Is there currently a way to disable thread debugging in gdb? >>> Not really. You might be able to preload a dummy libthread_db.so.1 >>> that always failed to detect new threads. >> What if you strip libthread.so? Isn't that supposed to >> cause thread debugging to fail? >> > > Stripping libthread_db.so seems to do the trick. Thanks for the > suggestion. Keeping both version of the library around and just > changing LD_LIBRARY_PATH to point to the one I want seems to be the > most portable way to handle debugging both the original and the cloned > process. A gdb command to turn on/off thread debugging would be very > nice to have though. Cool... so tell us a little bit about your application, please. What sorts of data are you monitoring in the running process, how are you monitoring the data, how often are you updating it, and how useful has the technique proven to be? And have you thought ahead as far as actually modifying the data of the running process?