JDK-8055678 : tools/launcher/TestSpecialArgs.java fails on all platforms with Error: invalid param not checked by JVM
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 8u40,9
  • Priority: P2
  • Status: Closed
  • Resolution: Cannot Reproduce
  • Submitted: 2014-08-20
  • Updated: 2014-11-06
  • Resolved: 2014-11-06
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
9Resolved
Related Reports
Duplicate :  
Description
tools/launcher/TestSpecialArgs.java start failing in jdk9-dev nightly since 2014-08-19 on all platforms with Error: invalid param not checked by JVM.

Might this related to JDK-8046598 was integrated?

java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build 1.9.0-ea-langtools-nightly-h1168-20140819-b27)
Java HotSpot(TM) Client VM (build 1.9.0-ea-langtools-nightly-h1168-20140819-b27, mixed mode)

Error message from test log:

Executed command: /Users/aurora/CommonData/jdk/bin/java -XX:NativeMemoryTracking= -version 

###TestError###: string <NativeMemoryTracking:> not found
###TestError###: string <Syntax error, expecting -XX:NativeMemoryTracking=> not found
++++Begin Test Info++++
Test Status: FAIL

...
----------System.err:(12/636)----------
java.lang.RuntimeException: Error: invalid param not checked by JVM
	at TestSpecialArgs.main(TestSpecialArgs.java:178)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:484)
	at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:759)
	at java.lang.Thread.run(Thread.java:745)

JavaTest Message: Test threw exception: java.lang.RuntimeException
JavaTest Message: shutting down test

result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Error: invalid param not checked by JVM
Comments
Closing as CNR
06-11-2014

Please verify with a later build.
12-09-2014

Test passes with 1.8.0_40-ea-b05 and 1.9.0-ea-b30: java version "1.8.0_40-ea" Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b05) Java HotSpot(TM) 64-Bit Server VM (build 25.40-b09, mixed mode) >jtreg TestSpecialArgs.java Directory "JTwork" not found: creating Directory "JTreport" not found: creating Test results: passed: 1 java version "1.9.0-ea" Java(TM) SE Runtime Environment (build 1.9.0-ea-b30) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b30, mixed mode) >jtreg TestSpecialArgs.java Directory "JTwork" not found: creating Directory "JTreport" not found: creating Test results: passed: 1
12-09-2014

George, could you please take a look at this?
12-09-2014

Now that JDK-8054547 is in jdk9/dev, mentioned test passed.
27-08-2014

I'd like to keep this open before JDK-8054547 push to JDK9-dev.
25-08-2014

No, the test is fine, the message is not in the diff. Since MemTracker::check_launcher_nmt_support() is commented out, it fails to trigger the error message.
21-08-2014

It appears to me the test is expecting this error messsage "Syntax error, expecting -XX:NativeMemoryTracking=[off|summary|detail] ", but the changeset you pointed out in JDK-8054547, does not appear to be emitting that message, am I missing something ? or does the launcher test need to be adjusted ?
21-08-2014

Based on Mandy's comment, NMT is integrated after module, so it was testing old NMT command line parameter parsing code.
21-08-2014

So why did the launcher test pass without the changes from modular source ?
21-08-2014

This is due to JDK-8054547 (https://bugs.openjdk.java.net/browse/JDK-8054547) change that has yet made to JDK9/dev, should work once it is integrated.
21-08-2014

To clarify - the modular source change is in jdk9 master repo with no hotspot change. Kumar verifies that jdk9 nightly works. jdk9/dev contains the hotspot integration, the jdk9/dev changes and jdk9/client integration.
21-08-2014

Right, if you see mandy's comments, hotspot changes have come into the dev repository for modular source changes which is causing a very different behavior.
21-08-2014

This is definitely a VM problem, when I substituted the libjvm.so with the one from b26 my build passes, and with the latest VM it fails, a VM change is causing this error.
20-08-2014

but when I test from this /java/re/jdk/9/nightly/b27_2014-08-20-1401_1173/binaries/solaris-x64 it works correctly, which is the latest RE nightly build.
20-08-2014

jdk9/dev also includes hotspot change after the modular source integration and there are a few changesets about NMT e.g. JDK-8046598 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/91eeb8807a03
20-08-2014

The root cause seems to be: JDK-8054834, something in this has broken it.
20-08-2014

This worked before the Modular source integration, something there is causing this to happen.
20-08-2014