Bug ID: JDK-8193640 jps test TestJpsSanity.java can intermittently timeout

JDK-8193640 : jps test TestJpsSanity.java can intermittently timeout

Type: Bug
Component: core-svc
Sub-Component: tools
Affected Version: 10

Priority: P4
Status: Closed
Resolution: Cannot Reproduce
OS: solaris_11
CPU: x86_64

Submitted: 2017-12-15
Updated: 2021-07-12
Resolved: 2021-07-12

Versions (Unresolved/Resolved/Fixed)

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.

Other
tbdResolved

Related Reports

Relates :	JDK-8250806 - serviceability/dcmd/gc/HeapDumpCompressedTest.java#id2 test timed out
Relates :	JDK-8217171 - sun/tools/jps/TestJpsSanity.java timed out

Description

The following jps test timed out on a recent Solaris X64 'release' bits run:

sun/tools/jps/TestJpsSanity.java

Here's a snippet of where the test appears to be timing out:

"MainThread" #24 prio=5 os_prio=64 tid=0x0000000000b27800 nid=0x50 in Object.wait()  [0xffff80ff71dfd000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(java.base@10-internal/Native Method)
        - waiting on <0x00000004001f4208> (a java.lang.ProcessImpl)
        at java.lang.Object.wait(java.base@10-internal/Object.java:328)
        at java.lang.ProcessImpl.waitFor(java.base@10-internal/ProcessImpl.java:494)
        - waiting to re-lock in wait() <0x00000004001f4208> (a java.lang.ProcessImpl)
        at jdk.testlibrary.ProcessTools.executeProcess(ProcessTools.java:381)
        at jdk.testlibrary.ProcessTools.executeProcess(ProcessTools.java:355)
        at JpsHelper.jps(JpsHelper.java:172)
        at JpsHelper.jps(JpsHelper.java:150)
        at TestJpsSanity.testJpsUnknownHost(TestJpsSanity.java:100)
        at TestJpsSanity.main(TestJpsSanity.java:44)
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@10-internal/Native Method)
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@10-internal/NativeMethodAccessorImpl.java:62)
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@10-internal/DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(java.base@10-internal/Method.java:564)
        at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115)
        at java.lang.Thread.run(java.base@10-internal/Thread.java:844)

so the stack trace shows the MainThread is trying to
run the "jps" cmd.

Here's the test's output of the "jps" cmds it was trying to run:

----------System.out:(24/941)----------
[/work/shared/bug_hunt/8167108/SMR_base_10/build/solaris-x86_64-normal-server-release/images/jdk/bin/jps -J-XX:+UsePerfData -?]
usage: jps [-help]
       jps [-q] [-mlvV] [<hostid>]

Definitions:
    <hostid>:      <hostname>[:<port>]

[/work/shared/bug_hunt/8167108/SMR_base_10/build/solaris-x86_64-normal-server-release/images/jdk/bin/jps -J-XX:+UsePerfData -help]
usage: jps [-help]
       jps [-q] [-mlvV] [<hostid>]

Definitions:
    <hostid>:      <hostname>[:<port>]

[/work/shared/bug_hunt/8167108/SMR_base_10/build/solaris-x86_64-normal-server-release/images/jdk/bin/jps -J-XX:+UsePerfData -version]
illegal argument: -version
usage: jps [-help]
       jps [-q] [-mlvV] [<hostid>]

Definitions:
    <hostid>:      <hostname>[:<port>]

[/work/shared/bug_hunt/8167108/SMR_base_10/build/solaris-x86_64-normal-server-release/images/jdk/bin/jps -J-XX:+UsePerfData Oja781nh2ev7vcvbajdg-Sda1-C.invalid]
Timeout signalled after 360 seconds


So that last "jps" cmd is the one that timed out.

Comments

Cannot reproduce
12-07-2021
at JpsHelper.jps(JpsHelper.java:172) at JpsHelper.jps(JpsHelper.java:c150) at TestJpsSanity.testJpsUnknownHost(TestJpsSanity.java:100) at TestJpsSanity.main(TestJpsSanity.java:44) From the above stack trace, the timeout is occuring when executing ProcessTools.executeProcess(processBuilder). This has some similarities to JDK-8194848 where the timeout is occuring when executing ProcessBuilder.start(). Both the bugs are on solaris.
25-01-2018
Update: Just before the Winter holiday I changed my JTREG test execution execution script to use "make run-test" instead of directly invoking jtreg. I also updated my Thread-SMR repos to the 2017.12.14 JDK10 snapshot to verify Thread-SMR testing for the JDK10/18.3 fork. I ran 9 Thread-SMR stress runs over the Winter holiday and did not see this test fail at all: $ grep sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214* do_bld_and_test_all.log.jdk10_hs_20171214:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214_redo:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214_redo:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214_redo:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214_redo2:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214_redo2:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214_redo2:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214_redo3:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214_redo3:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214_redo3:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214_redo4:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214_redo4:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214_redo4:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214_redo5:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214_redo5:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214_redo5:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214_redo6:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214_redo6:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214_redo6:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214_redo7:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214_redo7:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214_redo7:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214_redo8:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214_redo8:Passed: sun/tools/jps/TestJpsSanity.java do_bld_and_test_all.log.jdk10_hs_20171214_redo8:Passed: sun/tools/jps/TestJpsSanity.java The failure was intermittent, but I expected it to show up at least once in this round of Thread-SMR stress testing. I suspect that changing test invocation styles may have "fixed" this, but I have not proven that.
02-01-2018
I have attached the .jtr file from the 'release' bits failure.
15-12-2017