From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5557 invoked by alias); 19 Nov 2003 00:29:05 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 5542 invoked from network); 19 Nov 2003 00:29:03 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 19 Nov 2003 00:29:03 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1AMGDO-0007d0-Ep for ; Tue, 18 Nov 2003 19:29:02 -0500 Date: Wed, 19 Nov 2003 00:29:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [RFA/testsuite] attach.exp: Add small delay in busy loop... Message-ID: <20031119002902.GA29296@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20031118230002.GG1319@gnat.com> <3FBAB89F.3020805@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FBAB89F.3020805@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-11/txt/msg00387.txt.bz2 On Tue, Nov 18, 2003 at 04:26:07PM -0800, Michael Snyder wrote: > Joel Brobecker wrote: > >Hello, > > > >The attach.exp sometimes fails on certain platforms (eg mips-irix), > >and causes an attach process to be left behind. Since it is doing a busy > >loop, this runaway process left behind consumes 99.9% of the CPU, > >and considerably slows down the execution of the rest of the testsuite. > > > >I suggest the following change to add a small delay at each iteration > >of the busy loop. I had to make some adjustments to attach.exp: > > > > a. Line number 19 became line 32. > > Just like Elena recently upgraded a test to avoid hard-coded > > line number, we should probably clean this up, someday. This can > > be a separate patch, however. > > > > b. The program was attached to while inside the busy loop, so the > > test was expecting the debugger to report that the inferior was > > inside function main() after the attach command was performed. > > This is no longer the case, since the inferior is most likely > > inside a system call, doing the delay. I felt that it was not > > a necessity to checke where the debugger thought the inferior > > was stopped, so removed that part of the expected output. What > > I can do is add an extra test that does a backtrace and verifies > > that it contains a frame for function main(). > > > >2003-11-18 J. Brobecker > > > > * gdb.base/attach.c: Add small delay in busy loop. > > * gdb.base/attach.exp: Make some associated adjustments. > > > >OK to apply? > > Seems to work on Linux. I'd sure like to see that backtrace test, > though, to confirm that we are able to build a meaningful machine > state after we attach. Seems reasonable to me. Warning: this will be yet another place we backtrace from syscalls, and sometimes we just can't do that. We already have a couple of configurations where GDB can't reasonably be expected to backtrace out of nanosleep. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer