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.