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 3. Actual results: Quietly dies. Actually mozilla does a segfault Expected results: Works. 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: lstat64("/usr/lib/mozilla-1.4.1/res/fonts/fontEncoding.properties", {st_mode=S_IFLNK|0777, st_size=67, ...}) = 0 open("/usr/lib/mozilla-1.4.1/res/fonts/fontEncoding.properties", 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 ?
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
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.
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!
This also prvents any gnome app from running. Which is really bad if you want to log in and choose one of these languages.
This solution seemed to work for me. Thanks!
The 1.4.1-18 update that was just pushed for fedora should fix this.
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?
I was able to reproduce this with any page that had Chinese, Korean, or Japanese fonts on it. Try http://china.com
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.
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.
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
I opened bug 111973 for the fc-cache problem.
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.