[JDK-8223377] Updated information - Webengine crashes when HTML contains japanese/sundanese punctuation code points
Matthias Bläsing
mblaesing at doppel-helix.eu
Sat May 11 13:32:30 UTC 2019
[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(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
> >
More information about the openjfx-dev
mailing list