From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20374 invoked by alias); 17 Jul 2003 18:35:44 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 20367 invoked from network); 17 Jul 2003 18:35:43 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 17 Jul 2003 18:35:43 -0000 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19dDY6-0006af-00; Thu, 17 Jul 2003 14:32:14 -0400 Date: Thu, 17 Jul 2003 18:35:00 -0000 From: Daniel Jacobowitz To: David Carlton Cc: gdb Subject: Re: TARGET_SIGNAL_TRAP Message-ID: <20030717183214.GA25316@nevyn.them.org> Mail-Followup-To: David Carlton , gdb References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-07/txt/msg00215.txt.bz2 On Thu, Jul 17, 2003 at 11:29:44AM -0700, David Carlton wrote: > Some users here have noted that they have a hard time debugging > multithreaded code in GDB. We're assuming that it's probably a bug in > our code instead of in GDB: it's just that GDB is changing the timing > of the threads in ways that expose a latent bug in our code. > > Which made me curious: why does GDB change the timing of programs? I > set a breakpoint in handle_inferior_event, and I see all these events > claiming to be TARGET_SIGNAL_TRAPs. But I haven't set any breakpoints > or watchpoints! So what causes all these traps to be generated? Or > am I misunderstanding the situation? (I'm not at all sure that this > is specific to multithreaded code - it may just be that its effects > are most pronounced for multithreaded code, because single-threaded > code doesn't have as much timing to be thrown off.) Every time that a breakpoint is hit, including one breakpoint set at every shared library load/unload, thread creation, or sometimes thread exit, all threads are stopped and restarted. That's the usual cause. Signals also stop the process. If GDB isn't going to report the signal then it doesn't stop all threads, but that does interfere with timing. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer