[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