Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: gdb-patches@sourceware.org
Subject: [commit] Fix timeouts in break-interp.exp on slow machines
Date: Tue, 12 Oct 2010 17:20:00 -0000	[thread overview]
Message-ID: <201010121720.o9CHKTnM003520@d12av02.megacenter.de.ibm.com> (raw)

Hello,

since Jan checked in his recent set of patches, break-interp.exp test cases
have started to succeed on my ARM machines.  However, I was still seeing
timeouts in the "info files" tests.

This is once again caused by a gdb_expect clause with a ".*" wildcard that
matches a large number of lines.  This can cause expect to slow down
significantly, to the extent that the tests time out on slow machines.

Fixed along the lines of similiar tests elsewhere by separating the
statement into two different gdb_expect patterns, which eliminates
the need for this particular wildcard.

Tested on i386-linux and armv7l-linux-gnueabi with no regressions,
fixes the timeouts on ARM.

Committed to mainline.

Bye,
Ulrich


ChangeLog:

	* break-interp.exp (test_ld): Use two separate gdb_expect statements
	for the "info files" test to avoid timeouts on slow machines.


Index: gdb/testsuite/gdb.base/break-interp.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/break-interp.exp,v
retrieving revision 1.22
diff -u -p -r1.22 break-interp.exp
--- gdb/testsuite/gdb.base/break-interp.exp	11 Oct 2010 08:47:47 -0000	1.22
+++ gdb/testsuite/gdb.base/break-interp.exp	12 Oct 2010 13:38:57 -0000
@@ -442,14 +442,23 @@ proc test_ld {file ifmain trynosym displ
     if $ifmain {
 	reach "_dl_debug_state" run $displacement
 
+	# Use two separate gdb_expect statements to avoid timeouts due to
+	# slow processing of wildcard capturing long output
 	set test "info files"
 	set entrynohex ""
-	gdb_test_multiple $test $test {
-	    -re "\r\n\[\t \]*Entry point:\[\t \]*0x(\[0-9a-f\]+)\r\n.*$gdb_prompt $" {
+	send_gdb "$test\n"
+	gdb_expect  {
+	    -re "\r\n\[\t \]*Entry point:\[\t \]*0x(\[0-9a-f\]+)\r\n" {
 		set entrynohex $expect_out(1,string)
-		pass $test
+	        gdb_expect {
+		    -re "$gdb_prompt $" { pass $test }
+		    timeout { fail "$test (timeout)" }
+		}
 	    }
+	    -re ".*$gdb_prompt $"  { fail $test }
+	    timeout         { fail "$test (timeout)" }
 	}
+
 	# `info sym' cannot be tested for .opd as the binary may not have
 	# symbols.
 	if {[istarget powerpc64-*] && [is_lp64_target]} {
-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com


             reply	other threads:[~2010-10-12 17:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-12 17:20 Ulrich Weigand [this message]
2010-10-12 18:23 ` Jan Kratochvil
2010-10-12 18:37   ` Ulrich Weigand
2010-10-12 18:41     ` Jan Kratochvil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201010121720.o9CHKTnM003520@d12av02.megacenter.de.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox