From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27247 invoked by alias); 2 Dec 2007 18:38:34 -0000 Received: (qmail 27235 invoked by uid 22791); 2 Dec 2007 18:38:33 -0000 X-Spam-Check-By: sourceware.org Received: from igw2.br.ibm.com (HELO igw2.br.ibm.com) (32.104.18.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 02 Dec 2007 18:38:13 +0000 Received: from mailhub3.br.ibm.com (mailhub3 [9.18.232.110]) by igw2.br.ibm.com (Postfix) with ESMTP id 0BABD17F581 for ; Sun, 2 Dec 2007 16:33:51 -0200 (BRDT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id lB2Iac064218890 for ; Sun, 2 Dec 2007 16:36:39 -0200 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id lB2Iacve004900 for ; Sun, 2 Dec 2007 16:36:38 -0200 Received: from [9.8.9.232] ([9.8.9.232]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id lB2IacaM004892; Sun, 2 Dec 2007 16:36:38 -0200 Subject: Re: Keeping breakpoints inserted From: Thiago Jung Bauermann To: Jim Blandy Cc: Michael Snyder , Jim Blandy , Vladimir Prus , gdb@sources.redhat.com In-Reply-To: <8f2776cb0712010952y5330258akfe3086287f59ccb9@mail.gmail.com> References: <200711292224.23659.vladimir@codesourcery.com> <1196456622.6746.169.camel@localhost.localdomain> <1196458063.2501.153.camel@localhost.localdomain> <1196472622.2501.180.camel@localhost.localdomain> <8f2776cb0712010952y5330258akfe3086287f59ccb9@mail.gmail.com> Content-Type: text/plain Date: Sun, 02 Dec 2007 18:38:00 -0000 Message-Id: <1196620597.6746.179.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 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: 2007-12/txt/msg00007.txt.bz2 On Sat, 2007-12-01 at 09:52 -0800, Jim Blandy wrote: > On Nov 30, 2007 5:30 PM, Michael Snyder wrote: > The original concern you raised was that non-stop debugging is "more > intrusive than we already are". But clearly all-stop debugging on a > live system is maximally intrusive to the system's users; non-stop > debugging has the potential to be much less intrusive, when used with > knowledge of the interactions between the system's threads. There are cases when a developer will want to use non-stop debugging but minimize change of relative timing of threads. Suppose that a developer is trying to debug a deadlock situation in a program with 3 threads. A and B are deadlocking, and C is a "supporting" thread without which the other two can't run. He can't use all-stop debugging because while inspecting A and B, C needs to be running. In this case, relative timing of threads is important in order to have better chance at reproducing the deadlock. -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center