From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16314 invoked by alias); 17 Jul 2003 18:29:45 -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 16307 invoked from network); 17 Jul 2003 18:29:45 -0000 Received: from unknown (HELO hawaii.kealia.com) (209.3.10.89) by sources.redhat.com with SMTP; 17 Jul 2003 18:29:45 -0000 Received: by hawaii.kealia.com (Postfix, from userid 2049) id A7B38BED1; Thu, 17 Jul 2003 11:29:44 -0700 (PDT) To: gdb Subject: TARGET_SIGNAL_TRAP From: David Carlton Date: Thu, 17 Jul 2003 18:29:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-07/txt/msg00214.txt.bz2 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.) David Carlton carlton@kealia.com