JDK-8152950 : BasicLauncherTest.java fails due to type error
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2016-03-29
  • Updated: 2017-08-17
  • Resolved: 2016-05-27
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 b122Fixed
Related Reports
Relates :  
JDK-8152679 - DeadlockDetectionTest.java fails due to expected output missing
Relates :  
JDK-8157947 - SA: Javascript engine can't access internal packages of jdk.hotspot.agent
Relates :  
JDK-8155009 - [TESTBUG] jstack subtest of BasicLauncherTest should not be executed under OS X
Description
The test sun/tools/jhsdb/BasicLauncherTest.java when attempting to start up the Nashorn Javascript engine. The problem might happen due to the recent integration of Jigsaw.

Here is the output generated by the failure:

Starting clhsdb against 77378
Starting LingeredApp
Command line: ['/export/local/aurora/CommonData/TEST_JAVA_HOME/bin/java' '-cp' '/export/local/aurora/sandbox/results/workDir/classes/0/sun/tools/jhsdb:/export/local/aurora/sandbox/results/workDir/classes/0/lib/testlibrary:/export/local/aurora/sandbox/results/workDir/classes/0/test/lib/share/classes' 'jdk.test.lib.apps.LingeredApp' 'b6f00030-5e58-4ca0-8df6-a4caeaed84fb.lck' ]
Starting jhsdb jstack against 77485
----------System.err:(73/6224)----------
Attaching to process 77378, please wait...
javax.script.ScriptException: TypeError: sapkg.runtime.VM.getVM is not a function in sa.js at line number 54
javax.script.ScriptException: TypeError: sapkg.runtime.VM.getVM is not a function in sa.js at line number 54
Exception in thread "main" java.lang.RuntimeException: javax.script.ScriptException: TypeError: so["has(java.lang.String)"] is not a function in sa.js at line number 133
	at sun.jvm.hotspot.utilities.soql.JSJavaScriptEngine.call(jdk.hotspot.agent@9-internal/JSJavaScriptEngine.java:82)
	at sun.jvm.hotspot.utilities.soql.JSJavaScriptEngine.start(jdk.hotspot.agent@9-internal/JSJavaScriptEngine.java:434)
	at sun.jvm.hotspot.utilities.soql.JSJavaScriptEngine.start(jdk.hotspot.agent@9-internal/JSJavaScriptEngine.java:61)
	at sun.jvm.hotspot.CommandProcessor.postAttach(jdk.hotspot.agent@9-internal/CommandProcessor.java:1750)
	at sun.jvm.hotspot.CommandProcessor.<init>(jdk.hotspot.agent@9-internal/CommandProcessor.java:1788)
	at sun.jvm.hotspot.CLHSDB.run(jdk.hotspot.agent@9-internal/CLHSDB.java:98)
	at sun.jvm.hotspot.CLHSDB.main(jdk.hotspot.agent@9-internal/CLHSDB.java:40)
	at sun.jvm.hotspot.SALauncher.runCLHSDB(jdk.hotspot.agent@9-internal/SALauncher.java:134)
	at sun.jvm.hotspot.SALauncher.main(jdk.hotspot.agent@9-internal/SALauncher.java:334)
Caused by: javax.script.ScriptException: TypeError: so["has(java.lang.String)"] is not a function in sa.js at line number 133
	at jdk.nashorn.api.scripting.NashornScriptEngine.throwAsScriptException(jdk.scripting.nashorn@9-internal/NashornScriptEngine.java:466)
	at jdk.nashorn.api.scripting.NashornScriptEngine.invokeImpl(jdk.scripting.nashorn@9-internal/NashornScriptEngine.java:388)
	at jdk.nashorn.api.scripting.NashornScriptEngine.invokeFunction(jdk.scripting.nashorn@9-internal/NashornScriptEngine.java:189)
	at sun.jvm.hotspot.utilities.soql.JSJavaScriptEngine.call(jdk.hotspot.agent@9-internal/JSJavaScriptEngine.java:78)
	... 8 more
