Bug 87992

Summary: Fontconfig related applications cannot start until ~/.fonts.cache-1 is removed
Product: [Retired] Red Hat Linux Reporter: Konstanty <konstanty>
Component: fontconfigAssignee: Owen Taylor <otaylor>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: leonid.dimitrov, melevittfl, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-02 19:40:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
The created fonts.cache file
none
Screenshot of ?fontilus? displaying font correctly. none

Description Konstanty 2003-04-04 13:41:58 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
Fontconfig related programs don't seem to be able to run when ~/.fonts.cache-1
is present.



Version-Release number of selected component (if applicable):
fontconfig-2.1-9

How reproducible:
Always

Steps to Reproduce:
1. Start Cleanly (for i in `locate .fonts.cache`; do rm $i; done) - with no font
config cache files
2. Start a program (eg gedit)
3. Close Program
4. Start Program Again
    

Actual Results:  Program started once, but would not start again (until
~/.fonts.cache-1 is removed)

Expected Results:  Program should continue to start properly

Additional info:

Error message obtained:
No fonts found; this probably means that the fontconfig
library is not correctly configured. You may need to
edit the fonts.conf configuration file. More information
about fontconfig can be found in the fontconfig(3) manual
page and on http://fontconfig.org

will attach strace's of first and second run.

