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.bate...@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
