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

[Matthias Bläsing]

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