Comment 1 Konstanty 2003-04-04 13:52:21 UTC
< open("/home/kon/.fonts.cache-1", O_RDONLY) = -1 ENOENT (No such file or directory)
< open("/usr/share/fonts/fonts.cache-1", O_RDONLY) = -1 ENOENT (No such file or
directory)
< open("/usr/share/fonts", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 16
< fstat64(16, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
< fcntl64(16, F_SETFD, FD_CLOEXEC)        = 0
---
> open("/home/kon/.fonts.cache-1", O_RDONLY) = 16
> fstat64(16, {st_mode=S_IFREG|0664, st_size=316173, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x4001f000

...

> rename("/home/kon/.fonts.cache-1.NEW", "/home/kon/.fonts.cache-1") = 0
> unlink("/home/kon/.fonts.cache-1.LCK")  = 0
> writev(3, [{"\22\0\20\0\1\0\340\2\23\1\0\0\37\0\0\0\10_ID%\0\0\0001"..., 72},
{"RENDER", 6}, {"\0\0", 2}], 3) = 80
> read(3, "\1\346.\0\0\0\0\0\1\231\0\250\0\0\0\0\0\0\0\0\1\0\0\0p"..., 32) = 32
> write(3, "\231\0\3\0\0\0\0\0\10\0\0\0\231\1\1\0", 16) = 16
> read(3, "\1W/\0\0\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) = 32
> read(3, "\1\0250\0\221\0\0\0\22\0\0\0\1\0\0\0\7\0\0\0\1\0\0\0\1"..., 32) = 32
> read(3, "#\0\0\0\1\1\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0"..., 580) = 580
> uname({sys="Linux", node="innovation", ...}) = 0
> open("/home/kon/.Xdefaults-innovation", O_RDONLY) = -1 ENOENT (No such file or
directory)
> write(2, "No fonts found; this probably me"..., 258No fonts found; this
probably means that the fontconfig

(I guess the above is not that useful)

Some other information, is that I used to have garnome-0.22 installed with its
own fontconfig (working fine, but now removed - but there or not there -
something remains that is stuffing up fontconfig)


Comment 2 Konstanty 2003-04-04 13:59:04 UTC
Created attachment 90896 [details]
The created fonts.cache file

There is alot of binary data near the chinese fonts (is this a possible
culprit)

Comment 3 Konstanty 2003-04-04 14:02:18 UTC
Well, that comment about the Chinese fonts, made me consider chmod 0'ing all the
/usr/share/fonts/zh_* files - and then this problem goes away - I can run a
program (such as gedit) multiple times.

So this has something to do with the chinese entries inside ~/.fonts.cache-1
being invalid when they are read for a second time (but OK for the first time)
Or maybe it is conflicts between the multiple versions of Chinese fonts (TW and CN)

Comment 4 Konstanty 2003-04-04 14:18:01 UTC
Sorry that last 'fix' was a false alarm, I had gedit still open (running two
seems to work, but open, close, open is broken)

Even without the chinese fonts, things are still bad for fontconfig.

Comment 5 Owen Taylor 2003-04-04 15:10:48 UTC
It's not clear to me - does the problem come back once
you logout, remove ~/.fonts.cache-1, and log back in? 
(Since you've had a 3rd party fontconfig library installed,
it's hard for us to make any guarantees about our ability
to read ~/.fonts.cache-1)

Does the problem occur for other users, or just for one user?

Does the problem go away if you move away the /usr/share/fonts/kb
directory? It's possible that some font in there is is triggering a 
bug in fontconfig.

(I think the "reads of binary data" you are seeing are X server
traffic.)


Comment 6 Konstanty 2003-04-04 23:12:21 UTC
The problem was occuring for all users - including the gdm user (gdm would only
work after a reboot - it seems that after a reboot gdm remakes the
.fonts.cache-1 file)

Like you recommended - I looked through /usr/share/fonts/kb and one at a time
elliminated directories and groups of files. I have limited the error down to
one font onyx.ttf.

Interestingly enough - it is possible to view the font using the nautilus thing.
(Is it OK to attach ttf files to bugs - or is this a problem due to the fonts
being copyrighted).

Comment 7 Konstanty 2003-04-04 23:15:18 UTC
Created attachment 90916 [details]
Screenshot of ?fontilus? displaying font correctly.

Comment 8 Owen Taylor 2003-04-04 23:27:24 UTC
Attaching the font to the bug is not a good idea. If you mail it 
to me (otaylor) I'll see if I can track down the problem
then delete the font afterwards.

Comment 9 Owen Taylor 2003-04-07 14:58:02 UTC
So, to confirm, you remove onyx.ttf and the problem goes away,
you add it back, and it occurs again?

I can't reproduce any problems with this font, and it looks pretty
normal. It has a unusual "FontRevision" field, but I don't see 
why that would cause problems for fontconfig.


Comment 10 Konstanty 2003-04-08 10:18:12 UTC
Removing onyx.ttf from the /usr/share/fonts/kb/TrueType directory makes the
problem go away. However, the font seems to be ok when in ~/.fonts
(/home/kon/.fonts). I checked .fonts.cache-1 and found the font available - as
well as loading in in a program.

I also tried some of the below (also will duplicate the above):
in ~/.fonts - OK
in /usr/share/fonts/kb/TrueType - NOT OK
in /usr/share/fonts/kb/TrueType + Owned by kon.kon - NOT OK
in /usr/share/fonts/kb/TrueType/kon (directory owned by kon.kon) - NOT OK

One more test that I have not done yet is - a directory not in the XFree86 xfs
font server. (such as ~/.fonts is)
Because of this I moved the font to /usr/share/fonts/kb

Comment 11 Mark Levitt 2003-04-16 10:50:28 UTC
Hi,
I am having the same problem. Root cannot run an application like gedit or the
redhat-config-* utilities more than once without deleting .font-cache-1 from /root/

I do not have the onyx.ttf font on my system. 



Comment 12 Owen Taylor 2003-04-16 13:34:26 UTC
Could people check if they have any of:

 XFree86-ISO10646-1-100dpi-fonts-1.0-2.noarch.rpm
 XFree86-ISO10646-1-75dpi-fonts-1.0-2.noarch.rpm  
 XFree86-ISO8859-15-100dpi-fonts-1.0-2.noarch.rpm
 XFree86-ISO8859-15-75dpi-fonts-1.0-2.noarch.rpm

from Red Hat 7.2 installed? (rpm -qa | grep XFree86-ISO)
We've seen these packages causing some problems for fontconfig.


Comment 13 Mark Levitt 2003-04-16 13:38:50 UTC
[mlevitt@sheryl mlevitt]$ rpm -qa|grep ISO
XFree86-ISO8859-15-75dpi-fonts-4.3.0-2
XFree86-ISO8859-15-100dpi-fonts-4.3.0-2
[mlevitt@sheryl mlevitt]$

I think these are the RH 9 versions, right?



Comment 14 Owen Taylor 2003-04-16 14:07:13 UTC
Yeah, those should be fine, it's really the XFree86-ISO10646-1
fonts that are a problem because they don't get obsoleted properly
by the current XFree86 packages.

Do you (Mark) have other fonts in /usr/share/fonts or ~/.fonts
that didn't come with Red Hat Linux?



Comment 15 Mark Levitt 2003-04-16 15:16:47 UTC
>Do you (Mark) have other fonts in /usr/share/fonts or ~/.fonts
>that didn't come with Red Hat Linux?

Yes, I've got the Microsoft web fonts. 
I've just tried the following 

1) remove read and execute permission on the directory containing the MS fonts. 
2) launch redhat-config-users. It still failed. 
3) Delete /root/.font-cache-1
4) launch redhat-config-users. It succeeds.
5) Close redhat-config users.
6) Launch redhat-config-users. It fails with the No fonts found message.




