I also had a JDK16 bin dir on my path ...
I can get the error you show below (Error occurred during initialization
of VM) if I clear my PATH, which is different from the error I get when
running without moved runtime, so I can reproduce problem and test the fix.
I am using a script like:
./gradlew.bat clean build
cp -r build/application build/app2
mv build/app2/FetchURL/jre build/app2/FetchURL/runtime
cp FetchURLcfg.save build/app2/FetchURL/app/FetchURL.cfg
export PATH=
echo ""
echo "RUN as built:"
echo ""
build/application/FetchURL/FetchURL
echo ""
echo "RUN with default runtime:"
echo ""
build/app2/FetchURL/FetchURL
after fix both runs should have the same behavior and there should be no
error like:
Error occurred during initialization of VM
Could not find agent library instrument on the library path, with
error: Can't find dependent libraries
Module java.instrument may be missing from runtime image.
/Andy
On 9/22/2021 11:44 AM, Scott Palmer wrote:
On Sep 22, 2021, at 11:22 AM, Andy Herrick <andy.herr...@oracle.com
<mailto:andy.herr...@oracle.com>> wrote:
I still don't get the error your report. Is there something else
that needs to be set up for using instrumentation ?
Nothing that I’m aware of. Maybe there is something to do with Visual
C/C++ runtime libraries that I have installed globally? -just a wild
guess.
Ohhh… here’s something…
I had JDK 17 ‘bin’ folder on my PATH (along with many other things)
If I clear the PATH env var with:
set PATH=
Then I get an different error:
Error occurred during initialization of VM
Could not find agent library instrument on the library path, with
error: Can’t find dependent libraries
Module java.instrument may be missing from runtime image.
All I have to do to et back to the original error is
set PATH=C:\Tools\jdk-17\bin
So this is definitely related to the DLL search path, and it was just
lucky that some libraries were found via PATH in my environment.
I do get a different error when I have both runtime and jre
directories after "cp -r jre runtime" (in
FetchURL/build/application/FetchURL dir)
As built (before copy):
$ ./FetchURL
*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding"
with message c
an't find transform methodID at JPLISAgent.c line: 552
*** java.lang.instrument ASSERTION FAILED ***: "result" at
JPLISAgent.c line: 400
FATAL ERROR in native method: processing of -javaagent failed
after copy:
$ ./FetchURL
Exception in thread "main" java.lang.ClassNotFoundException:
io.m3si.utils.ClassL
oaderUtils$Agent
at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClas
sLoader.java:636)
at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Cl
assLoaders.java:182)
at
java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
at
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAg
ent(InstrumentationImpl.java:433)
at
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPre
main(InstrumentationImpl.java:527)
*** java.lang.instrument ASSERTION FAILED ***: "result" with message
agent load/p
remain call failed at
t:\workspace\open\src\java.instrument\share\native\libinstr
ument\JPLISAgent.c line: 422
FATAL ERROR in native method: processing of -javaagent failed,
processJavaStart f
ailed
but then with jre removed and line in cfg removed I get the same error:
$ ./FetchURL
Exception in thread "main" java.lang.ClassNotFoundException:
io.m3si.utils.ClassLoaderUt
ils$Agent
at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader
.java:636)
at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoad
ers.java:182)
at
java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
at
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(Ins
trumentationImpl.java:433)
at
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(In
strumentationImpl.java:527)
*** java.lang.instrument ASSERTION FAILED ***: "result" with message
agent load/premain
call failed at
t:\workspace\open\src\java.instrument\share\native\libinstrument\JPLISAge
nt.c line: 422
FATAL ERROR in native method: processing of -javaagent failed,
processJavaStart failed
note the "t:\workspace" ? I don't have a t: drive, where is that
coming from ?
Must be from how the JDK was built. I don’t have a T: drive either.
jar -tvf build\application\FetchURL\app\libs\FetchURL-0.0.01.jar
0 Wed Sep 22 11:16:40 EDT 2021 META-INF/
248 Wed Sep 22 11:16:40 EDT 2021 META-INF/MANIFEST.MF
0 Wed Sep 22 11:10:30 EDT 2021 io/
0 Wed Sep 22 11:10:30 EDT 2021 io/m3si/
0 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/
0 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/fetchurl/
3988 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/fetchurl/Main.class
1000 Wed Sep 22 11:10:30 EDT 2021
io/m3si/utils/ClassLoaderUtils$Agent.class
4613 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/ClassLoaderUtils.class
I extracted MANIFEST.MF just to be sure …
Manifest-Version: 1.0
Implementation-Title: Kayak Plugins Bootstrap
Premain-Class: io.m3si.utils.ClassLoaderUtils$Agent
Implementation-Version: 1.0.1
Agent-Class: io.m3si.utils.ClassLoaderUtils$Agent
Main-Class: io.m3si.utils.fetchurl.Main
Looks right to me.
Scott
/Andy
On 9/22/2021 10:25 AM, Scott Palmer wrote:
Sorry That last build with the Oracle OpenJDK needed the build file
changed to have
vendor = JvmVendorSpec.ORACLE
as well as the command line property pointing to the path to the jdk,
Scott
On Sep 22, 2021, at 10:24 AM, Scott Palmer <swpal...@gmail.com
<mailto:swpal...@gmail.com>> wrote:
I reproduced it with the AZUL's distribution of OpenJDK (with
JavaFX modules bundled) and I just changed:
vendor = JvmVendorSpec.ADOPTOPENJDK
And get the same error with that build of OpenJDK as well.
“OpenJDK Runtime Environment Temurin-17+35 (build 17+35)”
You can try that, as Gradle should download the JDK for you.
I then downloaded the Oracle build of OpenJDK
fromhttps://urldefense.com/v3/__https://jdk.java.net/17/__;!!ACWV5N9M2RV99hQ!eG4msXvYMONuZH2PKW1Mddol9UY2VkepPpI36eTZz9c_70fXHLm84-lrbzZBwkTMGA$
<https://urldefense.com/v3/__https://jdk.java.net/17/__;!!ACWV5N9M2RV99hQ!eG4msXvYMONuZH2PKW1Mddol9UY2VkepPpI36eTZz9c_70fXHLm84-lrbzZBwkTMGA$> (build
17+35-2724)
unzipped it to C:\Tools
building with:
gradlew -Porg.gradle.java.installations.paths=C:\Tools\jdk-17 clean
build
I still reproduce the error.
Though the assertion in native JVM code that you are getting looks
like yet another bug! So perhaps it is good that it is discovered
as well.
Scott
On Sep 22, 2021, at 9:54 AM, Andy Herrick <andy.herr...@oracle.com
<mailto:andy.herr...@oracle.com>> wrote:
I can't seem to get your testcase to work with the Oracle JDK
configured.
I can build, but then when I run
$ ./build/application/FetchURL/FetchURL.exe
I get:
*** java.lang.instrument ASSERTION FAILED ***:
"!errorOutstanding" with message c
an't find transform methodID at JPLISAgent.c line: 552
*** java.lang.instrument ASSERTION FAILED ***: "result" at
JPLISAgent.c line: 400
FATAL ERROR in native method: processing of -javaagent failed
same behavior if I restore "runtime" directory and fix
FetchURL.cfg to remove app.runtime entry.
anyway I used your two source files to build the test app without
gradle, and the test can
downloadhttps://urldefense.com/v3/__https://linear-89.frequency.stream/dist/localnow/89/hls/master/playlist.m3u8__;!!ACWV5N9M2RV99hQ!eG4msXvYMONuZH2PKW1Mddol9UY2VkepPpI36eTZz9c_70fXHLm84-lrbzbGSGkGog$
<https://urldefense.com/v3/__https://linear-89.frequency.stream/dist/localnow/89/hls/master/playlist.m3u8__;!!ACWV5N9M2RV99hQ!eG4msXvYMONuZH2PKW1Mddol9UY2VkepPpI36eTZz9c_70fXHLm84-lrbzbGSGkGog$> without
any problems.
I then moved runtime to jre and added line
"app.runtime=$APPDIR/../jre" to cfg file and app still ran fine
(downloaded the above)
So I still don't have any way to reproduce this problemwith the
Oracle jdk.
/Andy
PS:
Although something somewhere else may have changed to counter the
problem, it's clear from your description, that since the only
place in the code the default runtime path is used (instead of the
actual runtime path, which may be different) is the line in
WinLauncher.cpp to call SetDllDirectory().
This should be fixed - but would like a way to reproduce the
problem it causes first.
/Andy
On 9/21/2021 12:12 PM, Andy Herrick wrote:
I thought I could create a reproduction scenario by using an app
with "-splash:<image file>" arg then moving the jre as you did,
but I have not yet been able make it fail.
/Andy
On 9/21/2021 11:43 AM, Scott Palmer wrote:
On Sep 21, 2021, at 11:40 AM, Alan Bateman
<alan.bate...@oracle.com <mailto:alan.bate...@oracle.com>> wrote:
On 21/09/2021 15:54, Andy Herrick wrote:
I found the problem in
open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp
we call SetDllDirectory() with the path to the bin dir in the
default runtime directory, not the actual runtime directory.
since on Windows we never use other than the default runtime
location - we had not seen a problem, but is bug I will file
and fix.
Good to see that you found it quickly. However I'm puzzled as
why initializingEncoding wasn't called, I would have expected
the VM to blow up during early startup. Would you have cycles
to dig into that a bit more in case something has been masked,
like for example an exception being swallowed. Running with
-Xlog:exceptions might reveal something.
Do you have a case that reproduces the issue?
Scott
