[JDK-8223377] Updated information - Webengine crashes when HTML contains japanese/sundanese punctuation code points

Matthias Bläsing mblaesing at doppel-helix.eu
Fri May 10 20:23:05 UTC 2019


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:



I experimented with OpenJFX once again and noticed, that even simple
programms crashed for me. I saw the crashes being introduced in maven


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

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:
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.path = /usr/java/packages/lib


    java.library.path = /usr/java/packages/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


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
- the system property was changed to default to use the bundled native

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


More information about the openjfx-dev mailing list