Hi Kevin, thank you for the update of the issue. I had a deeper look at the NativeLibLoader code and made an attempt to fix the issue.
I'll send the required review request email shortly. Greetings Matthias Am Samstag, den 11.05.2019, 08:45 -0700 schrieb Kevin Rushforth: > Based on the additional info I raised the priority of JDK-8223377 [1] to > P3 and targeted it to openjfx13. I filed JDK-8223746 [2] to track the > request to check the version the native libraries (not targeted to a > particular release). > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8223377 > [2] https://bugs.openjdk.java.net/browse/JDK-8223746 > > > On 5/11/2019 7:15 AM, Kevin Rushforth wrote: > > Hi Matthias, > > > > I was not aware that Ubuntu distributed a standalone JavaFX > > library, > > so yes that explains the problem. > > > > I will file an RFE to add the native / class file versioning > > checks > > that you mentioned, but that's likely to be a bit of work, since I > > think it would be worth doing only if done as part of the initial > > load > > library in such a way that when it fails, it considers it a failed > > load (and moves on to the next method of finding the libraries > > (although there is still some value in early detection and a > > thrown > > exception with a reasonable error message versus the crash that > > happens today). > > > > I think the best short-term solution is your suggestion of > > changing > > the order of precedence such that System.loadLibrary is last, which > > is > > more in keeping with what we do when running the SDK: the > > libraries > > associated with the class files should be used in preference to > > the > > system libraries. > > > > -- Kevin > > > > > > On 5/11/2019 6:32 AM, Matthias Bläsing wrote: > > > [Resend to Mailinglist, I'm subscribed and did not see, that it > > > was > > > directly send to me] > > > > > > Hi Kevin, > > > > > > the problem on Ubuntu is this: When you install a package, that > > > requires OpenJFX (for example mediathekview), the package > > > libopenjfx-jni is installed as a dependency. > > > > > > The package libopenjfx-jni installs the OpenJFX native libraries > > > into > > > the folder /usr/lib/x86_64-linux-gnu/jni. This is all good if you > > > are > > > only using distribution libraries, but when using a third-party > > > application, that requires JavaFX, it breaks. In my case this is > > > Apache > > > NetBeans, that can't even bundle a JVM (ASF requirement), so > > > using the > > > system VM is the logical choice. > > > > > > The problem is in > > > com.sun.glass.utils.NativeLibLoader#loadLibraryInternal. > > > The native libraries are loaded: > > > > > > - from filesstem in the same folder as the jar > > > - via System#loadLibrary > > > - extracted from the resources of the jar > > > > > > The options are tried in that order and the first successful > > > wins. > > > > > > In my case instead of loading the working native libraries from > > > the > > > maven > > > jars, the system ones are picked up via System#loadLibrary. This > > > means, > > > I get the OpenJFX native libraries for 11.0.2 with the OpenJFX > > > java > > > classes of 13-ea+7 (for the newest variant). This is obvisually a > > > bad > > > idea (the crash shows that clearly). > > > > > > For JNA two thinks are done: The native libraries are versioned > > > independently > > > from the java classes and after loading the library the java > > > part > > > checks if > > > a compatible native library was loaded (same major, same or > > > higher minor > > > version). The java classes embedd the version of the native > > > library they > > > expect and the native library embeds its real version, so > > > mismatches > > > can be > > > detected before the JVM blows. > > > > > > Another difference: Today JNA prefers its bundled native library > > > if not > > > requested differently via system property. For desktop systems > > > JNA > > > now tries > > > to load the library first from the JAR and only falls back to > > > system > > > libraries, > > > if that fails. > > > > > > > > > Does this clear up the situation a bit? > > > > > > > > > Greetings > > > > > > Matthias > > > > > > > > > Am Freitag, den 10.05.2019, 13:50 -0700 schrieb Kevin Rushforth: > > > > The normal submission process yielded a bug report to be > > > > evaluated, and > > > > it's still in the queue to be looked at. Since you provided > > > > some > > > > additional information, we can add it to the bug report as a > > > > comment. > > > > Btw, the direct URL for the bug in JBS is: > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8223377 > > > > > > > > From your aditional comments, it sounds as if this is some > > > > sort of > > > > system configuration issue. Unless there are JavaFX classes or > > > > .so > > > > files > > > > in your JDK (which is not supported with OpenJFX 11 or > > > > greater), I > > > > don't > > > > know how you would see the mismatch between the javafx.web > > > > class files > > > > and the jfxwebkit.so native library. > > > > > > > > -- Kevin > > > > > > > > > > > > On 5/10/2019 1:23 PM, Matthias Bläsing wrote: > > > > > Hello, > > > > > > > > > > as the normal submission process did not yield an update for > > > > > the > > > > > above > > > > > mentioned issue and this is a crasher, I try to get the > > > > > information > > > > > submitted here. > > > > > > > > > > As reference the JDK issue: > > > > > > > > > > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8223377 > > > > > > > > > > Summary: > > > > > > > > > > I experimented with OpenJFX once again and noticed, that even > > > > > simple > > > > > programms crashed for me. I saw the crashes being introduced > > > > > in > > > > > maven > > > > > release: > > > > > > > > > > <dependency> > > > > > <groupId>org.openjfx</groupId> > > > > > <artifactId>javafx-controls</artifactId> > > > > > <version>12-ea+7</version> > > > > > </dependency> > > > > > <dependency> > > > > > <groupId>org.openjfx</groupId> > > > > > <artifactId>javafx-web</artifactId> > > > > > <version>12-ea+7</version> > > > > > </dependency> > > > > > > > > > > Until that version this stack trace is generated: > > > > > > > > > > java.lang.ArrayIndexOutOfBoundsException: Index -17 out of > > > > > bounds > > > > > for length 32 > > > > > at > > > > > com.sun.prism.impl.GlyphCache.getCachedGlyph(GlyphCache.java: > > > > > 332) > > > > > at > > > > > com.sun.prism.impl.GlyphCache.render(GlyphCache.java:148) > > > > > at > > > > > com.sun.prism.impl.ps.BaseShaderGraphics.drawString(BaseShade > > > > > rGraphics.java:2101) > > > > > at > > > > > com.sun.javafx.webkit.prism.WCGraphicsPrismContext$10.doPaint > > > > > (WCGraphicsPrismContext.java:939) > > > > > at > > > > > com.sun.javafx.webkit.prism.WCGraphicsPrismContext$Composite. > > > > > paint(WCGraphicsPrismContext.java:1524) > > > > > at > > > > > com.sun.javafx.webkit.prism.WCGraphicsPrismContext$Composite. > > > > > paint(WCGraphicsPrismContext.java:1509) > > > > > at > > > > > com.sun.javafx.webkit.prism.WCGraphicsPrismContext.drawString > > > > > (WCGraphicsPrismContext.java:951) > > > > > at > > > > > com.sun.webkit.graphics.GraphicsDecoder.decode(GraphicsDecode > > > > > r.java:301) > > > > > > > > > > at > > > > > com.sun.webkit.graphics.WCRenderQueue.decode(WCRenderQueue.ja > > > > > va:92) > > > > > at com.sun.webkit.WebPage.paint2GC(WebPage.java:736) > > > > > at com.sun.webkit.WebPage.paint(WebPage.java:703) > > > > > at > > > > > com.sun.javafx.sg.prism.web.NGWebView.renderContent(NGWebView > > > > > .java:95) > > > > > at > > > > > com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > > > > > at > > > > > com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > > > > > at > > > > > com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:27 > > > > > 0) > > > > > at > > > > > com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java: > > > > > 578) > > > > > at > > > > > com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > > > > > at > > > > > com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > > > > > at > > > > > com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.jav > > > > > a:479) > > > > > at > > > > > com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.j > > > > > ava:328) > > > > > at > > > > > com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPai > > > > > nter.java:91) > > > > > at > > > > > java.base/java.util.concurrent.Executors$RunnableAdapter.call > > > > > (Executors.java:515) > > > > > at > > > > > java.base/java.util.concurrent.FutureTask.runAndReset(FutureT > > > > > ask.java:305) > > > > > at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > > > > > at > > > > > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(T > > > > > hreadPoolExecutor.java:1128) > > > > > at > > > > > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run( > > > > > ThreadPoolExecutor.java:628) > > > > > at > > > > > com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.ru > > > > > n(QuantumRenderer.java:125) > > > > > at java.base/java.lang.Thread.run(Thread.java:834) > > > > > > > > > > I tried to corner the problem and noticed, that the crash is > > > > > _not_ > > > > > reproducible with the java binary from jdk.java.net. The > > > > > crash is also > > > > > not reproducible with a Ubuntu Live CD with only the default- > > > > > jre > > > > > installed. > > > > > > > > > > Then I tried to align the live environment (does not crash) > > > > > with my > > > > > desktop system (OpenJFX crashes). And finally I found the > > > > > problem. > > > > > > > > > > 1. Get the Xubuntu 19.04 live CD: > > > > > http://torrent.ubuntu.com/xubuntu/releases/disco/release/desktop/xubuntu-19.04-desktop-amd64.iso.torrent > > > > > 2. Start the Image (Try Xubuntu) in VirtualBox > > > > > 3. Install the default JDK (that will be 11.0.3) and maven: > > > > > sudo apt install default-jdk maven git > > > > > 4. Clone the reproducer repository: > > > > > git clone > > > > > https://github.com/matthiasblaesing/reproduce-openjfx-crash.git > > > > > 5. Build it: > > > > > cd reproduce-openjfx-crash > > > > > mvn package > > > > > 6. Run with: > > > > > java -jar target/reproduce-openjfx-crash.jar > > > > > > > > > > => Window with the title "Hello World!", the text "Test" and > > > > > japanese/sudanese punctuation symbols are shown > > > > > => In the console, you see, that the native libraries are > > > > > loaded > > > > > from resource > > > > > > > > > > 7. Close windows > > > > > 8. Install openjfx JNI libraries: > > > > > apt install libopenjfx-jni > > > > > 9. Run again with: > > > > > java -jar target/reproduce-openjfx-crash.jar > > > > > > > > > > => Window is briefly displayed > > > > > => On the console a SEGFAULS is logged (and hs_err_pid... is > > > > > written) > > > > > => You can read, that the native libraries were loaded via > > > > > System#loadLibrary > > > > > > > > > > ----------------------------------------------------------- > > > > > --------- > > > > > > > > > > This result also explains why the problem is not visible with > > > > > the > > > > > binaries from jdk.java.net: The java executables use > > > > > different > > > > > java.library.paths: > > > > > > > > > > Ubuntu: > > > > > > > > > > java.library.path = /usr/java/packages/lib > > > > > /usr/lib/x86_64-linux-gnu/jni > > > > > /lib/x86_64-linux-gnu > > > > > /usr/lib/x86_64-linux-gnu > > > > > /usr/lib/jni > > > > > /lib > > > > > /usr/lib > > > > > > > > > > OpenJDK: > > > > > > > > > > java.library.path = /usr/java/packages/lib > > > > > /usr/lib64 > > > > > /lib64 > > > > > /lib > > > > > /usr/lib > > > > > > > > > > As contents of the libopenjfx-jni package is installed to > > > > > /usr/lib/x86_64-linux-gnu/jni/, only the Ubuntu java launcher > > > > > finds > > > > > the > > > > > binaries. > > > > > > > > > > ----------------------------------------------------------- > > > > > --------- > > > > > > > > > > It is not too surprising, that the native libraries and the > > > > > java > > > > > implementations are tightly coupled. For the JNA project we > > > > > are faced > > > > > with the same situation. However, there are differences: > > > > > > > > > > - the JNA project checks, that the native libraries are > > > > > of a compatible version > > > > > - there is a system property, that lets the user choose > > > > > whether > > > > > system libraries should be used or the bundled native > > > > > libraries be > > > > > extracted > > > > > - the system property was changed to default to use the > > > > > bundled native > > > > > libraries > > > > > > > > > > I had a quick look at the NativeLibraryLoader and don't see a > > > > > similar > > > > > mechanism. The only work around I found was overriding the > > > > > java.library.path, but that requires changes to the launch > > > > > sequence of > > > > > the VM. > > > > > > > > > > > > > > > For a managed language, I don't think a segfault is a valid > > > > > result for > > > > > loading HTML and thus should not be just a P4. It is not > > > > > uncommon to > > > > > have the distribution libraries installed, so I expect the > > > > > problem to > > > > > be present on more systems. > > > > > > > > > > > > > > > Thank you > > > > > > > > > > Matthias > > > > >