Caused by: sa.js:133 TypeError: so["has(java.lang.String)"] is not a function
	at jdk.nashorn.internal.runtime.ECMAErrors.error(jdk.scripting.nashorn@9-internal/ECMAErrors.java:57)
	at jdk.nashorn.internal.runtime.ECMAErrors.typeError(jdk.scripting.nashorn@9-internal/ECMAErrors.java:213)
	at jdk.nashorn.internal.runtime.ECMAErrors.typeError(jdk.scripting.nashorn@9-internal/ECMAErrors.java:185)
	at jdk.nashorn.internal.runtime.ECMAErrors.typeError(jdk.scripting.nashorn@9-internal/ECMAErrors.java:172)
	at jdk.nashorn.internal.runtime.Undefined.lookup(jdk.scripting.nashorn@9-internal/Undefined.java:105)
	at jdk.nashorn.internal.runtime.linker.NashornLinker.getGuardedInvocation(jdk.scripting.nashorn@9-internal/NashornLinker.java:106)
	at jdk.nashorn.internal.runtime.linker.NashornLinker.getGuardedInvocation(jdk.scripting.nashorn@9-internal/NashornLinker.java:96)
	at jdk.dynalink.linker.support.CompositeTypeBasedGuardingDynamicLinker.getGuardedInvocation(jdk.dynalink@9-internal/CompositeTypeBasedGuardingDynamicLinker.java:184)
	at jdk.dynalink.linker.support.CompositeGuardingDynamicLinker.getGuardedInvocation(jdk.dynalink@9-internal/CompositeGuardingDynamicLinker.java:132)
	at jdk.dynalink.LinkerServicesImpl.lambda$getGuardedInvocation$0(jdk.dynalink@9-internal/LinkerServicesImpl.java:160)
	at jdk.dynalink.LinkerServicesImpl.getWithLookupInternal(jdk.dynalink@9-internal/LinkerServicesImpl.java:191)
	at jdk.dynalink.LinkerServicesImpl.getGuardedInvocation(jdk.dynalink@9-internal/LinkerServicesImpl.java:158)
	at jdk.dynalink.DynamicLinker.relink(jdk.dynalink@9-internal/DynamicLinker.java:262)
	at jdk.nashorn.internal.scripts.Script$Recompilation$24$4193A$sa.main$wrapScriptObject$__has__(jdk.scripting.nashorn.scripts/sa.js:133)
	at jdk.nashorn.internal.scripts.Script$Recompilation$23$5023A$sa$cu1$restOf.main$wrapScriptObject$__get__(jdk.scripting.nashorn.scripts/sa.js:161)
	at jdk.nashorn.internal.scripts.Script$Recompilation$21$2804AA$sa$cu1$restOf.main(jdk.scripting.nashorn.scripts/sa.js:204)
	at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(jdk.scripting.nashorn@9-internal/ScriptFunctionData.java:658)
	at jdk.nashorn.internal.runtime.ScriptFunction.invoke(jdk.scripting.nashorn@9-internal/ScriptFunction.java:513)
	at jdk.nashorn.internal.runtime.ScriptRuntime.apply(jdk.scripting.nashorn@9-internal/ScriptRuntime.java:471)
	at jdk.nashorn.api.scripting.ScriptObjectMirror.callMember(jdk.scripting.nashorn@9-internal/ScriptObjectMirror.java:198)
	at jdk.nashorn.api.scripting.NashornScriptEngine.invokeImpl(jdk.scripting.nashorn@9-internal/NashornScriptEngine.java:382)
	... 10 more
