JDK-8167001 : [TESTBUG] java/lang/instrument/DaemonThread/TestDaemonThread.java fails when run by jprt
  • Type: Bug
  • Component: core-svc
  • Sub-Component: java.lang.instrument
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-10-01
  • Updated: 2016-11-04
  • Resolved: 2016-10-18
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 9
9 b143Fixed
Related Reports
Relates :  
JDK-8161225 - Assert failure in JVMTI GetNamedModule at JPLISAgent.c line: 792
Sub Tasks
JDK-8167026 :  
Quarantine TestDaemonThread.java - Resolved
JDK-8167034 :  
Re-enable TestDaemonThread.java once JDK-8167001 is fixed - Resolved
Description
One of the changes done for JDK-8161225 was to have it properly check the exit value of subprocesses it creates. Previously it just made sure there was no ASSERT message in the output. The extra check is catching failures (presumably pre-existing) that only seem to turn up with run under jprt, and for that matter only when run with a batch of tests (using jdk_instrument test group or jdk/test/java/lang/instrument path). It does not fail standalone under jprt, and it does not fail when run under RBT, even as part of a batch.

The failure seems to be classpath related, and is causing TestDaemonThreadLauncher not to be able to find TestDaemonThread when it launches it as a subprocess.
Comments
...and adding "othervm" to the @run line fixes the problem, both for the makefile case, and also if you run from the command line while specifying -agentvm.
03-10-2016
...and when run from the command line and specifying -agentvm, it also fails.
03-10-2016
agentvm for the failed case (run with makefile). othervm for the passing case (run from command line). Neither the test nor the jtreg command line specify the mode. I can attach .jtr files if you still want them.
03-10-2016
Chris, Can you report back the following: In the two cases where you run jtreg directly, or you run tests with the Makefile, can you identify which "mode" is being used -- agentvm mode or othervm/default mode? jtreg does have some crufty code in it to force CLASSPATH to be set, and I'm wondering if that is coming into play. I did try and remove that code a somewhat-long while back, but it broke some tests, which were relying on CLASSPATH being set. If you can't easily determine that, could you at least post .jtr files from the two cases?
03-10-2016
Yes, I understand that. My question why does the test makefile invocation of jtreg tests use -classpath, but the jtreg command line invocation we normally use results in using CLASSPATH?
03-10-2016
The is not a jtreg issue so much as a shell and JVM issue. -classpath is an option that only exists on the command line, and has no impact on any environment variables, and no persistent effect on the JVM except to set the classpath of the JVM. CLASSPATH, on the other hand, is an environment variable, and has a persistent effect. In particular, starting a (JVM) process is likely to look at the env variable if -classpath is not set. For more info, refer to documentation about the Java launcher.
03-10-2016
Looks like the makefile invocation is the cause. Both of the following fail in the same way if run locally: make jtreg_tests TESTDIRS=java/lang/instrument/DaemonThread/ PRODUCT_HOME=<dir> make jdk_instrument PRODUCT_HOME=<dir> For some reason invoking from the makefile changes how the test is run. This is what it looks like when not using the makefile (running jtreg directly): PATH=/bin:/usr/bin \ XMODIFIERS=@im=none \ CLASSPATH=/local/ws/jdk9/hs3/jdk/test/JTwork/classes/java/lang/instrument/DaemonThread:/local/ws/jdk9/hs3/jdk/test/java/lang/instrument/DaemonThread:/local/ws/jdk9/hs3/jdk/test/JTwork/classes/lib/testlibrary:/local/ws/jdk9/hs3/jdk/test/lib/testlibrary:/net/scanas416.us.oracle.com/export/java_re2/misc/promoted/jtreg/4.2/fcs/b03/binaries/jtreg/lib/javatest.jar:/net/scanas416.us.oracle.com/export/java_re2/misc/promoted/jtreg/4.2/fcs/b03/binaries/jtreg/lib/jtreg.jar \ /myws/jdk9/hs3/build/linux-x64-debug/images/jdk/bin/java \ <snip> com.sun.javatest.regtest.agent.MainWrapper /local/ws/jdk9/hs3/jdk/test/JTwork/java/lang/instrument/DaemonThread/TestDaemonThread.d/main.2.jta And when using the makefile: PATH=/bin:/usr/bin \ XMODIFIERS=@im=none \ /local/ws/jdk9/hs3/build/linux-x64-debug/images/jdk/bin/java \ <snip> -classpath /local/ws/jdk9/hs3/jdk/testoutput/JTwork/classes/java/lang/instrument/DaemonThread:/local/ws/jdk9/hs3/jdk/test/java/lang/instrument/DaemonThread:/local/ws/jdk9/hs3/jdk/testoutput/JTwork/classes/lib/testlibrary:/local/ws/jdk9/hs3/jdk/test/lib/testlibrary:/net/scanas416.us.oracle.com/export/java_re2/misc/promoted/jtreg/4.2/fcs/b03/binaries/jtreg/lib/javatest.jar:/net/scanas416.us.oracle.com/export/java_re2/misc/promoted/jtreg/4.2/fcs/b03/binaries/jtreg/lib/jtreg.jar \ TestDaemonThreadLauncher So in one case CLASSPATH is exported/imported, and it looks like it makes it to the subprocesses because of that. In the other, -classpath is passed in, and the classpath only makes it to the subprocesses if you tell ProcessTools.createJavaProcessBuilder() to do so. Actually that's only true for jdk/test. For hotspot/test the the classpath is always passed to the subprocess.
01-10-2016
The problem is fixed by changing the test to pass "true" for the first argument to ProcessTools.createJavaProcessBuilder(). This will cause it to add "addTestVmAndJavaOptions", which includes -cp of the java.class.path property. After doing this and running the test locally, I noticed the test output that is produced when attempting to spawn the subprocess changed from: Command line: [/myws/jdk9/hs3/build/linux-x64-debug/images/jdk/bin/java -javaagent:DummyAgent.jar TestDaemonThread . ] to: Command line: [/myws/jdk9/hs3/build/linux-x64-debug/images/jdk/bin/java -cp /local/ws/jdk9/hs3/JTwork/classes/java/lang/instrument/DaemonThread:/local/ws/jdk9/hs3/jdk/test/java/lang/instrument/DaemonThread:/local/ws/jdk9/hs3/JTwork/classes/lib/testlibrary:/local/ws/jdk9/hs3/jdk/test/lib/testlibrary:/net/scanas416.us.oracle.com/export/java_re2/misc/promoted/jtreg/4.2/fcs/b03/binaries/jtreg/lib/javatest.jar:/net/scanas416.us.oracle.com/export/java_re2/misc/promoted/jtreg/4.2/fcs/b03/binaries/jtreg/lib/jtreg.jar -server -javaagent:DummyAgent.jar TestDaemonThread . ] This makes sense, and I can see why it would fix problems (presumably the subprocess was not being setup with the proper classpath), but still doesn't explain why this issue only turned up when running in jprt with a batch of tests. It must have something to do with the makefile invocation of jtreg.
01-10-2016