[JDK-8223377] Updated information - Webengine crashes when HTML contains japanese/sundanese punctuation code points
Kevin Rushforth
kevin.rushforth at oracle.com
Sat May 11 14:15:12 UTC 2019
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:
>>>
>>> <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