Comment 16 Mark Levitt 2003-04-16 15:24:44 UTC
Some additional info...

OK, silly me, I just realized that removing r and x permissions doesn't apply to
root. 

So, I renamved the directory from "monotype" to "mtype" and tried the same steps
as listed above. Same result.


Comment 17 Owen Taylor 2003-04-16 15:31:23 UTC
I don't think the windows fonts have anything to do with it, but 
just to be sure, could you move them out of /usr/share/fonts entirely?
As long as they are in /usr/share/fonts, fontconfig will find them.


Comment 18 Mark Levitt 2003-04-16 15:39:06 UTC
OK, I moved /usr/share/fonts/monotype/ to /usr/local/monotype and restarted xfs
by doing # service xfs restart.

I tried my test again and it's still failing. Sorry.

By the way, if the XF86Config file specifies only unix:7100 (xfs) as a fontpath
and xfs's config file has an explicit list of font paths, then how do fonts not
contained in one of the explicit font paths get user? I guess I don't understand
what fontconfig is doing...


Comment 19 Mark Levitt 2003-04-16 16:44:20 UTC
More info...

OK, it seems I spoke too soon when I said the MS web fonts were the only non-RH
fonts installed.

I discovered another directory in /usr/share/fonts/default name TrueType with a
large number of additional TrueType fonts. (around 330).

About ten of these fonts were owned by ttfonts-1.0.9. However, the rest of them
were not owned by any package. 

I moved all the fonts that were not owned by the ttfonts package out of the
/usr/share/fonts directory and re-ran my test. This time, I was able to run
redhat-config-users multiple times without failure. 

I don't really remember where these fonts came from. I'll try and track down
which specific font causes the problem. 



Comment 20 Owen Taylor 2003-05-16 14:34:49 UTC
*** Bug 91003 has been marked as a duplicate of this bug. ***

Comment 21 Leonid I. Dimitrov 2003-05-16 15:40:29 UTC
I encountered the same problem (bug 91003). The font I found to be causing the
troubles was Oldengl.TTF

Comment 22 Leonid I. Dimitrov 2003-05-16 15:47:09 UTC
I encountered the same problem (bug 91003). The font I found to be causing the
troubles was Oldengl.TTF

Comment 23 Owen Taylor 2004-09-02 19:40:49 UTC
oldengl.ttf is I think the name of a Monotype font that I don't
have available. There's really nothing more I can do here. If you
can reproduce the problem with a current fontconfig version
(Red Hat 9 shipped with 2.1, FC1/FC2 have 2.2.1, current 
rawhide is 2.2.3 which is the lastest stable version), then you
might want to file upstream in bugzilla.freedesktop.org.

(Just as a caution, please don't include links in a bug report 
as to where to download  a font unless you are sure the font is
freely redistributable.)