Bug 1484079

Summary: AWT java apps fail to start when stix-fonts is used as sans-serif font
Product: Red Hat Enterprise Linux 7 Reporter: Viktor Ashirov <vashirov>
Component: java-1.8.0-openjdkAssignee: Andrew John Hughes <ahughes>
Status: CLOSED ERRATA QA Contact: Lukas Zachar <lzachar>
Severity: high Docs Contact:
Priority: unspecified    
Version: 7.4CC: ahughes, ajipatil, ayadav, bviktor, cbucur, dbhole, dkochuka, hajek, jvanek, neugens, pandrade, qguo, skeens_kristi, theophanis_kontogiannis
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: java-1.8.0-openjdk-1.8.0.144-2.b01.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-10 11:50:25 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 1479563    
Attachments:
Description Flags
reproducer
none
candidate fix none

Description Viktor Ashirov 2017-08-22 12:00:33 EDT
Description of problem:
When the following set of fonts is installed on a system, AWT java apps refuse to start
# rpm -qa  | grep fonts
xorg-x11-fonts-Type1-7.5-9.el7.noarch
stix-fonts-1.1.0-5.el7.noarch

Version-Release number of selected component (if applicable):
java-1.8.0-openjdk-1.8.0.131-11.b12.el7.x86_64

How reproducible:
Deterministically 

Steps to Reproduce:
1. Install a fresh RHEL7.4
2. Install 389-console (from EPEL or RHDS repo)
3. Run 389-console

Actual results:
$ 389-console
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
	at sun.font.CompositeStrike.getStrikeForSlot(CompositeStrike.java:75)
	at sun.font.CompositeStrike.getFontMetrics(CompositeStrike.java:93)
	at sun.font.FontDesignMetrics.initMatrixAndMetrics(FontDesignMetrics.java:359)
	at sun.font.FontDesignMetrics.<init>(FontDesignMetrics.java:350)
	at sun.font.FontDesignMetrics.getMetrics(FontDesignMetrics.java:302)
	at sun.swing.SwingUtilities2.getFontMetrics(SwingUtilities2.java:1113)
	at javax.swing.JComponent.getFontMetrics(JComponent.java:1626)
	at javax.swing.plaf.basic.BasicLabelUI.getPreferredSize(BasicLabelUI.java:227)
	at javax.swing.JComponent.getPreferredSize(JComponent.java:1662)
	at java.awt.GridBagLayout.GetLayoutInfo(GridBagLayout.java:1115)
	at java.awt.GridBagLayout.getLayoutInfo(GridBagLayout.java:916)
	at java.awt.GridBagLayout.preferredLayoutSize(GridBagLayout.java:736)
	at java.awt.Container.preferredSize(Container.java:1796)
	at java.awt.Container.getPreferredSize(Container.java:1780)
	at javax.swing.JComponent.getPreferredSize(JComponent.java:1664)
	at java.awt.BorderLayout.preferredLayoutSize(BorderLayout.java:719)
	at java.awt.Container.preferredSize(Container.java:1796)
	at java.awt.Container.getPreferredSize(Container.java:1780)
	at javax.swing.JComponent.getPreferredSize(JComponent.java:1664)
	at javax.swing.JRootPane$RootLayout.preferredLayoutSize(JRootPane.java:920)
	at java.awt.Container.preferredSize(Container.java:1796)
	at java.awt.Container.getPreferredSize(Container.java:1780)
	at javax.swing.JComponent.getPreferredSize(JComponent.java:1664)
	at java.awt.BorderLayout.preferredLayoutSize(BorderLayout.java:719)
	at java.awt.Container.preferredSize(Container.java:1796)
	at java.awt.Container.getPreferredSize(Container.java:1780)
	at java.awt.Window.pack(Window.java:809)
	at com.netscape.management.client.console.SplashScreen.<init>(Unknown Source)
	at com.netscape.management.client.console.Console.<init>(Unknown Source)
	at com.netscape.management.client.console.Console.main(Unknown Source)



Expected results:
389-console should start successfully

