On Thu, 11 Sep 2025 10:42:31 GMT, Daniel Fuchs <[email protected]> wrote:
>> There were two `@run` lines, one without a timeout (which is now removed), >> and a later one with a timeout of 400. >> IIUC, this means that the test was executed 2 times, one with a default >> timeout, and another with the explicit timeout of 400. >> >> The JBS issue shows a timeout after 120 seconds, so I guess this was due to >> the first `@run` line without an explicit timeout. > > Yes - the observed timeout was 120s - so it must have been the first `@run`. > That first `@run` was added by > [JDK-8078672](https://bugs.openjdk.org/browse/JDK-8078672) - I'm not sure why > - that might have been a left over from debugging... Hello Raffaello, > The JBS issue shows a timeout after 120 seconds, so I guess this was due to > the first @run line without an explicit timeout. More as a general note than a review of this change - when a test action times out, jtreg prints the timeout information in that test action's "section" (each test action has a "section" of its own in the jtr report file). That section will additionally also include the literal definition of the test action. In the case of this timeout failure that happened in our CI, that section looks like: #section:main ----------messages:(11/327)---------- command: main BigIntegerTest reason: User specified action: run main BigIntegerTest started: Wed Sep 10 17:58:16 UTC 2025 ... Timeout signalled after 120 seconds Timeout information: --- Timeout information end. finished: Wed Sep 10 18:01:11 UTC 2025 elapsed time (seconds): 174.678 Notice the "reason" in that section, that's where the test action's literal definition is printed. In this case (as you note), it was the `@run main BigIntegerTest` which timed out. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27211#discussion_r2340729303
