[External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?

Andy Herrick andy.herrick at oracle.com
Thu Sep 23 14:05:40 UTC 2021


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.herrick at oracle.com 
>> <mailto:andy.herrick at 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 <swpalmer at gmail.com 
>>>> <mailto:swpalmer at 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.herrick at oracle.com 
>>>>> <mailto:andy.herrick at 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.Bateman at oracle.com <mailto:Alan.Bateman at 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
>


More information about the core-libs-dev mailing list