[External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?
andy.herrick at oracle.com
Wed Sep 22 13:54:20 UTC 2021
I can't seem to get your testcase to work with the Oracle JDK configured.
I can build, but then when I run
> *** 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
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
This should be fixed - but would like a way to reproduce the problem it
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>
>>> On 21/09/2021 15:54, Andy Herrick wrote:
>>>> I found the problem in
>>>> 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