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