From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4552 invoked by alias); 30 Aug 2005 02:52:08 -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 4503 invoked by uid 22791); 30 Aug 2005 02:52:05 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 30 Aug 2005 02:52:05 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1E9wEF-0004nK-IY; Mon, 29 Aug 2005 22:52:03 -0400 Date: Tue, 30 Aug 2005 02:55:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis , gdb-patches@sources.redhat.com Subject: Re: MI testsuite to use PTY for inferior Message-ID: <20050830025203.GA16646@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sources.redhat.com References: <20050727031758.GA15798@white> <200508132151.j7DLpnoR015475@elgar.sibelius.xs4all.nl> <20050819222721.GA20029@white> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050819222721.GA20029@white> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-08/txt/msg00251.txt.bz2 On Fri, Aug 19, 2005 at 06:27:21PM -0400, Bob Rossi wrote: > > Funny thing is that if I run mi-console.exp alone, it usually > > (although not always) succeeds. > > > > Attached are a gdb.log for a failing run and a passing run. > > OK, I've tracked down why mi-console.exp breaks. Also, I can reproduce > it. The problem is slightly difficult to fix because of race conditions > so I was hoping to get some advice from people who might have had > similar experience with the testsuite. Nice job tracking this down. > This splits up the regex matching into 2 commands, which makes sense. > The problem is, in mi_gdb_test when it goes to match 47\\^running, it is > possible that either just that has been outputted by GDB (Yay, match!), > or that also the 47\\*stopped... output has also been output by GDB. In > this case, the testcase fails because the regex in mi_gdb_test does not > match the 'end anchor' of the output from GDB. Thus the race condition. > > I'm still thinking of ways to fix this without totally hacking the > testsuite, any ideas? > > To reproduce this problem, put 'sleep 1' just before the gdb_expect line > in mi-support.exp:mi_gdb_test. That gives GDB enough time to output > both items that need to be matched. Well, let's see. I'd recommend adding support for multiple prompts to mi_gdb_test so that we don't lose the "unexpected output" case; otherwise we get nasty timeouts. I'm thinking of, roughly, this control flow. gdb_expect { .... -re "^running\n$mi_gdb_prompt" { # Note the lack of a trailing anchor. # This will leave everything after that prompt in expect's # buffer, only consuming things before it. pass 1 } -re ".*$mi_gdb_prompt$" { fail return } } gdb_expect { .... -re "\*stopped\n$mi_gdb_prompt" { pass 1 } -re ".*$mi_gdb_prompt$" { fail return } } I haven't tried it. Does the idea make sense? -- Daniel Jacobowitz CodeSourcery, LLC