Issue in combination with JLink/JPackage

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Wed Jun 8 20:20:38 UTC 2022 

There seems to be a combination of issues here (which seem to have 
little to do with library loading).

In the "only-libraw-working" log, the failure has to do with code trying 
to call the SegmentAllocator.nativeAllocator method, that is no longer 
there (now MemorySession implements SegmentAllocator directly).

In the "nothing-runs" log, I see references to "CLinker" - the class has 
been renamed to "Linker".

It seems to me that the version of jextract you are using to work with 
19 is not correct.

You can get build a version of jextract that works with 19 here:

https://github.com/openjdk/jextract

(for now it has to be built manually, binaries will be made available 
soon - but the process is a lot simpler than building a full JDK)

Hope this helps

Maurizio


On 08/06/2022 19:37, Clemens Lanthaler wrote:

> Hello Maurizio,
>
> here are the logs with all kind of setups. The name of the logfile 
> tells what I have tried. But basically libhheiffx is not working also 
> under JDK19. Librawfx is working if compiled for jdk19 or jdk18.0.1.
>
> What I have seen is that the JVM is no longer been crashing and that 
> the jpackage image produces the same issues than if you run it via 
> maven/IDE.
>
> Hopfully that helps you.
>
> best regards,
> Clemens
>
>
> Am 05.06.22 um 23:29 schrieb Maurizio Cimadamore:
>>
>>
>> On 05/06/2022 11:28, Clemens Lanthaler wrote:
>>> Hello Maurizio,
>>>
>>> I have now updated all my panama project with the Panama Build 
>>> 19-panama+1-13. Now my LibrawFX library is working as expected, but 
>>> my second lib LibHeifFX is not working and shows the same error 
>>> message than before.
>>>
>>> The difference between the two native libs is that LibrawFX is 
>>> thread safe and LibheifFX is not. Maybe the reason for only showing 
>>> the issue on Libheif could be also the loading order.
>>>
>>> From the issue description the fix is already included (build 11) 
>>> but it seems that there is another issue behind it.
>>>
>>> What I did:
>>> - Generate with jextract from Panama Build 19-panama+1-13
>>> - Run with JDK 18.0.1
>>>
>>> Must I run it with JDK 19 to be working ? But if that is the case 
>>> than LibrawFX should not be working as well. Give me feedback if you 
>>> need any logs additionally.
>> Hi Clemens,
>>
>> I believe you need to run with 19 to take advantage of the fix - e.g. 
>> to make sure that System.loadLibrary and Panama library loading truly 
>> act as orthogonal.
>>
>> Let's start from there and see where we get - please post any stack 
>> trace that could be relevant to diagnose this.
>>
>> Thanks
>> Maurizio
>>
>>>
>>> best regards,
>>> Clemens
>>>
>>>
>>> Am 18.02.22 um 23:16 schrieb Maurizio Cimadamore:
>>>>
>>>> Hi Clemens,
>>>> no worries - I will let you know when we have an EA with the fix 
>>>> available (we'll probably wait to accumulate some other 
>>>> fixes/features as well).
>>>>
>>>> Thanks
>>>> Maurizio
>>>>
>>>> On 18/02/2022 22:04, Clemens Lanthaler wrote:
>>>>> Hi,
>>>>> Thanks allot for the info. I have seen that the fix will be part 
>>>>> of JDK19 and frankly speeking I have never build a jdk by myself. 
>>>>> I would appreciate if there is a chance to get a binary of this 
>>>>> pre build including panama.
>>>>>
>>>>> Thank you in advance.
>>>>>
>>>>> best regards,
>>>>> Clemens
>>>>>
>>>>>> Maurizio Cimadamore <maurizio.cimadamore at oracle.com> hat am 
>>>>>> 18.02.2022 15:30 geschrieben:
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>> quick update on this. The problem with library loading in JDK 
>>>>>> being too
>>>>>> strict for Panama has been fixed upstream (thanks Mandy!):
>>>>>>
>>>>>> https://git.openjdk.java.net/jdk/pull/7435
>>>>>>
>>>>>>
>>>>>> We've just merged those changes into the Panama repo - which 
>>>>>> means that,
>>>>>> if you build the latest version of the repo, you should be able to
>>>>>> verify that the workarounds are no longer required.
>>>>>>
>>>>>> Please let us know how that goes.
>>>>>>
>>>>>> Cheers
>>>>>> Maurizio
>>>>>>
>>>>>> On 10/02/2022 10:05, Maurizio Cimadamore wrote:
>>>>>>> I have managed to create a simple reproducer on Windows:
>>>>>>> import jdk.incubator.foreign.CLinker;
>>>>>>> public class TestLookup {
>>>>>>>     public static void main(String[] args) {
>>>>>>> System.load("C:\\Windows\\System32\\ucrtbase.dll");
>>>>>>>         CLinker.systemCLinker().lookup("foo");
>>>>>>>     }
>>>>>>> }
>>>>>>> The call to CLinker::lookup fails with UnsatisfiedLinkError as
>>>>>>> ucrtbase is already loaded by the application class loader.
>>>>>>> This seems to be a bug in the library loading mechanism - we do 
>>>>>>> have a
>>>>>>> "raw" library loading mechanism that is not subject to JNI 
>>>>>>> restrictions:
>>>>>>> https://github.com/openjdk/jdk/blob/309acbf0e86a0d248294503fccc7a936fa0a846e/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L99 
>>>>>>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/309acbf0e86a0d248294503fccc7a936fa0a846e/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java*L99__;Iw!!ACWV5N9M2RV99hQ!bOgtuoBaY3YrzwP16VXj_WbRpiIFGIzLTsiROaXth333Wb6mUx9EzcQleW7Q-4C06fylqx0$> 
>>>>>>>
>>>>>> >
>>>>>>> This library loader ends up calling this method which contains a 
>>>>>>> class
>>>>>>> loader check:
>>>>>>> https://github.com/openjdk/jdk/blob/309acbf0e86a0d248294503fccc7a936fa0a846e/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L203 
>>>>>>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/309acbf0e86a0d248294503fccc7a936fa0a846e/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java*L203__;Iw!!ACWV5N9M2RV99hQ!bOgtuoBaY3YrzwP16VXj_WbRpiIFGIzLTsiROaXth333Wb6mUx9EzcQleW7Q-4C0tN6Z3Vs$> 
>>>>>>>
>>>>>> >
>>>>>>> I believe this loader check should be guarded by a "isJNI" flag, 
>>>>>>> as we
>>>>>>> did for other checks - e.g. whether JNI_OnLoad should be called.
>>>>>>> Cheers
>>>>>>> Maurizio
>>>>>>> On 07/02/2022 12:19, Maurizio Cimadamore wrote:
>>>>>>>> No problem.
>>>>>> >> I've filed this:
>>>>>> >>
>>>>>> >> https://bugs.openjdk.java.net/browse/JDK-8281335
>>>>>> >>
>>>>>> >> Cheers
>>>>>> >> Maurizio
>>>>>> >>
>>>>>> >> On 07/02/2022 12:15, clemens.lanthaler at itarchitects.at wrote:
>>>>>> >>> Hi Maurizio,
>>>>>> >>>
>>>>>> >>> thanks allot for your help and for the investigation.
>>>>>> >>>
>>>>>> >>> best regards,
>>>>>> >>> Clemens
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>> On 7. Feb 2022, at 13:03, Maurizio Cimadamore
>>>>>> >>>> <maurizio.cimadamore at oracle.com> wrote:
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> Hi Clemens (it seems like your message got dropped by the 
>>>>>> mailing
>>>>>> >>>> list, not sure why).
>>>>>> >>>>
>>>>>> >>>> Your message seems to point at some bad interaction between
>>>>>> >>>> jpackage and Panama both trying to load ucrtbase.dll (and 
>>>>>> only one
>>>>>> >>>> can win). Apparently, the Panama code isn't executed early 
>>>>>> enough
>>>>>> >>>> in the jpackage case.
>>>>>> >>>>
>>>>>> >>>> We'll need to investigate more.
>>>>>> >>>>
>>>>>> >>>> Maurizio
>>>>>> >>>>
>>>>>> >>>> On 05/02/2022 15:31, Clemens Lanthaler wrote:
>>>>>> >>>>> Hello everybody,
>>>>>> >>>>>
>>>>>> >>>>> I am the developer of project librawfx
>>>>>> >>>>> (github.com/lanthale/librawfx) and the app Photoslide
>>>>>> >>>>> (github.com/lanthale/photoslide).
>>>>>> >>>>>
>>>>>> >>>>> At the begining of Photoslide the whole app was modularized 
>>>>>> and
>>>>>> >>>>> therefore all was working including librawfx which is using
>>>>>> >>>>> project Panama. After a while I had to change to a mixed
>>>>>> >>>>> (modulepath for jdk+javafx libs and classpath for the rest)
>>>>>> >>>>> environment and deployed my app PhotoSlide again. Under 
>>>>>> Linux and
>>>>>> >>>>> OSX all is working as expected. The problem exists only under
>>>>>> >>>>> Windows. Furthermore it exists only if I am creating a
>>>>>> >>>>> Jlink/Jpackage distribution. Running the app from maven was
>>>>>> >>>>> working as expected. Only the JPackage launcher have the 
>>>>>> issue and
>>>>>> >>>>> I have no clue what the root cause is.
>>>>>> >>>>>
>>>>>> >>>>> The exception I am always seeing is:
>>>>>> >>>>> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load
>>>>>> >>>>> SCHWERWIEGEND: null
>>>>>> >>>>> java.lang.UnsatisfiedLinkError: Native Library
>>>>>> >>>>> C:\Windows\System32\ucrtbase.dll already loaded in another
>>>>>> >>>>> classloader
>>>>>> >>>>> (Full stacktrace below)
>>>>>> >>>>>
>>>>>> >>>>> How can you reproduce the issue:
>>>>>> >>>>>
>>>>>> >>>>>  1. Git clone project 
>>>>>> https://github.com/lanthale/JeditFX.git 
>>>>>> <https://urldefense.com/v3/__https://github.com/lanthale/JeditFX.git__;!!ACWV5N9M2RV99hQ!bOgtuoBaY3YrzwP16VXj_WbRpiIFGIzLTsiROaXth333Wb6mUx9EzcQleW7Q-4C0nxVq_C0$> 
>>>>>>
>>>>>> >>>>>  2. Start the app with "mvn javafx:run at default-cli"
>>>>>> >>>>>  3. Click on the open icon in the toolbar and select file
>>>>>> >>>>> 
>>>>>> "...\Documents\NetBeansProjects\JeditFX\JeditFX\src\main\resources\RAW-ADOBE_DNG_Sample.dng" 
>>>>>>
>>>>>> >>>>>
>>>>>> >>>>>  4. The app is showing the image below the textarea
>>>>>> >>>>>  5. Create the jlink/jpackage app-image with "mvn -Ppackage 
>>>>>> clean
>>>>>> >>>>>     install"
>>>>>> >>>>>  6. Start the exe jeditfx.exe in directory ".\target\jeditfx"
>>>>>> >>>>>  7. Open the same file again -> No image is shown below the 
>>>>>> text
>>>>>> >>>>>     area and the exception is thrown in the background
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>> I have tried many things but it is only happening if I have
>>>>>> >>>>> OpenJFX+JDK Modules on the module path and the rest of the jar
>>>>>> >>>>> files on the classpath. All libs which are not having any 
>>>>>> Panama
>>>>>> >>>>> code inside of the app are working perfectly and it is only
>>>>>> >>>>> happening on Windows.
>>>>>> >>>>>
>>>>>> >>>>> Thank you in advance for your help!
>>>>>> >>>>>
>>>>>> >>>>> best regards,
>>>>>> >>>>> Clemens
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>> *Full stacktrace from Photoslide:*
>>>>>> >>>>>
>>>>>> >>>>> Feb. 03, 2022 7:44:41 PM org.photoslide.search.SearchIndex
>>>>>> >>>>> createSearchIndex
>>>>>> >>>>> INFORMATION: Start time create searchDB: 
>>>>>> 2022-02-03T19:44:41.693455
>>>>>> >>>>> Feb. 03, 2022 7:44:42 PM org.photoslide.SoftwareUpdater
>>>>>> >>>>> lambda$checkForSoftwareUpdates$2
>>>>>> >>>>> INFORMATION: No new version found!
>>>>>> >>>>> Feb. 03, 2022 7:44:43 PM org.photoslide.search.SearchIndex
>>>>>> >>>>> lambda$createSearchIndex$0
>>>>>> >>>>> INFORMATION: End time create searchDB: 
>>>>>> 2022-02-03T19:44:43.186194400
>>>>>> >>>>> Feb. 03, 2022 7:44:58 PM org.librawfx.RAWImageLoader load
>>>>>> >>>>> SCHWERWIEGEND: null
>>>>>> >>>>> java.lang.UnsatisfiedLinkError: Native Library
>>>>>> >>>>> C:\Windows\System32\ucrtbase.dll already loaded in another
>>>>>> >>>>> classloader
>>>>>> >>>>> at
>>>>>> >>>>> 
>>>>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown
>>>>>> >>>>> Source)
>>>>>> >>>>> at
>>>>>> >>>>> 
>>>>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown
>>>>>> >>>>> Source)
>>>>>> >>>>> at
>>>>>> >>>>> 
>>>>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.lambda$makeWindowsLookup$1(Unknown 
>>>>>>
>>>>>> >>>>> Source)
>>>>>> >>>>> at
>>>>>> >>>>> 
>>>>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.libLookup(Unknown 
>>>>>>
>>>>>> >>>>> Source)
>>>>>> >>>>> at
>>>>>> >>>>> 
>>>>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.makeWindowsLookup(Unknown 
>>>>>>
>>>>>> >>>>> Source)
>>>>>> >>>>> at
>>>>>> >>>>> 
>>>>>> jdk.incubator.foreign/jdk.internal.foreign.SystemLookup.(Unknown
>>>>>> >>>>> Source)
>>>>>> >>>>> at
>>>>>> >>>>> 
>>>>>> jdk.incubator.foreign/jdk.incubator.foreign.CLinker.systemLookup(Unknown 
>>>>>>
>>>>>> >>>>> Source)
>>>>>> >>>>> at org.libraw.win.RuntimeHelper.lookup(RuntimeHelper.java:33)
>>>>>> >>>>> at org.libraw.win.libraw_h.(libraw_h.java:15)
>>>>>> >>>>> at
>>>>>> >>>>> 
>>>>>> org.librawfx.LibrawImage.readPixelDataFromStream(LibrawImage.java:113) 
>>>>>>
>>>>>> >>>>>
>>>>>> >>>>> at 
>>>>>> org.librawfx.RAWImageLoader.getImageData(RAWImageLoader.java:168)
>>>>>> >>>>> at org.librawfx.RAWImageLoader.load(RAWImageLoader.java:84)
>>>>>> >>>>> at
>>>>>> >>>>> 
>>>>>> javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown 
>>>>>>
>>>>>> >>>>> Source)
>>>>>> >>>>> at
>>>>>> >>>>> 
>>>>>> javafx.graphics at 18-ea/com.sun.javafx.iio.ImageStorage.loadAll(Unknown 
>>>>>>
>>>>>> >>>>> Source)
>>>>>> >>>>> at
>>>>>> >>>>> 
>>>>>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.loadAll(Unknown 
>>>>>>
>>>>>> >>>>> Source)
>>>>>> >>>>> at
>>>>>> >>>>> 
>>>>>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.PrismImageLoader2.(Unknown 
>>>>>>
>>>>>> >>>>> Source)
>>>>>> >>>>> at
>>>>>> >>>>> 
>>>>>> javafx.graphics at 18-ea/com.sun.javafx.tk.quantum.QuantumToolkit.loadImage(Unknown 
>>>>>>
>>>>>> >>>>> Source)
>>>>>> >>>>> at
>>>>>> >>>>> 
>>>>>> javafx.graphics at 18-ea/javafx.scene.image.Image.loadImage(Unknown
>>>>>> >>>>> Source)
>>>>>> >>>>> at
>>>>>> >>>>> 
>>>>>> javafx.graphics at 18-ea/javafx.scene.image.Image.initialize(Unknown
>>>>>> >>>>> Source)
>>>>>> >>>>> at javafx.graphics at 18-ea/javafx.scene.image.Image.(Unknown 
>>>>>> Source)
>>>>>> >>>>> at
>>>>>> >>>>> 
>>>>>> org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:46) 
>>>>>>
>>>>>> >>>>>
>>>>>> >>>>> at
>>>>>> >>>>> 
>>>>>> org.photoslide.datamodel.MediaFileLoader$1.call(MediaFileLoader.java:43) 
>>>>>>
>>>>>> >>>>>
>>>>>> >>>>> at
>>>>>> >>>>> 
>>>>>> javafx.graphics at 18-ea/javafx.concurrent.Task$TaskCallable.call(Unknown 
>>>>>>
>>>>>> >>>>> Source)
>>>>>> >>>>> at java.base/java.util.concurrent.FutureTask.run(Unknown 
>>>>>> Source)
>>>>>> >>>>> at
>>>>>> >>>>> 
>>>>>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown 
>>>>>>
>>>>>> >>>>> Source)
>>>>>> >>>>> at java.base/java.util.concurrent.FutureTask.run(Unknown 
>>>>>> Source)
>>>>>> >>>>> at
>>>>>> >>>>> 
>>>>>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
>>>>>> >>>>> Source)
>>>>>> >>>>> at
>>>>>> >>>>> 
>>>>>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
>>>>>> >>>>> Source)
>>>>>> >>>>> at java.base/java.lang.Thread.run(Unknown Source)
>>>
>>> -- 
>>> ITArchitects
>>> CEO: B.Sc. Clemens Lanthaler
>>> Forchachstrasse 3
>>> A-6166 Fulpmes
>>> Tel.: +43 (0)650 855 2954
>>> email:office at itarchitects.at
>>> homepage:http://www.itarchitects.at
>>> -------------------------------------------------
>>> Notice: This e-mail and any attachments are confidential and may be privileged.
>>> If you are not the intended recipient, notify the sender immediately, destroy all
>>> copies from your system and do not disclose or use the information for any purpose.
>>> Diese E-Mail inklusive aller Anhaenge ist vertraulich und koennte bevorrechtigtem
>>> Schutz unterliegen. Wenn Sie nicht der beabsichtigte Adressat sind, informieren Sie
>>> bitte den Absender unverzueglich, loeschen Sie alle Kopien von Ihrem System und
>>> veroeffentlichen Sie oder nutzen Sie die Information keinesfalls, gleich zu welchem Zweck.
>
> -- 
> ITArchitects
> CEO: B.Sc. Clemens Lanthaler
> Forchachstrasse 3
> A-6166 Fulpmes
> Tel.: +43 (0)650 855 2954
> email:office at itarchitects.at
> homepage:http://www.itarchitects.at
> -------------------------------------------------
> Notice: This e-mail and any attachments are confidential and may be privileged.
> If you are not the intended recipient, notify the sender immediately, destroy all
> copies from your system and do not disclose or use the information for any purpose.
> Diese E-Mail inklusive aller Anhaenge ist vertraulich und koennte bevorrechtigtem
> Schutz unterliegen. Wenn Sie nicht der beabsichtigte Adressat sind, informieren Sie
> bitte den Absender unverzueglich, loeschen Sie alle Kopien von Ihrem System und
> veroeffentlichen Sie oder nutzen Sie die Information keinesfalls, gleich zu welchem Zweck.

More information about the panama-dev mailing list