From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21358 invoked by alias); 19 Nov 2003 19:16:04 -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 21323 invoked from network); 19 Nov 2003 19:16:02 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 19 Nov 2003 19:16:02 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id hAJJFvH17665 for ; Wed, 19 Nov 2003 14:15:57 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id hAJJFua30670; Wed, 19 Nov 2003 14:15:56 -0500 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id hAJJFuH11680; Wed, 19 Nov 2003 11:15:56 -0800 Message-ID: <3FBBC16B.8020508@redhat.com> Date: Wed, 19 Nov 2003 19:16:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb-patches@sources.redhat.com Subject: Re: [RFA/testsuite] attach.exp: Add small delay in busy loop... References: <20031118230002.GG1319@gnat.com> <3FBAB89F.3020805@redhat.com> <20031119002902.GA29296@nevyn.them.org> In-Reply-To: <20031119002902.GA29296@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-11/txt/msg00402.txt.bz2 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?