Bug 1484079

(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.

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.

Created attachment 1317799 [details]
reproducer

Created attachment 1317834 [details]
candidate fix

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?

Duplicate of bug 1479563?

Thank you, Mario! I did a scratch build with your fix and was able to start the 389-console.

Hi,

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

Best regards,
Flos

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 ~]$

(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.

(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.

(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)

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!

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.

*** Bug 1479563 has been marked as a duplicate of this bug. ***

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