Additional info:
If any other sans font is installed on a system, apps work correctly. 
See also https://stackoverflow.com/questions/45569367/upgrade-rhel-from-7-3-to-7-4-arrayindexoutofboundsexception-in-sun-font-composi
Comment 2 Mario Torre 2017-08-24 08:09:37 EDT
(In reply to Viktor Ashirov from comment #0)
> Description of problem:
> When the following set of fonts is installed on a system, AWT java apps
> refuse to start
> # rpm -qa  | grep fonts
> xorg-x11-fonts-Type1-7.5-9.el7.noarch
> stix-fonts-1.1.0-5.el7.noarch
> 
> Version-Release number of selected component (if applicable):
> java-1.8.0-openjdk-1.8.0.131-11.b12.el7.x86_64
> 
> How reproducible:
> Deterministically 
> 
> Steps to Reproduce:
> 1. Install a fresh RHEL7.4
> 2. Install 389-console (from EPEL or RHDS repo)
> 3. Run 389-console

Hi Viktor,

I need some more instructions to reproduce your environment, including a list of all the packages you have installed.
Comment 4 Mario Torre 2017-08-24 11:38:53 EDT
I was able to reproduce the issue with the test case in the stackoverflow entry (a version of which I'm also attaching to this bug report).

I believe there are two issues that have a play in this bug, one is that this font is CFF, Java only loads Type 1 or True Type during the first part of the font initialisation. The second issue is related, for some reason the STIX font replaces the default SanSerif font, but since the font configuration for this font has been skipped we have an empty configuration. I can see where this happens in the code, however I don't yet fully grasp why the empty configuration replaces the default font (which is the Type 1 Cursor or Utopia I believe), I need to dig a bit more for that.

That said, you can still use STIX directly, i.e.:

Font font = new Font("STIX", Font.PLAIN, 12);

And this works of course.

I would argue that having just those two fonts is an invalid configuration anyway, especially if executing AWT application is the goal. I had to force the system into removing things in order for that to happen, and that included all the desktop and most of the graphics packages, so I advice to install a more complete set of fonts at the very least.

I will try to add CFF to the list of fonts loaded at startup and see if I can fix the issue with STIX replacing the default loaded fonts, however it may take a bit to get there reliably, and the patch may in fact break many other applications so this needs to be considered.
Comment 5 Mario Torre 2017-08-24 11:41 EDT
Created attachment 1317799 [details]
reproducer
Comment 6 Mario Torre 2017-08-24 12:16 EDT
Created attachment 1317834 [details]
candidate fix
Comment 7 Mario Torre 2017-08-24 12:20:37 EDT
I attached a possible fix, I don't think this is wrong since CFF files should be ok to load by default, however I need to submit this to upstream for validation before we can ship a build with this fix.

In the meantime, could you please check if with the given patch you can run again the 389-console?
Comment 8 Andrew John Hughes 2017-08-24 14:33:45 EDT
Duplicate of bug 1479563?
Comment 9 Viktor Ashirov 2017-08-25 09:35:25 EDT
Thank you, Mario! I did a scratch build with your fix and was able to start the 389-console.
Comment 10 Qi Guo [Flos] 2017-09-14 23:35:56 EDT
Hi,

Does this issue also affect other versions of java eg.1.7/1.6 provided by RH?

Best regards,
Flos
Comment 11 jiri vanek 2017-09-15 04:36:07 EDT
Looks bad. All seems to be affected: 

[tester@localhost ~]$ 
[tester@localhost ~]$ rpm -qa  | grep fonts
stix-fonts-1.1.0-5.el7.noarch
xorg-x11-fonts-Type1-7.5-9.el7.noarch
[tester@localhost ~]$ /usr/lib/jvm/java-1.6.0-openjdk.x86_64/bin/javac  TestJava.java 
[tester@localhost ~]$ /usr/lib/jvm/java-1.6.0-openjdk.x86_64/bin/java TestJava
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fe850dbecb1, pid=2173, tid=140636107024128
#
# JRE version: 6.0_41-b41
# Java VM: OpenJDK 64-Bit Server VM (23.41-b41 mixed mode linux-amd64 compressed oops)
# Derivative: IcedTea6 1.13.13
# Distribution: Red Hat Enterprise Linux Server release 7.3 (Maipo), package rhel-1.13.13.1.el7_3-x86_64
# Problematic frame:
# C  [libfontconfig.so.1+0xccb1]  FcConfigSetSysRoot+0x181
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/tester/hs_err_pid2173.log
#
# If you would like to submit a bug report, please include
# instructions how to reproduce the bug and visit:
#   http://icedtea.classpath.org/bugzilla
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Aborted
[tester@localhost ~]$ /usr/lib/jvm/java-1.7.0-openjdk/bin/java TestJava
Bitstream Charter
Courier 10 Pitch
Cursor
Dialog
DialogInput
Monospaced
SansSerif
Serif
STIX
Utopia
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
	at sun.font.CompositeStrike.getStrikeForSlot(CompositeStrike.java:75)
	at sun.font.CompositeStrike.getFontMetrics(CompositeStrike.java:93)
	at sun.font.Font2D.getFontMetrics(Font2D.java:400)
	at java.awt.Font.defaultLineMetrics(Font.java:2175)
	at java.awt.Font.getLineMetrics(Font.java:2282)
	at java.awt.font.TextLayout.fastInit(TextLayout.java:589)
	at java.awt.font.TextLayout.<init>(TextLayout.java:392)
	at TestJava.main(TestJava.java:17)
[tester@localhost ~]$ /usr/lib/jvm/java-1.8.0-openjdk/bin/java TestJava
Bitstream Charter
Courier 10 Pitch
Cursor
Dialog
DialogInput
Monospaced
SansSerif
Serif
STIX
Utopia
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
	at sun.font.CompositeStrike.getStrikeForSlot(CompositeStrike.java:75)
	at sun.font.CompositeStrike.getFontMetrics(CompositeStrike.java:93)
	at sun.font.Font2D.getFontMetrics(Font2D.java:415)
	at java.awt.Font.defaultLineMetrics(Font.java:2176)
	at java.awt.Font.getLineMetrics(Font.java:2283)
	at java.awt.font.TextLayout.fastInit(TextLayout.java:598)
	at java.awt.font.TextLayout.<init>(TextLayout.java:393)
	at TestJava.main(TestJava.java:17)
[tester@localhost ~]$ cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 7.3 (Maipo)
[tester@localhost ~]$ /usr/lib/jvm/java-1.8.0-openjdk/bin/java -version
openjdk version "1.8.0_144"
OpenJDK Runtime Environment (build 1.8.0_144-b01)
OpenJDK 64-Bit Server VM (build 25.144-b01, mixed mode)
[tester@localhost ~]$ /usr/lib/jvm/java-1.7.0-openjdk/bin/java -version
java version "1.7.0_151"
OpenJDK Runtime Environment (rhel-2.6.11.1.el7_4-x86_64 u151-b00)
OpenJDK 64-Bit Server VM (build 24.151-b00, mixed mode)
[tester@localhost ~]$ /usr/lib/jvm/java-1.6.0-openjdk.x86_64/bin/java -version
java version "1.6.0_41"
OpenJDK Runtime Environment (IcedTea6 1.13.13) (rhel-1.13.13.1.el7_3-x86_64)
OpenJDK 64-Bit Server VM (build 23.41-b41, mixed mode)
[tester@localhost ~]$
Comment 12 Mario Torre 2017-09-15 05:15:38 EDT
(In reply to Qi Guo [Flos] from comment #10)
> Hi,
> 
> Does this issue also affect other versions of java eg.1.7/1.6 provided by RH?
> 
> Best regards,
> Flos

Yes, they all are, the code is the same. I still could not understand exactly why stix are special (other than being CFF), since they replace the default fonts (I got an idea though I'm checking now), however I don't think there is an actual bug in the jdk, but perhaps in the fact that stix is now in RHEL (I think it wasn't before), and this minimal configuration is always problematic: the JDK specifically needs Type 1 and TrueType fonts, while CFF are OpenType Type 2 fonts. We are not really installing any font that is "usable" since stix somehow "replaces" the one default font package. Nevertheless, I asked upstream but didn't get any reply yet, I'm testing the patch with a few different default desktop configurations, so far I don't see any obvious side effect so we can probably ship it and try to upstream it and see how it goes.
Comment 13 Mario Torre 2017-09-15 09:58:37 EDT
(In reply to Mario Torre from comment #12)
> (In reply to Qi Guo [Flos] from comment #10)
> > Hi,
> > 
> > Does this issue also affect other versions of java eg.1.7/1.6 provided by RH?
> > 
> > Best regards,
> > Flos
> 
> Yes, they all are, the code is the same. I still could not understand
> exactly why stix are special (other than being CFF), since they replace the
> default fonts (I got an idea though I'm checking now), however I don't think
> there is an actual bug in the jdk, but perhaps in the fact that stix is now
> in RHEL (I think it wasn't before), and this minimal configuration is always
> problematic: the JDK specifically needs Type 1 and TrueType fonts, while CFF
> are OpenType Type 2 fonts. We are not really installing any font that is
> "usable" since stix somehow "replaces" the one default font package.
> Nevertheless, I asked upstream but didn't get any reply yet, I'm testing the
> patch with a few different default desktop configurations, so far I don't
> see any obvious side effect so we can probably ship it and try to upstream
> it and see how it goes.

Ok, I think I understand better what happens now. The number of fonts to retrieve depends on a fixed sets of font names. The code asks the best match for those fonts to the native fontconfig library. When STIX is the only other font installed with the default Type1, fontconfig returns this as best match, for example when requesting a font of type "sans:regular:roman". Since this is a valid font for fontconfig the match is registered so we then scan the actual Set of the STIX fonts. This is discarded later on however, since STIX are CFF and we only keep Type1 or TrueType, as noted before.

So it all boils down now to decide to either discard CFF in the fist place or to add them to the list of fonts to support for the default mappings, I would prefer to go with the latter since is more stable in my opinion.
Comment 16 Mario Torre 2017-09-20 08:33:52 EDT
(In reply to Mario Torre from comment #15)

> It's an interesting question, I think it may be the matching that changes,

Yes, it's the matching. When I have abattis-cantarell-fonts-0.0.16-3.el7.noarch and xorg-x11-fonts-Type1-7.5-9.el7.noarch only, I get 3 match for the query of "sans:regular:roman", they are two Type 1 and one CFF (which is the Cantarell font), the CFF one is discarded in this pass, but having at least one Type 1 in the match ensures the array won't be end up empty. When I add STIX I have 5 match, but since they are all CFF they are all discarded. I think STIX are considered "better" by FontConfig, but I don't know if this is a misconfiguration of the font or else, it's a bit over my expertise, perhaps someone from the FontConfig team may know better.

So to recap, the trick is that you need at least one Type 1 or True Type that is "better match" to fill the initial font array, indeed this is pretty fragile, since any random combination of installed fonts may cause an issue so I'll try to get my patch upstream. On the other end, there may also be a problem with FontConfig, I think we should ask the maintainers if they are aware of any changes.

Btw, you can actually see the same with the fc-match utility, with stix (output edited):

$ fc-match -f "sans:regular:roman" -sv
Pattern has 34 elts (size 48)
	family: "STIX"(s)
	fontformat: "CFF"(w)
	postscriptname: "STIX-Regular"(w)

Pattern has 34 elts (size 48)
	family: "Cantarell"(s)
	fontformat: "CFF"(w)
	postscriptname: "Cantarell-Regular"(w)

Pattern has 34 elts (size 48)
	family: "STIX"(s)
	fontformat: "CFF"(w)
	postscriptname: "STIX-Bold"(w)

Pattern has 34 elts (size 48)
	family: "STIX"(s)
	fontformat: "CFF"(w)
	postscriptname: "STIX-Italic"(w)

Pattern has 34 elts (size 48)
	family: "STIX"(s)
	fontformat: "CFF"(w)
	postscriptname: "STIX-BoldItalic"(w)

Without:

$ fc-match -f "sans:regular:roman" -sv
Pattern has 29 elts (size 32)
	family: "Utopia"(s)
	fontformat: "Type 1"(w)
	postscriptname: "Utopia-Regular"(w)

Pattern has 30 elts (size 32)
	family: "Cursor"(s)
	fontformat: "Type 1"(w)
	postscriptname: "Cursor"(w)

Pattern has 34 elts (size 48)
	family: "Cantarell"(s)
	fontformat: "CFF"(w)
	postscriptname: "Cantarell-Regular"(w)
Comment 18 Viktor Ashirov 2017-09-21 03:20:48 EDT
In fact, it's not always pulling stix-fonts. On some systems I had paratype-pt-sans-caption-fonts installed (which doesn't cause the issue described in this bug, since it's TTF). I filed bug 1484094 for fontconfig to address this nondeterministic behaviour. I'd greatly appreciate if you leave your comments there as well.

Thanks!
Comment 22 Mario Torre 2017-10-06 05:55:33 EDT
I'm working with upstream for this bug (and 1479563), for now I think we can ship our RPMs with this patch on the next update, since things will likely take longer.
Comment 25 Mario Torre 2017-10-11 06:56:28 EDT
*** Bug 1479563 has been marked as a duplicate of this bug. ***
Comment 42 errata-xmlrpc 2018-04-10 11:50:25 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0872