JDK-8166642 : serviceability/dcmd/framework/* timeout
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-09-23
  • Updated: 2022-07-13
  • Resolved: 2018-03-15
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 11
11 b07Fixed
Related Reports
Duplicate :  
JDK-8194057 - serviceability/dcmd/framework/InvalidCommandTest.java times out
Relates :  
JDK-8205654 - serviceability/dcmd/framework/HelpTest.java timed out
Relates :  
JDK-8072440 - serviceability/dcmd/ tests timeout
Relates :  
JDK-8072440 - serviceability/dcmd/ tests timeout
Sub Tasks
JDK-8199708 :  
[BACKOUT] serviceability/dcmd/framework/* timeout - Resolved
Description
serviceability/dcmd/framework/VMVersionTest timeout

result: Error. Program `TEST_JAVA_HOME\bin\java' timed out (timeout set to 1920000ms, elapsed time was 1919998ms).
Comments
I see the cause of this bug was never mentioned here. This is from Daniil's RFR email: ------------------------------------------------------ The problem here is that these tests invoke jcmd in different ways and one of such ways is when a main class is passed to the jcmd as a VM identifier. The main class for jtreg test is com.sun.javatest.regtest.agent.MainWrapper and in some cases more than one test are running in parallel and there are multiple Java processes with com.sun.javatest.regtest.agent.MainWrapper as a main class . When it happens jcmd iterates over all Java processes that match the condition (the main class equals to com.sun.javatest.regtest.agent.MainWrapper) and executes the command for each of them. That results in the jcmd invokes the given command multiple times and attaches to Java processes not related to the current test. The fix makes serviceability/dcmd/framework/* tests non-concurrent to ensure that they don't interact with other tests. ------------------------------------------------------ There was also some discussion fixing this by having each test use a unique main class name instead of MainWrapper in order to avoid having to run too many tests non-concurrent. However, there are only 3 tests involved here, and they run quickly, so performance is not really an issue.
26-06-2018
URL: http://hg.openjdk.java.net/jdk/jdk/rev/66ba2092464c User: jwilhelm Date: 2018-03-23 18:52:48 +0000
23-03-2018
URL: http://hg.openjdk.java.net/jdk/hs/rev/66ba2092464c User: cjplummer Date: 2018-03-15 22:27:46 +0000
15-03-2018
Failures are only on Windows.
20-11-2017
Just another rule about timeout RULE "serviceability/dcmd/framework/VMVersionTest.java" Timeout none
20-03-2017
Note that the process environment shows jcmd is still running. So it appears that the exec'd jcmd has hung for some reason.
26-09-2016