This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: Fix testsuite timeout clobbers
- From: Joel Brobecker <brobecker at adacore dot com>
- To: gdb-patches at sourceware dot org
- Date: Fri, 29 Jan 2010 07:59:50 +0400
- Subject: Re: RFC: Fix testsuite timeout clobbers
- References: <20100128215305.GA2813@caradoc.them.org>
> gdb/testsuite/
> * gdb.base/call-strs.exp, gdb.base/default.exp,
> gdb.base/ending-run.exp, gdb.base/finish.exp, gdb.base/funcargs.exp,
> gdb.base/huge.exp, gdb.base/nodebug.exp, gdb.base/ptype.exp,
> gdb.base/restore.exp, gdb.base/return.exp, gdb.base/setvar.exp,
> gdb.base/watchpoints.exp, gdb.threads/gcore-thread.exp,
> gdb.base/watchpoint-solib.exp: Save and restore timeout.
> * gdb.base/ending-run.exp: Correct restore of timeout.
> * gdb.base/page.exp: Remove unnecessary timeout setting.
Looks fine to me.
Independently of that, do we want to try a different approache where
the timeout gets reset more systematically? For instance, I can propose:
everytime gdb_start is called, reset the timeout to the default value
(which itself should be configurable - through a site.exp or board file?)
On the same topic (timeouts), I ran the testsuite on sparc-solaris,
yesterday, and some tests were badly timing out, and each timeout
was taking what it felt like hours (the testsuite itself took more
than 2 hours, and that's after I justed killed -9 the inferiors from
the tests). With AdaCore's testsuite, a timeout means we've lost sync
with debugger anyway - is there really an advantage to continuing a
testcase when we get a timeout? Wouldn't it just as effective to abort
the testcase after the first timeout?
--
Joel