Re: What does "Execution timeout is: $test_timeout" mean?
Jonathan Wakely <[email protected]> Fri, 4 Dec 2020 13:36:26 +0000
| Newsgroups | gmane.comp.sysutils.dejagnu.general |
|---|---|
| Message-ID | <[email protected]> |
On 03/12/20 22:49 -0600, Jacob Bachmeyer wrote: >Jonathan Wakely wrote: >>On 02/12/20 21:48 -0600, Jacob Bachmeyer wrote: >>>Jonathan Wakely wrote: >>>>Hi, >>>> >>>>[...] >>>> >>>>If I set test_timeout in ~/.dejagnurc or site.exp then I do indeed see >>>>the value change. But it doesn't do anything. I can set test_timeout >>>>to 2 second, and tests that sleep for 20 seconds or more will still >>>>PASS and not timeout (as long as $tool_timeout is large enough). >>> >>>Evidently, the GCC testsuite is overriding that setting. >> >>Yes, GCC replaces the standard_wait proc with one that uses its own >>value: >> >>https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/lib/timeout.exp;h=856c2e3184122cbd1128116703fef5480ec8805e;hb=HEAD >> >> >>And so now I see what's happening. DG prints the value of >>$test_timeout, calls remote_wait with that timeout, which calls >>standard_wait with that timeout, but GCC replaces that proc with one >>that uses a different timeout. I don't think DG can know about that >>really. >> >>Maybe what GCC should really do is set $test_timeout instead, which is >>possible now that proc unix_load allows it to be overridden. > >This is another example of problems caused by monkey-patching the test >framework. The use of a different variable is a bug in the GCC >testsuite. While I share the sentiment on monkey-patching, this code in GCC dates from 2008, so it's not entirely surprising that it doesn't use the test_timeout variable that was introduced in 2015, replacing a hardcoded "300" value: https://lists.gnu.org/archive/html/dejagnu/2015-11/msg00008.html I'll look into whether we can unify GCC's timeout with the new test_timeout variable in recent versions of DejaGnu.