From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11090 invoked by alias); 1 Dec 2007 17:52:51 -0000 Received: (qmail 11076 invoked by uid 22791); 1 Dec 2007 17:52:50 -0000 X-Spam-Check-By: sourceware.org Received: from py-out-1112.google.com (HELO py-out-1112.google.com) (64.233.166.177) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 01 Dec 2007 17:52:44 +0000 Received: by py-out-1112.google.com with SMTP id u52so6357394pyb for ; Sat, 01 Dec 2007 09:52:42 -0800 (PST) Received: by 10.35.110.13 with SMTP id n13mr4097673pym.1196531562219; Sat, 01 Dec 2007 09:52:42 -0800 (PST) Received: by 10.35.36.15 with HTTP; Sat, 1 Dec 2007 09:52:42 -0800 (PST) Message-ID: <8f2776cb0712010952y5330258akfe3086287f59ccb9@mail.gmail.com> Date: Sat, 01 Dec 2007 17:52:00 -0000 From: "Jim Blandy" To: "Michael Snyder" Subject: Re: Keeping breakpoints inserted Cc: "Jim Blandy" , "Thiago Jung Bauermann" , "Vladimir Prus" , gdb@sources.redhat.com In-Reply-To: <1196472622.2501.180.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200711292224.23659.vladimir@codesourcery.com> <1196456622.6746.169.camel@localhost.localdomain> <1196458063.2501.153.camel@localhost.localdomain> <1196472622.2501.180.camel@localhost.localdomain> X-Google-Sender-Auth: c51ced3fd84d4d91 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/msg00005.txt.bz2 On Nov 30, 2007 5:30 PM, Michael Snyder wrote: > > Since breakpoints only make the threads that hit them execute "very > > slowly", I don't see how they could introduce a deadlock in code that > > didn't already have the potential for deadlock in the absence of a > > debugger. > > Well, just 'cause you've changed the timing. Thread A holds > a resource that thread B needs; thread A hits a breakpoint > but thread B gets to keep running (for a while) because you > haven't finished inserting breakpoints. Non-stop debugging can affect the relative timing of threads more than all-stop debugging. And even if the developer only stops one thread, others may stop too, because they're waiting for the developer's thread to do something. But I don't think what you've described is deadlock: B is blocked waiting for A, which may take a long time (until the developer lets go of it, to be exact) to get through what it's doing. When A resumes, both will resume. 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. I think what's bothering you is that the degree of effective interference depends on the developer knowing stuff about the system under debug; it's not just a flat-out guarantee made by the debugger: "no matter what you do, we promise X, or at least roughly X." But there are reasonable debugger use cases that are simply not possible at all with all-stop debugging. We want to support those, in addition to the ones we support now.