From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22374 invoked by alias); 19 Nov 2003 19:17:27 -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 22340 invoked from network); 19 Nov 2003 19:17:25 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 19 Nov 2003 19:17:25 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1AMXpM-0002rY-HC; Wed, 19 Nov 2003 14:17:24 -0500 Date: Wed, 19 Nov 2003 19:17:00 -0000 From: Daniel Jacobowitz To: Michael Snyder Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA/testsuite] attach.exp: Add small delay in busy loop... Message-ID: <20031119191724.GA10982@nevyn.them.org> Mail-Followup-To: Michael Snyder , gdb-patches@sources.redhat.com References: <20031118230002.GG1319@gnat.com> <3FBAB89F.3020805@redhat.com> <20031119002902.GA29296@nevyn.them.org> <3FBBC16B.8020508@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FBBC16B.8020508@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-11/txt/msg00403.txt.bz2 On Wed, Nov 19, 2003 at 11:15:55AM -0800, Michael Snyder wrote: > Daniel Jacobowitz wrote: > >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. > > Well, we could run to a known breakpoint and then backtrace -- > but that wouldn't test the state immediately after attach. > Can you think of a good test for a valid state, other than > a backtrace? Not really. Let's not worry about the problem for now. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer