'Re: [JDK-8223377] Updated information - Webengine crashes when HTML contains japanese/sundanese punc'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: [JDK-8223377] Updated information - Webengine crashes when HTML contains japanese/sundanese punc
From:       Matthias =?ISO-8859-1?Q?Bl=E4sing?= <mblaesing () doppel-helix ! eu>
Date:       2019-05-12 16:27:55
Message-ID: 42ef8fbb1985cfb3d4839b8cc2941627a83afa0c.camel () doppel-helix ! eu
[Download RAW message or body]

Hi Kevin,

thank you for the update of the issue. I had a deeper look at the 
NativeLibLoader code and made an attempt to fix the issue.

I'll send the required review request email shortly.

Greetings

Matthias

Am Samstag, den 11.05.2019, 08:45 -0700 schrieb Kevin Rushforth:
> 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(BaseShade
> > > > > rGraphics.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(GraphicsDecode
> > > > > r.java:301) 
> > > > > 
> > > > > at 
> > > > > com.sun.webkit.graphics.WCRenderQueue.decode(WCRenderQueue.ja
> > > > > va: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:27
> > > > > 0)
> > > > > 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.jav
> > > > > a:479)
> > > > > at 
> > > > > com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.j
> > > > > ava:328)
> > > > > at 
> > > > > com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPai
> > > > > nter.java:91)
> > > > > at 
> > > > > java.base/java.util.concurrent.Executors$RunnableAdapter.call
> > > > > (Executors.java:515)
> > > > > at 
> > > > > java.base/java.util.concurrent.FutureTask.runAndReset(FutureT
> > > > > ask.java:305)
> > > > > at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
> > > > > at 
> > > > > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(T
> > > > > hreadPoolExecutor.java:1128)
> > > > > at 
> > > > > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(
> > > > > ThreadPoolExecutor.java:628)
> > > > > at 
> > > > > com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.ru
> > > > > n(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
> > > > > 


[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic