JDK-8132850 : java.lang.ArrayIndexOutOfBoundsException during text rendering with many fonts installed
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 7u1
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-08-02
  • Updated: 2018-12-12
  • Resolved: 2015-08-13
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 JDK 9
8u72Fixed 9 b80Fixed
Related Reports
Duplicate :  
Relates :  
Description
When a lot of fonts are installed on a target Linux system, rendering of some characters leads to ArrayIndexOutOfBoundsException.

To reproduce the issue, run the attached simple program after installing texlive package.

Expected result - is that the program runs normally.
Actual result - exception is thrown.

To install texlive:

* On OpenSuSE 13.2 it's enough to install texlive package from distribution's repository.
* On SuSE Linux Enterprise Server 12:

  - download installer from https://www.tug.org/texlive/acquire-netinstall.html
  - run install-tl script, change target installation directory TEXDIR to ~/texlive, complete installation
  - create file ~/.fonts.conf with the following contents:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
  <dir>~/texlive/texmf-dist/fonts</dir>
</fontconfig>

 - run 'fc-cache -f' to update fontconfig caches
 - to verify the procedure, run 'fc-list | grep texlive'. The command should produce non-empty output.

The issue is reproduced with latest java version:
java version "1.8.0_51"
Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)

Additional technical information:
The issue will occur when the number of physical fonts discovered using libfontconfig for a certain logical font is larger than 128.

The only known workaround is decreasing the number of fonts installed in the system. Avoiding the usage of logical fonts in application would also help but it's not easy to achieve.
Comments
There are few issues - the native fontconfig code to accumulate the fonts was resetting the set of glyphs for each time through the loop. thus its heuristic to limit the number of slots was never met and so it would add more slots than it should. In addition it should limit to 256 (or fewer) anyway. - a special case in FileFontStrike accepted a composite glyph id. These use the MS byte of the int to store a slot. Once it was > 127 then the test to see if the glyph was a slot zero glyph failed. Hence the AIIOB. - finally for extra safety the CompositeFont constructor should ignore trailing slots that will not fit.
05-08-2015

The problem is likely related to the one byte we use to store the slot index for a composite font. With fontconfig there may be many fonts in a composite and the heuristics used to limit that may be being defeated by the specific fonts that are installed. I need to look into the details to see which way I would like to solve this.
02-08-2015