JDK-8096998 : [Linux, Font] IllegalArgumentException when trying to open HTMLEditor font name combobox
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 8u20
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-07-08
  • Updated: 2015-06-12
  • Resolved: 2014-07-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8u20Fixed
Related Reports
Relates :  
JDK-8096667 - [Regression, Linux] ArrayIndexOutOfBoundsException when trying to open HTMLEditor font name combobox.
Description
8u20, when trying to open HTMLEditor font name combobox, IllegalArgumentException is reported. The font list is not displayed. 

I don't have a linux test machine which has 3D acceleration enabled, so all tests use SW pipeline.

On one Ubuntu12.04x64, one OEL6.3x86, and one Ubuntu 13.10x86, it shows following exception:
java.lang.IllegalArgumentException: STRIDE * HEIGHT exceeds length of data
	at com.sun.pisces.PiscesRenderer.inputImageCheck(PiscesRenderer.java:429)
	at com.sun.pisces.PiscesRenderer.fillAlphaMask(PiscesRenderer.java:359)
	at com.sun.prism.sw.SWGraphics.drawGlyph(SWGraphics.java:622)
	at com.sun.prism.sw.SWGraphics.drawString(SWGraphics.java:592)
	at com.sun.javafx.sg.prism.NGText.renderText(NGText.java:312)
	at com.sun.javafx.sg.prism.NGText.renderContent2D(NGText.java:270)
	at com.sun.javafx.sg.prism.NGShape.renderContent(NGShape.java:230)
	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2067)
	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959)
......
Comments
Verified fix with 8u40 b20.
06-01-2015
8u20 changeset: http://hg.openjdk.java.net/openjfx/8u20/rt/rev/582d275d227d
09-07-2014
It is a follow on fix from RT-37704 already approved for 8u20. SQE is OK to take it to 8u20.
09-07-2014
Thanks a lot for the prompt fix!
09-07-2014
http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/0539172f0957 changeset: 7447:0539172f0957 tag: tip user: Felipe Heidrich <felipe.heidrich@oracle.com> date: Tue Jul 08 10:06:48 2014 -0700 summary: RT-37856: [Linux, Font] IllegalArgumentException when trying to open HTMLEditor font name combobox
08-07-2014
+1 on the 1st patch, since it is a simple, safe fix.
08-07-2014
Justification: This is a regression in a new feature. We have replaced t2k with native fonts for Linux. Risk: The fix is contained. It is a follow on fix from RT-37704 that prevents the software pipeline from failing. The fix for RT-37704 exposed this problem.
08-07-2014
"I'd be a bit worried of changing code outside of fonts" That is why both my patches are only on fonts. For safety I believe the 1st patch is fine http://cr.openjdk.java.net/~fheidric/RT-37856/webrev/
08-07-2014
This is a regression and we will likely be taking it forward. We need to settle on the fix. If the right fix is in SWGraphics, then the change should be made there. I'd be a bit worried of changing code outside of fonts, that's all. Let's settle on the safest fix and ensure that it fixes this case and the other case that we already took forward.
08-07-2014
This another option for a fix http://cr.openjdk.java.net/~fheidric/RT-37856-2/webrev/ That will get the imageData to pass the checks performed in PiscesRenderer#inputImageCheck() Personally both fixes are fine. I also think that SWGraphics.java should check for pixelData.length==0. It would be more consistent with Prism, and it would save itself some unnecessary work (and it would fix this bug).
08-07-2014
Note: imageData.length==0 is used for white spaces glyphs. These are glyphs that have no image but have horizontal advance. For example, text="ABC". Now assume the error happens when rendering the "B". The old code would render "A C" (assume the space between "A" and "C" is the advance for "B"). The new code will render "AC", cause the routine returns before the advance for error glyph is set (it is left with zero). Note that in this type of error is all likelihood the entire text will disappear.
08-07-2014
Yes, I'll post the fix soon. Our internal API is not well defined, in prism if the glyph returns an empty image data it is simply ignored. SW tests if height*width=data.length. The fix for RT-37704 only made data.length==0 (in the error case), which is good enough for prism. But SW needs data.length AND height=0, width=0.
08-07-2014
Fix: http://cr.openjdk.java.net/~fheidric/RT-37856/webrev/ This will cause "g.getPixelData(subPixel);" to return NULL instead of empty array. PROS: we already NULL in other places, all the caller ignore glyphs when the image data is NULL. CONS: Internally when the imageData is NULL is means the glyph was not initialized, that means the next time someone attempts the render the glyph it will again call the native routine to render it (which will fail again). I tested RT-37856 & RT-37704.
08-07-2014
GlyphCache.java byte[] glyphImage = glyph.getPixelData(subPixel); if (glyphImage == null || glyphImage.length == 0) { //do the work } SWGraphics.java final byte pixelData[] = g.getPixelData(subPixel); if (pixelData != null) { //do the work }
08-07-2014
Felipe, can you make it happen?
08-07-2014
It happens with some font and size combination. Please try attached test case. System + size 11 -16, the exception occur.
08-07-2014
It's a regression comparing with 8. Some findings during testing: 1. On the machine that RT-37704 is reproducible, before fix of RT-37704, a ArrayIndexOutOfBoundsException is reported, but after applying the fix, ClassNotFoundException is reported. There might be something wrong with that machine. 2. On the machines that this bug RT-37856 is reproducible, there is no difference with the fix of RT-37704 or not, IllegalArgumentException is reported in both cases.
08-07-2014
This is similar to RT-37704, but the exceptions is not the same as the exception described RT-37704.
08-07-2014