Re: [JDK-8223377] Updated information - Webengine crashes when HTML contains japanese/sundanese punctuation code points
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
Re: [JDK-8223377] Updated information - Webengine crashes when HTML contains japanese/sundanese punctuation code points
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: org.openjfx javafx-controls 12-ea+7 org.openjfx javafx-web 12-ea+7 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
Re: [JDK-8223377] Updated information - Webengine crashes when HTML contains japanese/sundanese punctuation code points
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: org.openjfx javafx-controls 12-ea+7 org.openjfx javafx-web 12-ea+7 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
Re: [JDK-8223377] Updated information - Webengine crashes when HTML contains japanese/sundanese punctuation code points
[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: > > > > > > org.openjfx > > javafx-controls > > 12-ea+7 > > > > > > org.openjfx > > javafx-web > > 12-ea+7 > > > > > > 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
Re: [JDK-8223377] Updated information - Webengine crashes when HTML contains japanese/sundanese punctuation code points
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: org.openjfx javafx-controls 12-ea+7 org.openjfx javafx-web 12-ea+7 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
[JDK-8223377] Updated information - Webengine crashes when HTML contains japanese/sundanese punctuation code points
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: org.openjfx javafx-controls 12-ea+7 org.openjfx javafx-web 12-ea+7 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