Comments
Date: Thu, 26 May 2016 11:28:43 +0530 From: Sundararajan Athijegannathan <sundararajan.athijegannathan@oracle.com> I had discussed this problem within the nashorn team. And I had discussed this issue with Jini as well. So, I'm CCing this email to nashorn internal alias and India serviceability folks as well. Yes, we have a problem with scripting SA classes. Background: Nashorn uses dynalink library [ http://openjdk.java.net/jeps/276 ] to link invokedynamic call sites. In particular, it uses "beans linker" of dynalink to support Java access from scripts. Dynalink allows only public method, field access of public classes of exported packages only. i.e., only the packages exported to the "world" are allowed to be accessed from scripts. Scripts are compiled and loaded into runtime/dynamic modules [named "jdk.scripting.nashorn.scripts"]. But, dynalink, as a nashorn independent library, uses publicLookup to resolve methods / fields and so can not allow module internal package access. In the non-modular world, the exported package restriction didn't exists. That is the reason why public methods & fields of public SA classes can be accessed from scripts. But, in the modular world, SA packages are module internal to SA's own module [rightfully so! we don't want SA access to the world anyway!]. So, scripts accessing SA classes are broken in modular jdk :( Possible fix: Nashorn supports script-friendly wrappers on Java objects. Any object implementing jdk.nashorn.api.scripting.JSObject [ https://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/JSObject.html ] will be specially linked by Nashorn. Sample: http://hg.openjdk.java.net/jdk9/dev/nashorn/file/59d31c4e3f77/samples/jsobject.js http://hg.openjdk.java.net/jdk9/dev/nashorn/file/59d31c4e3f77/samples/BufferArray.java One possible fix for SA script access is that we could create JSObject wrappers. Obviously, creating wrapper for each-n-every interesting SA class would be too much! So, we could create reflection based wrappers for SA classes, objects, arrays and methods. Just after creating script engine, we could expose function to wrap a SA class/object/array/method as a JSObject. Say, if we expose "SAType" script function that returns a wrapper for SA class, user code can do var VM = SAType("sun.jvm.hotspot.runtime.VM"); // this would return a JSObject wrapper for SA class "VM" // static method calls on VM here.. I know this is a medium sized effort - but can be done. I think we just need 4 classes. JSObjectClassWrapper, JSObjectInstanceWrapper, JSObjectArrayWrapper, JSObjectMethodWrapper -- all using reflection to implement getMember, call, hasMember etc. - each wrapping a SA Java class, Java object, Java array and a Java method respectively.
26-05-2016
Temporary assigning the bug to Dmitry to get it on our radar as the bug returned back to SVC after evaluation. This failure impacts the Main baseline nightly.
18-05-2016
Thanks to Sundar for reproducing and solving the issue. The problem is that Nashorn can only operate on public members of public types of exported packages. Thus, you need to export the sun.jvm.hotspot subpackages that are used in sa.js in the jdk.hotspot.agent to the jdk.scripting.nashorn and jdk.dynalink modules in order to make them accessible to the script. Assigning back to hotspot svc.
29-04-2016
Separate issue JDK-8155009 is filled for OS X stack walking problem
25-04-2016
1) Coredump stack walking is not implemented for OS X (see JDK-8152679) and OS X doesn't allow non-root user to attach so the test detect that it's running not under root and silently bailout. It results that JSTACK subtest on OS X marked as PASSED if it runs under non-root but FAILS if it runs under root. 2) CLHSDB runs fine on build 9-internal+0-2016-03-28-144750.dms.hs-rt but it not able to initialize javascript engine with latest hs (on all platforms). But BasicLauncher test didn't catch the problem - it marked as PASSED.
25-04-2016
[~dsamersoff] Can you please take a look into this issue? Can it be similar to the JDK-8152679 fixed by you? Thank you!
22-04-2016
I don't have an OSX system to test this on. However, we since we don't have any platform native code in Nashorn it is quite unlikely that this is an issue with Nashorn. Following Sundar's suggestion (who I think wrote the original script) I'm reassigning this to the serviceability team.
22-04-2016
Test failed in hs-rt nightly on 2016-04-07. hs-rt was synced with hs main yesterday. Please note that test failed only on OSX platform. Can be this related to JDK-8029590 "SA: pstack implementation is required on macosx to achieve parity with other platforms" and similar test failure on OSX described in JDK-8152679?
08-04-2016
Reopen this issue. Please, verify this test on OSX.
08-04-2016
The test also passes with a current jdk9/hs build for me. It looks like the issue has been fixed, closing as "cannot reproduce". In case it still occurs please reopen with additional information.
07-04-2016
Attaching jtreg output from successful BasicLauncherTest run.
06-04-2016
The test passes for me with a current jdk9/dev build. Do I need a different repository to reproduce this?
06-04-2016