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

Scott Palmer swpalmer at gmail.com
Wed Sep 22 14:25:48 UTC 2021


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> 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://jdk.java.net/17/    (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> 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.
>> 
>> /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> 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