This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Fix testsuite timeout clobbers


> 	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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]