> On Sep 22, 2021, at 11:22 AM, Andy Herrick <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> 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$
>>>
>>> <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 download
>>>> https://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>
>>>>>>> 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
