2004-07-20-trunk on Darwin/PPC (Darwin lamancha.opendarwin.org 7.0.0 Darwin
Kernel Version 7.0.0: Wed Sep 24 15:48:39 PDT 2003;
root:xnu/xnu-517.obj~1/RELEASE_PPC Power Macintosh powerpc), "mkfontscale"
crashes while processing "MSungStd-Light-Acro.otf" like this:
-- snip --
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x00404884 in cff_cmap_unicode_init (cmap=0x622f50) at
167 FT_UInt sid = charset->sids[n];
#0 0x00404884 in cff_cmap_unicode_init (cmap=0x622f50) at
#1 0x003d9edc in FT_CMap_New (clazz=0x46117c, init_data=0x0,
charmap=0xbffff160, acmap=0x0) at ../../extras/freetype2/src/base/ftobjs.c:2261
#2 0x00400108 in cff_face_init (stream=0x61db60, face=0x1800200, face_index=0,
num_params=0, params=0x0) at ../../extras/freetype2/src/cff/cffobjs.c:667
#3 0x003d8904 in open_face (driver=0x6013a0, stream=0x61db60, face_index=0,
num_params=0, params=0x0, aface=0xbffff250) at
#4 0x003d8cd0 in FT_Open_Face (library=0x6011d0, args=0xbffff2d0, face_index=0,
aface=0xbffff3c4) at ../../extras/freetype2/src/base/ftobjs.c:1619
#5 0x003deb0c in FT_New_Face (library=0x6011d0, pathname=0x61b690
aface=0xbffff3c4) at ftmac.c:996
#6 0x00004408 in doDirectory (dirname_given=0xbffffe24
"/Users/gisburn/tmp/allfonts/test1", numEncodings=0, encodingsToDo=0x0) at
#7 0x00002554 in main (argc=2, argv=0xbffffd4c) at mkfontscale.c:264
The program is running. Exit anyway? (y or n) y
-- snip --
Steps to reproduce:
1. Grab all available fonts:
% find / 2>/dev/null | egrep -i "\.ttf|\.ttc|\.otf|\.otc|\.pfa|\.pfb" | tee
2. Link them into one directory:
% mkdir test001
% cd test001
% cat ../allfonts.txt | while read i ; do ln -s "$i" . ; done
3. Run "mkfontscale":
Core dump when processing MSungStd-Light-Acro.otf
No core dump
I wonder if this related to the problem reported on firstname.lastname@example.org with crashes in mkfontscale on
PPC with various operating systems. Check:
In particular Ian Romanick reports:
I have been able to reproduce this same problem on a G4 running Debian (sarge), but *not* on a
POWER4 box. GCC 3.3.4 was used on the G4, and GCC 3.3.3 was used on the POWER4. Both built for
32-bit. On the G4, I tried building with a variety of different optimization settings (-O0, -O2, -Os) and
architecture settings, but nothing seemed to help.
I changed the OS to "All" because I also hit this on Linux. As a side note,
another user has reported *not* hitting this bug on a G3 based Mac running
Linux. Could this bug be specific to the G4?
Since we are so close to the release, if a small patch is available to fix this
problem, then we could consider it for this release; otherwise, it will probably
just be documented as a known issue in the release notes.
On today's release wranglers call, we decided to set a deadline for patches of
today at 6pm EDT. If patches are available by then, are small and
self-contained, they can still be integreated into the release. Otherwise, we
will move the remaining open bugs to the release notes bug 999 for documentation.
Moving to release notes bug as noted earlier.
with no patch forthcoming, this is clearly not urgent enough to be a blocker for 7.
I had totally forgotten about this bug. I was one of the original reporters,
and I haven't been able to reproduce it for at least 6 months. As such, I'm
going to go ahead and resolve it as WORKSFORME.