From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29793 invoked by alias); 21 Feb 2007 00:54:13 -0000 Received: (qmail 29733 invoked by uid 22791); 21 Feb 2007 00:54:12 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.palmsource.com (HELO mx2.palmsource.com) (12.7.175.14) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 21 Feb 2007 00:54:02 +0000 Received: from localhost (localhost [127.0.0.1]) by localhost.domain.tld (Postfix) with ESMTP id 1738D11D353; Tue, 20 Feb 2007 16:54:01 -0800 (PST) Received: from mx2.palmsource.com ([127.0.0.1]) by localhost (mx2.palmsource.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03636-09-7; Tue, 20 Feb 2007 16:54:00 -0800 (PST) Received: from ussunex01.palmsource.com (unknown [192.168.101.9]) by mx2.palmsource.com (Postfix) with ESMTP id DA52911CF6E; Tue, 20 Feb 2007 16:53:59 -0800 (PST) Received: from 192.168.92.92 ([192.168.92.92]) by ussunex01.palmsource.com ([192.168.101.9]) via Exchange Front-End Server owa.palmsource.com ([10.0.20.17]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Feb 2007 00:53:59 +0000 Received: from svmsnyderlnx by owa.palmsource.com; 20 Feb 2007 16:53:58 -0800 Subject: Re: Break in a thread but continue other threads From: Michael Snyder To: David Highley Cc: gdb@sourceware.org In-Reply-To: <200702161602.l1GG2gpr014571@douglas.highley-recommended.com> References: <200702161602.l1GG2gpr014571@douglas.highley-recommended.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 21 Feb 2007 01:10:00 -0000 Message-Id: <1172019238.19657.75.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 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-02/txt/msg00218.txt.bz2 On Fri, 2007-02-16 at 08:02 -0800, David Highley wrote: > Is it possible to put a break in one thread but continue all the other > threads? No, gdb has a very simple model for thread debugging: either all threads are running, or all are stopped. * Except as noted below... > Our developers keep lamenting to me the inadequacies of the gdb > debugger in debugging our run time configured multi-threaded > applications. In several cases I can answer read the manual but in > others I know the persons diligence and capabilities. While ddd is ok it > would not be considered a great interface by any standard. I peronally > am not complaining as I do not use any of the integrated development > environments but I get plenty of input from the developer community; > 300+ on just one program. * Theoretically, you might set a thread-specific breakpoint and attach to it the command "set scheduler-locking on". If your host / target supports scheduler locking, this would prevent any other thread from running, whereupon you could simply "continue". However, use at your own risk... it's a great way to create a deadlock. I haven't tried this, usual disclaimers apply...