From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26798 invoked by alias); 31 Mar 2009 15:41:29 -0000 Received: (qmail 26582 invoked by uid 22791); 31 Mar 2009 15:41:26 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 31 Mar 2009 15:41:20 +0000 Received: (qmail 5708 invoked from network); 31 Mar 2009 15:41:17 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 31 Mar 2009 15:41:17 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [gdbserver] fix spurious SIGTRAPs Date: Tue, 31 Mar 2009 15:45:00 -0000 User-Agent: KMail/1.9.10 References: <200903120245.21837.pedro@codesourcery.com> <200903252239.23040.pedro@codesourcery.com> In-Reply-To: <200903252239.23040.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903311640.45209.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-03/txt/msg00702.txt.bz2 On Wednesday 25 March 2009 22:39:22, Pedro Alves wrote: > On Thursday 12 March 2009 02:45:21, Pedro Alves wrote: > > While working on multi-process/non-stop gdbserver, using my favorite > > multithreaded test, I noticed that gdbserver sometimes would report > > spurious SIGTRAPs. > > > > Here's what would happen: > > > > The test consists of several threads all running the same loop. > > There is a breakpoint set in the loop, hence all threads may hit it. > > The test then issues several "next" commands in a loop. > > > > Here's what would happen in gdbserver: > > > > 1) We issue a "continue", and wait until a thread hits the > > breakpoint. Could be any thread, but assume thread 1 hits it. > > > > 2) We issue a "next" --- this single-steps thread 1, and resumes all > > other threads. > > > > 3) thread 2, due to scheduler-locking off, hits the breakpoint. > > gdbserver stops all other threads by sending them SIGSTOPs. > > > > 4) While being stopped in step 3, thread 1 reports a SIGTRAP, that > > corresponds to the finished single-step of step 2. gdbserver > > leaves the SIGTRAP pending to report later. > > > > 5) We issue another "next" --- this requests thread 2 to > > single-step, and all other threads to continue, including thread > > 1. Before resuming any thread, gdbserver notices that it > > remembers from step 4 a pending SIGTRAP to report for thread 1, > > so reports it now. > > > > 6) From GDB's perpective, this SIGTRAP can't represent a finished > > single-step, since thread 1 was not single-stepping (it was > > continued in step 5). Neither does this SIGTRAP correspond to a > > breakpoint hit. GDB reports to the user a spurious SIGTRAP. > > > > Older GDBs happened to paper over the problem, as > > clear_proceed_status used to only clear the status of one thread. As > > a side effect, GDB resumed the threads that hit such > > spurious SIGTRAPs. > > > > To fix this, when stopping all threads to report a stop to GDB, > > if we find a thread stops with a SIGTRAP due to a finished single-step, > > do not leave the SIGTRAP pending. > > > > Tested against x86_64-linux gdbserver, new test included. > > > > OK to apply? Daniel mentions that he has no time to review these gdbserver patches, and told me to review them myself. :-) If nobody objects, and if there are no comments on the patches themselves, I'll apply this patch, and the others that add non-stop + multiprocess support to gdbserver. -- Pedro Alves