Bug 109537 - Mozilla & Epiphany crashes from bad ttfonts-ja update
Mozilla & Epiphany crashes from bad ttfonts-ja update
Product: Fedora
Classification: Fedora
Component: ttfonts-ja (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Akira TAGOH
Bill Huang
Depends On:
  Show dependency treegraph
Reported: 2003-11-08 23:31 EST by Bob Arendt
Modified: 2007-11-30 17:10 EST (History)
6 users (show)

See Also:
Fixed In Version: 1.4.1-18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-11-19 10:55:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bob Arendt 2003-11-08 23:31:31 EST
Description of problem:
Mozilla and Epiphany were crashing.  Mozilla mail would always
crash when displaying a mail message from the enlightenment mail
list from Carsten Haitzler (The Rasterman).  It correlated with
the display of japanese characters.  I had updated from RedHat 9
(with latest updates) to FC1 (without intervening test rels).

Version-Release number of selected component (if applicable):
Redhat 9:  ttfonts-ja-1.2-21
FC1:       ttfonts-ja-1.2-29

How reproducible:
Always - if Japanese fonts (like in RasterMan's sig line) are present

Steps to Reproduce:
1. Open mozilla or epipany
2. Display pages 
Actual results:
Quietly dies.  Actually mozilla does a segfault

Expected results:

Additional info:
I've solved my problem, but there appears to be an update problem
with ttfonts-ja.  I've updated 3 systems from RH9 to FC1, and
experienced the same problem in all cases.

I found the root of the problem using strace.  When the error occurs:

{st_mode=S_IFLNK|0777, st_size=67, ...}) = 0
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/share/fonts/ja/TrueType/kochi-gothic.ttf", O_RDONLY) = -1
ENOENT (No such file or directory)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
unlink("/home/rda/.mozilla/rda/jh20zns0.slt/lock") = 0
exit_group(11)                          = ?

Turns out the font file names changed, and the fonts.dir (and other)
file contained both the OLD files as well as the NEW names.
The old files no longer existed, but fontconfig thought they did,
since they were in the font.dir.  Thus the crash.

My solution was to re-install the ttfonts-ja rpm:
rpm -e --nodeps ttfonts-ja 
rm -rf /usr/share/fonts/ja/TrueType
rpm -Uvh ttfonts-ja-1.2-29.noarch.rpm

No problems now.  I suspect that a full install works, that
only the update fails to properly remove the entries in fonts.dir
and other files.  The rpm scripts need a patch ?
Comment 1 Steve Lacy 2003-11-10 15:03:47 EST
Yes, I had the exact same problem, except that it was with the Chinese
fonts in /usr/share/fonts/zh_CN.  I diagnosed it in exactly the same
way (by stracing Mozilla).  I suspect that its not a specific problem
for japanese fonts, but more that its a general FC1 font RPM bug, for
all fonts. 

I found that if I moved away the file fonts.cache-1, that the crash
went away.

What command do I run to regenerate these files?  Is it safe to do:

find /usr/share/fonts -name "fonts.cache-1" | xargs rm 
Comment 2 Bob Arendt 2003-11-10 16:38:57 EST
I believe the fc-cache command creates these files. Removing the
fonts.cache-1 file will solve the problem, but also removes
the font.  Regenerating fonts.cache-1 wouldn't help in my case,
since the fonts.dir file (used by fc-cache?) had entries for both
the old and new font file names.  Uninstalling, wiping out the
.rpmsave files (by wiping the directory) and doing a fresh reinstall
takes care of everything.

Looking at rpm -q --scripts ttfonts-ja (or whatever ttfonts) the
postinstall script regenerates all the font info for the system,
for both X11/xfs and fontconfig.
Comment 3 Steve Lacy 2003-11-11 01:02:58 EST
I don't really think that removing the fonts.cache-1 file will remove
the font file itself, it will just make the fonts not visible until I
run fc-cache again. 

I nuked all my fonts.cache-1 files, reran fc-cache, they were all
regenerated, and everything seems great now.  I had no .rpmnew or
.rpmsave files, so that wasn't the issue, it was just that
fonts.cach-1 referenced fonts that no longer existed. 

Thanks for your help!
Comment 4 P Jones 2003-11-11 11:44:59 EST
This also prvents any gnome app from running. Which is really bad if
you want to log in and choose one of these languages.
Comment 5 Alex Lancaster 2003-11-14 14:06:43 EST
This solution seemed to work for me.  Thanks!
Comment 6 Christopher Blizzard 2003-11-19 10:55:14 EST
The 1.4.1-18 update that was just pushed for fedora should fix this.
Comment 7 Scott Baker 2003-11-19 11:42:03 EST
I'm having the same problem with Firebird 0.7.  It seems to bomd out
sporadically, are there any web pages I can go to to try and force it
to crash.  This would show me if it's the same bug or not.

I'm confused why we're fixing the Mozilla RPM if the problem seems to
be a font that doesn't exist.  Wouldn't a better solution be to fix
the fonts.dir file?
Comment 8 Steve Lacy 2003-11-19 12:33:17 EST
I was able to reproduce this with any page that had Chinese, Korean,
or Japanese fonts on it.  Try http://china.com
Comment 9 Scott Baker 2003-11-19 17:21:24 EST
I just tried http://china.com on both Mozilla 1.4.1-17 and 1.4.1-18,
and both were able to display the page without crashing.  
Comment 10 David Baron 2003-12-11 20:58:31 EST
The problem with the ttfonts-ja package still remains, though.  It's
leaving extra entries in the fonts.cache-1, fonts.dir, and fonts.scale
in /usr/share/fonts/ja/TrueType on upgrade from RH9.

Furthermore, current trunk Mozilla still seems to crash because of
this problem.
Comment 11 David Baron 2003-12-11 21:03:32 EST
Actually, as noted before, it's really an fc-cache bug, not a
ttfonts-ja bug.  fc-cache should be deleting files that no longer
exist from its lists
Comment 12 David Baron 2003-12-11 21:30:45 EST
I opened bug 111973 for the fc-cache problem.
Comment 13 John Li 2004-01-02 22:56:34 EST
After upgrading from RH9 to FC1, and logging in with simplified
Chinese, file ~/.xsession-errors contained:

0mXftFontOpen(): Failed:  
(and then, in Chinese: "file or directory doesn't exist")
Following charsets:
0: -Sony-Fixed-Medium-R-Normal--16-120-100-100-c-80-ISO8859-1
1: -Sony-Fixed-Medium-R-Normal--16-120-100-100-c-80-ISO8859-1
2: -isas-fangsong ti-medium-r-normal--0-0-0-0-c-0-gb2312.1980-0
3: -jis-fixed-medium-r-normal--0-0-0-0-c-0-jisx0208.1983-0
4: -baekmuk-batangbdf-bold-r-normal--0-0-0-0-m-0-ksc5601.1987-0
5: -taipei-fixed-medium-r-normal--0-0-0-0-c-0-big5-0
6: -arabic-newspaper-medium-r-normal--0-0-0-0-p-0-iso10646-1
** (gnome-session:5681): WARNING **: Cannot open font file for font
ZYSong 18030 10
** (gnome-session:5681): WARNING **: Cannot open fallback font,
nothing to do

When at the login prompt I chose languages, the script next to the
simplified Chinese option did not display Chinese, but little squares
of hex code.  (Thai was the same way.)

After installing the Mozilla upgrade, the error messages 0-6 are gone,
but the ZYSong error remains.  Mozilla also crashes when acessing a
Chinese web site.  Chinese and Thai still do not display correctly in
the choose-languages area.  Japanese works OK.

Note You need to log in before you can comment on or make changes to this bug.