[External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?
swpalmer at gmail.com
Wed Sep 22 14:24:04 UTC 2021
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://jdk.java.net/17/ (build 17+35-2724)
unzipped it to C:\Tools
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.
> On Sep 22, 2021, at 9:54 AM, Andy Herrick <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 download https://linear-89.frequency.stream/dist/localnow/89/hls/master/playlist.m3u8 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.
> 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.
> 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.
>> 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> 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?
More information about the core-libs-dev