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(BaseShaderGraphics.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(GraphicsDecoder.java:301) at com.sun.webkit.graphics.WCRenderQueue.decode(WCRenderQueue.java: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:270) 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.java:479) at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:328) at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(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
