JDK-8096667 : [Regression, Linux] ArrayIndexOutOfBoundsException when trying to open HTMLEditor font name combobox.
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 8u20
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-06-25
  • Updated: 2015-06-12
  • Resolved: 2014-07-08
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-8096998 - [Linux, Font] IllegalArgumentException when trying to open HTMLEditor font name combobox
Relates :  
JDK-8088943 - [Font] Bitmapped font should not be sub-pixel rendered.
Description
8u20 b19, Linux only, when trying to open HTMLEditor font name combobox, ArrayIndexOutOfBoundsException is reported. The font list is not displayed.

This is a regression reproducible with 8u20. 
8u11 works fine. 
Tested on Ubuntu 12.04, 13.04, OEL6, with SW pipeline. 

java.lang.ArrayIndexOutOfBoundsException: 12
	at com.sun.javafx.font.freetype.FTFontFile.initGlyph(FTFontFile.java:173)
	at com.sun.javafx.font.freetype.FTFontStrike.initGlyph(FTFontStrike.java:82)
	at com.sun.javafx.font.freetype.FTGlyph.init(FTGlyph.java:56)
	at com.sun.javafx.font.freetype.FTGlyph.getPixelData(FTGlyph.java:86)
	at com.sun.prism.sw.SWGraphics.drawGlyph(SWGraphics.java:613)
	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)
	at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235)
	at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576)
	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2067)
	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959)
	at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235)
	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2067)
	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959)
	at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235)
	at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576)
	at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2308)
	at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2202)
	at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2228)
	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2061)
	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959)
	at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235)
	at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576)
	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2067)
	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959)
	at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235)
	at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576)
	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2067)
	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959)
	at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235)
	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2067)
	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959)
	at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235)
	at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576)
	at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2067)
	at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1959)
	at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:474)
	at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:327)
	at com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:135)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
	at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125)
	at java.lang.Thread.run(Thread.java:744)
Comments
Verified fix with 8u40 b20.
06-01-2015
Thanks Kevin. A new bug RT-37856 is filed.
08-07-2014
This looks like a different bug but let's let Felipe decide. Please hurry and enter the new JIRA as this Friday is about the last time that we will be accepting changes (unless absolutely forced to take them).
08-07-2014
I verified that, yes, Hudson build #33 of 8u-cpu-web-sandbox does contain the fix for this bug. Please note that the first of the exceptions you list above is not the same as the exception described in this bug report. You are getting an IllegalArgumentException and not an ArrayIndexOutOfBoundsException, and the exception is in a different method. Please file a new bug. As for the ClassNotFoundException, I expect something is wrong with that system, with your environment, or with your installation of the JDK or FX.
08-07-2014
@Jenny: Please do not reopen a bug for which a changeset is pushed. It is almost never the right thing to do. If you are still seeing a problem, then first let's verify that the build you are running really does contain the fix (I can check), and if it does, then file a new bug.
08-07-2014
But on a Ubuntu13.04 on which I found the bug, after applying the fix, it reports: java.lang.ClassNotFoundException: com.sun.glass.ui.gtk.GtkPlatformFactory at java.net.URLClassLoader$1.run(URLClassLoader.java:372) at java.net.URLClassLoader$1.run(URLClassLoader.java:361) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:360) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:259) at com.sun.glass.ui.PlatformFactory.getPlatformFactory(PlatformFactory.java:42) at com.sun.glass.ui.Application.run(Application.java:148) at com.sun.javafx.tk.quantum.QuantumToolkit.startup(QuantumToolkit.java:255) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:208) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:649) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:669) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$147(LauncherImpl.java:157) at com.sun.javafx.application.LauncherImpl$$Lambda$1/1627292979.run(Unknown Source) at java.lang.Thread.run(Thread.java:745) The error message is quite different from before (in "Description").
08-07-2014
I'm still seeing the bug with build http://jfx.us.oracle.com/hudson/job/8u-cpu-web-sandbox/33/ which says it includes the fix. 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) ......
08-07-2014
8u20 changeset: http://hg.openjdk.java.net/openjfx/8u20/rt/rev/dab88dec3067
30-06-2014
I agree with Steve's justification and risk estimation. SQE is OK to take this fix to 8u20.
27-06-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 checks for a particular error case and does nothing rather than throwing an exception. Doing more at this time is too risky.
26-06-2014
http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/d15c87bbefce changeset: 7366:d15c87bbefce tag: tip user: Felipe Heidrich <felipe.heidrich@oracle.com> date: Thu Jun 26 05:10:59 2014 -0700 summary: RT-37704: [Regression, Linux] ArrayIndexOutOfBoundsException when trying to open HTMLEditor font name combobox.
26-06-2014
Felipe: Go ahead and push to 8u-dev (for 8u40), but leave the bug open. We can take this forward to the R-team as a critical request for 8u20.
26-06-2014
Agreed. +1
26-06-2014
Thanks for the details. I am fine with talking this forward into 8u20. Kevin?
26-06-2014
FYI, it seems we should be able to use http://www.freetype.org/freetype2/docs/reference/ft2-bitmap_handling.html#FT_Bitmap_Convert to fix the FT_PIXEL_MODE_MONO case (I mean, part of the fix).
25-06-2014
Note, the code that copies the bytes from the OS will only work if the pixel format is a 8-bit gray (FT_PIXEL_MODE_GRAY) or 24-bit RGB (FT_PIXEL_MODE_LCD) any other mode is rendering crap. A more comprehensive fix is handle any pixel format returned back and blit it to what prism expected. For example, in order to fix RT-36794 (bitmapped fonts), we will have to handle FT_PIXEL_MODE_MONO. http://cr.openjdk.java.net/~fheidric/RT-37704/webrev/ is the easy & safe fix.
25-06-2014
The pixel modes are doc here http://www.freetype.org/freetype2/docs/reference/ft2-basic_types.html#FT_Pixel_Mode The pixel mode returned depends on (or, is influenced by) the rendering mode set on FT_Render_Glyph() http://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_Render_Mode Note that we don't call FT_Render_Glyph() directly (in case you inspect the code), we use FT_Load_Glyph() passing FT_LOAD_RENDER, which says: "FT_LOAD_RENDER Call FT_Render_Glyph after the glyph is loaded. By default, the glyph is rendered in FT_RENDER_MODE_NORMAL mode. This can be overridden by FT_LOAD_TARGET_XXX or FT_LOAD_MONOCHROME." For grayscale we use FT_LOAD_TARGET_NORMAL, which maps to FT_RENDER_MODE_NORMAL #define FT_LOAD_TARGET_NORMAL FT_LOAD_TARGET_( FT_RENDER_MODE_NORMAL ) For LCD we use #define FT_LOAD_TARGET_LCD FT_LOAD_TARGET_( FT_RENDER_MODE_LCD )
25-06-2014
If we take this fix forward, we need to be 100% sure that we have not blown regular text rendering out of the water. The code change is very small and looks ok. Can you think of another case that might fail? Are there other values that the OS constants that you test for can have? Basically I'm looking for a bit more information about the fix so we can take it forward.
25-06-2014
Webrev http://cr.openjdk.java.net/~fheidric/RT-37704/webrev/ The problem is that javafx is gettign monochromatic image back from freetype (it is font with embedded bitmap for CJK) the fix above ignores the glyph. Safest possible option.
25-06-2014
We need to look at this for 8u20. It is a native text issue.
25-06-2014
It can be reproduced from 8u20 b01.
25-06-2014