I still don't get the error your report. Is there something else that
needs to be set up for using instrumentation ?
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 ?
/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> 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 from
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> 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 download
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> 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
