JDK-8367365 : java/math/BigInteger/BigIntegerTest.java failed in jtreg timeout
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.math
  • Affected Version: 26
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: aarch64
  • Submitted: 2025-09-10
  • Updated: 2025-09-12
  • Resolved: 2025-09-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 26
26 masterFixed
Related Reports
Relates :  
Description
----------System.out:(2/65)----------
Seed from RandomFactory = -9062601749751529207L
Testing subset 1
----------System.err:(47/1453)----------
Constructor: Passed
Prime: Passed
nextProbablePrime: Passed
Arithmetic I for 100 bits: Passed
Arithmetic II for 100 bits: Passed
Arithmetic I for 2760 bits: Passed
Arithmetic II for 2760 bits: Passed
Arithmetic I for 8000 bits: Passed
Arithmetic II for 8000 bits: Passed
divideAndRemainder for 100 bits: Passed
divideAndRemainder for 2760 bits: Passed
divideAndRemainder for 8000 bits: Passed
pow for 100 bits: Passed
pow for 2760 bits: Passed
pow for 8000 bits: Passed
square for 100 bits: Passed
square for 4200 bits: Passed
square for 7000 bits: Passed
squareRootSmall: Passed
perfectSquaresLong: Passed
squareRoot for 2^N and 2^N - 1, 1 <= N <= Double.MAX_EXPONENT: Passed
squareRoot for int: Passed
squareRoot for long: Passed
squareRoot for double: Passed
sqrtAndRemainder: Passed
nthRootSmall: Passed
nthRoot for 2^N, 2^N - 1 and 2^N + 1, 1 <= N <= 256: Passed
nthRoot for int: Passed
nthRoot for long: Passed
nthRoot for double: Passed
nthRootAndRemainder: Passed
Bit Count: Passed
BitLength: Passed
clearBit/testBit for 100 bits: Passed
flipBit/testBit for 100 bits: Passed
getLowestSetBit for 100 bits: Passed
Logic (^ | & ~) for 100 bits: Passed
Logic (&~ | ~) for 100 bits: Passed
baz shiftLeft for 100 bits: Passed
baz shiftRight for 100 bits: Passed
baz shiftLeft/Right for 100 bits: Passed
Array Conversion for 100 bits: Passed
Modular Inverse for 100 bits: Passed
Modular Inverse for 2760 bits: Passed

JavaTest Message: Test complete.

result: Error. "main" action timed out with a timeout of 120 seconds on agent 20


test result: Error. "main" action timed out with a timeout of 120 seconds on agent 20
Comments
[~rgiulietti] OK thanks for the feedback I didn't see two run commands in the test, but observed only extract from code * @run main/timeout=400 BigIntegerTest and this corresponds with extract from log maxTimeout=400 run=USER_SPECIFIED build jdk.test.lib.RandomFactory\nUSER_SPECIFIED main BigIntegerTest\nUSER_SPECIFIED main/timeout\=400 BigIntegerTest\n so my reasoning was based on that log observation ... However, after looking at the test source multiple times I finally saw @run main BigIntegerTest which explains the 120 timeout, which would have been 480 when the timeout factor was 4 while I had originally only seen * @run main/timeout=400 BigIntegerTest Nonetheless bear with me as the following may be relevant in the future The possibilities for a timeout on Agent/AgentServer connection exist. It is also important to note that the reduction of the timeout factor impacts the timeout settings on the Agent/AgentServer TCP connection described below. FWIW Looking into this further we see that an SO_TIMEOUT is set on the Agent/AgentServer connection The reduction of the timeout factor is influential here An Agent and its peer AgentServer communicate over a TCP socket and that socket has a keep alive timeout set as follows public static class KeepAlive { public static final int WRITE_TIMEOUT = 60 * 1000; // 1 minute public static final int READ_TIMEOUT = 2 * WRITE_TIMEOUT; Agent connection set up code try { final int ACCEPT_TIMEOUT = (int) (60 * 1000 * timeoutFactor); // default 60 seconds, for server to start and "phone home" ss.setSoTimeout(ACCEPT_TIMEOUT); log("Waiting up to " + ACCEPT_TIMEOUT + " milli seconds for a" + " socket connection on port " + port + (agentServerPid != -1 ? " from process " + agentServerPid : "")); Socket s = ss.accept(); log("Received connection on port " + port + " from " + s); s.setSoTimeout((int)(KeepAlive.READ_TIMEOUT * timeoutFactor)); <----------------- Now 1 and NOT 4 in = new DataInputStream(s.getInputStream()); out = new DataOutputStream(s.getOutputStream()); } finally { ss.close(); } s.setSoTimeout((int)(KeepAlive.READ_TIMEOUT * timeoutFactor)); with timeoutFactor == 1 this reduces the keep alive to 120 seconds rather than the previous 480 seconds As such the reduction in the timeout factor may impact on the Agent/ AgentServer communications and result in intermittent failures
12-09-2025

I think this is a JTREG issue as a side effect of the recent timeout factor adjustment This test should have timed out after 6 minute i.e. 480 seconds and NOT 120 seconds. As such this is either the timeout specified to the test has had NO effect, or the 120 seconds is a communications timeout OR some other timer between the Agent and its AgentServer. This "other" timer may have been adjusted by the timeout factor and is operating without that adjustment. But to re-iterate this TEST has a TIMEOUT == 480 seconds NOT 120 seconds
12-09-2025

Changeset: 8b92af7d Branch: master Author: Raffaello Giulietti <rgiulietti@openjdk.org> Date: 2025-09-11 14:59:30 +0000 URL: https://git.openjdk.org/jdk/commit/8b92af7d4aeece8b40c6c4f9de333964833da607
11-09-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/27211 Date: 2025-09-11 08:55:02 +0000
11-09-2025

The timeoutFactor was recently changed from 4 to 1. I thought tests with an explicit time (this one has /timeout=400) were adjusted but it looks like this one wasn't changed.
11-09-2025