freetype crashes in Mac OS X

[guylinton]

freetype crashes in FT_New_Face_From_FOND. Mac OS X 10.4.8 on PowerPC  
G5. The backtrace (top entries) is shown below.

I don't understand why FT_New_Face_From_FOND is being called from  
within FT_New_Face_From_Resource, but I think this may be due to  
optimisation in the compiler.

At the point of the crash, I think the problem is that R30 is zero.  
The top frame is as shown below.

I have tried running under gdb, and it does not appear to be the  
first call on FT_New_Face that fails - in fact  there seem to be many  
successful one before. Is it likely that libfontconfig is trying to  
load ALL the fonts on my system? (Or does it need to call FT_New_Face  
for every character output?

I don't know how to display the parameters of the call, so I can't  
find out which particular font is causing the problem. Also, I don't  
know how to generate any more symbols in the library so that I can  
get more information about the crash (perhaps there are no more  
symbols, because everything in the de-compilation seems to be in  
registers). The crash seems to be just after a release resource, but  
I don't know where this comes from in the source (I have the de-
compilation - I am not sure it is the same as the otool, perhaps 'or'  
is the same as 'mr'). Note that I am building using MacPorts, so I  
don't know how I would change the parameters inthat to change the  
compilation is a different compiler option were needed.

Could anyone help me to sort out this failure.

Many thanks.
Tim Lyons



Host Name:      hidden-G5
Date/Time:      2008-03-21 23:17:20.653 +0000
OS Version:     10.4.8 (Build 8L127)
Report Version: 4

Command: python2.5
Path:    /opt/local/bin/python2.5
Parent:  bash [1279]

Version: ??? (???)

PID:    14610
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
0   libfreetype.6.dylib       0x017007a4 FT_New_Face_From_FOND + 420
1   libfreetype.6.dylib       0x01700a5c FT_New_Face_From_Resource +  
476
2   libfreetype.6.dylib       0x01700b04 FT_New_Face + 52
3   libfontconfig.1.dylib     0x01782878 FcFreeTypeQuery + 72
4   libfontconfig.1.dylib     0x0177f5c4 FcFileScanConfig + 196
5   libfontconfig.1.dylib     0x0177f894 FcDirCacheScan + 452
6   libfontconfig.1.dylib     0x0177b990 FcConfigAddDirList + 128
7   libfontconfig.1.dylib     0x0177bc5c FcConfigBuildFonts + 92
8   libfontconfig.1.dylib     0x01782e3c FcInitLoadConfigAndFonts + 44
9   libfontconfig.1.dylib     0x017830c0 FcInit + 48
10  libfontconfig.1.dylib     0x01778c9c FcConfigGetCurrent + 44
11  libfontconfig.1.dylib     0x0177a838 FcConfigSubstituteWithPat + 56
12  libpangocairo-1.0.0.dylib 0x015f7308  
pango_cairo_fc_font_map_context_substitute + 40


(gdb) info frame
Stack level 0, frame at 0xbfffab30:
pc = 0x17507a4 in FT_New_Face_From_FOND; saved pc 0x1750a5c
called by frame at 0xbfffb5f0
Arglist at 0xbfffab30, args:
Locals at 0xbfffab30, Previous frame's sp is 0xbfffb5f0
Saved registers:
   r25 at 0xbfffb5d4, r26 at 0xbfffb5d8, r27 at 0xbfffb5dc, r28 at  
0xbfffb5e0, r29 at 0xbfffb5e4, r30 at 0xbfffb5e8, r31 at 0xbfffb5ec,  
lr at 0xbfffb5f8
This function was not called from a signal handler.
The function prologue begins at 0x1750600.
The function body begins at 0x175062c.
A stack frame has been allocated.
2752 bytes of integer and floating-point registers have been saved:
0x1750628 is the stack setup address.
General-purpose registers r25--r31 have been saved at offset 0xffffffe4.
No floating-point registers have been saved.
The link register has been saved at offset 0x8.
(gdb)



(gdb) info reg
r0             0x0      0
r1             0xbfffab30       3221203760
r2             0xbfffa000       3221200896
r3             0x0      0
r4             0x0      0
r5             0xbfffab08       3221203720
r6             0x0      0
r7             0xffffffffffffffff       18446744073709551615
r8             0x19e2400        27141120
r9             0x0      0
r10            0x90bae680       2428167808
r11            0xa0b8af98       2696458136
r12            0x90008540       2415953216
r13            0x0      0
r14            0x0      0
r15            0x2e2bd50        48414032
r16            0x2e8b9e0        48806368
r17            0x0      0
r18            0x0      0
r19            0x0      0
r20            0xbfffc6bc       3221210812
r21            0x2e7a9c0        48736704
r22            0xbfffb62e       3221206574
r23            0xbfffbc28       3221208104
r24            0x2      2
r25            0xbfffbc28       3221208104
r26            0x2e7a9c0        48736704
r27            0x0      0
r28            0x0      0
r29            0x0      0
r30            0x0      0
r31            0x1750610        24446480
pc             0x17507a4        24446884
ps             0x100000000000d030       1152921504606900272
cr             0x24284482       606618754
lr             0x1750784        24446852
ctr            0x90008540       2415953216
xer            0x20000000       536870912
mq             0x0      0
fpscr          0x82004000       2181054464
vscr           0x10000  65536
vrsave         0x0      0
(gdb)



_______________________________________________
Freetype-devel mailing list
Freetype-devel@...
http://lists.nongnu.org/mailman/listinfo/freetype-devel

[Wenlin Institute]

On Mar 26, 2008, at 3:25 PM, Tim Lyons wrote:
> freetype crashes in FT_New_Face_From_FOND.

What program are you running when the crash occurs? The stack trace  
shows libpangocairo calling libfontconfig, which is calling  
libfreetype. But what program is calling libpangocairo? Without more  
context, it's not clear that the crash is caused by a bug in  
Freetype. The bug could be anywhere. Could you post code that  
produces the problem?

Best wishes,

Tom Bishop

> Mac OS X 10.4.8 on PowerPC G5. The backtrace (top entries) is shown  
> below.
>
> I don't understand why FT_New_Face_From_FOND is being called from  
> within FT_New_Face_From_Resource, but I think this may be due to  
> optimisation in the compiler.
>
> At the point of the crash, I think the problem is that R30 is zero.  
> The top frame is as shown below.
>
> I have tried running under gdb, and it does not appear to be the  
> first call on FT_New_Face that fails - in fact  there seem to be  
> many successful one before. Is it likely that libfontconfig is  
> trying to load ALL the fonts on my system? (Or does it need to call  
> FT_New_Face for every character output?
>
> I don't know how to display the parameters of the call, so I can't  
> find out which particular font is causing the problem. Also, I  
> don't know how to generate any more symbols in the library so that  
> I can get more information about the crash (perhaps there are no  
> more symbols, because everything in the de-compilation seems to be  
> in registers). The crash seems to be just after a release resource,  
> but I don't know where this comes from in the source (I have the de-
> compilation - I am not sure it is the same as the otool, perhaps  
> 'or' is the same as 'mr'). Note that I am building using MacPorts,  
> so I don't know how I would change the parameters inthat to change  
> the compilation is a different compiler option were needed.
>
> Could anyone help me to sort out this failure.
>
> Many thanks.
> Tim Lyons
>
>
>
> Host Name:      hidden-G5
> Date/Time:      2008-03-21 23:17:20.653 +0000
> OS Version:     10.4.8 (Build 8L127)
> Report Version: 4
>
> Command: python2.5
> Path:    /opt/local/bin/python2.5
> Parent:  bash [1279]
>
> Version: ??? (???)
>
> PID:    14610
> Thread: 0
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000
>
> Thread 0 Crashed:
> 0   libfreetype.6.dylib       0x017007a4 FT_New_Face_From_FOND + 420
> 1   libfreetype.6.dylib       0x01700a5c FT_New_Face_From_Resource  
> + 476
> 2   libfreetype.6.dylib       0x01700b04 FT_New_Face + 52
> 3   libfontconfig.1.dylib     0x01782878 FcFreeTypeQuery + 72
> 4   libfontconfig.1.dylib     0x0177f5c4 FcFileScanConfig + 196
> 5   libfontconfig.1.dylib     0x0177f894 FcDirCacheScan + 452
> 6   libfontconfig.1.dylib     0x0177b990 FcConfigAddDirList + 128
> 7   libfontconfig.1.dylib     0x0177bc5c FcConfigBuildFonts + 92
> 8   libfontconfig.1.dylib     0x01782e3c FcInitLoadConfigAndFonts  
> + 44
> 9   libfontconfig.1.dylib     0x017830c0 FcInit + 48
> 10  libfontconfig.1.dylib     0x01778c9c FcConfigGetCurrent + 44
> 11  libfontconfig.1.dylib     0x0177a838 FcConfigSubstituteWithPat  
> + 56
> 12  libpangocairo-1.0.0.dylib 0x015f7308  
> pango_cairo_fc_font_map_context_substitute + 40
>
>
> (gdb) info frame
> Stack level 0, frame at 0xbfffab30:
> pc = 0x17507a4 in FT_New_Face_From_FOND; saved pc 0x1750a5c
> called by frame at 0xbfffb5f0
> Arglist at 0xbfffab30, args:
> Locals at 0xbfffab30, Previous frame's sp is 0xbfffb5f0
> Saved registers:
>   r25 at 0xbfffb5d4, r26 at 0xbfffb5d8, r27 at 0xbfffb5dc, r28 at  
> 0xbfffb5e0, r29 at 0xbfffb5e4, r30 at 0xbfffb5e8, r31 at  
> 0xbfffb5ec, lr at 0xbfffb5f8
> This function was not called from a signal handler.
> The function prologue begins at 0x1750600.
> The function body begins at 0x175062c.
> A stack frame has been allocated.
> 2752 bytes of integer and floating-point registers have been saved:
> 0x1750628 is the stack setup address.
> General-purpose registers r25--r31 have been saved at offset  
> 0xffffffe4.
> No floating-point registers have been saved.
> The link register has been saved at offset 0x8.
> (gdb)
>
>
>
> (gdb) info reg
> r0             0x0      0
> r1             0xbfffab30       3221203760
> r2             0xbfffa000       3221200896
> r3             0x0      0
> r4             0x0      0
> r5             0xbfffab08       3221203720
> r6             0x0      0
> r7             0xffffffffffffffff       18446744073709551615
> r8             0x19e2400        27141120
> r9             0x0      0
> r10            0x90bae680       2428167808
> r11            0xa0b8af98       2696458136
> r12            0x90008540       2415953216
> r13            0x0      0
> r14            0x0      0
> r15            0x2e2bd50        48414032
> r16            0x2e8b9e0        48806368
> r17            0x0      0
> r18            0x0      0
> r19            0x0      0
> r20            0xbfffc6bc       3221210812
> r21            0x2e7a9c0        48736704
> r22            0xbfffb62e       3221206574
> r23            0xbfffbc28       3221208104
> r24            0x2      2
> r25            0xbfffbc28       3221208104
> r26            0x2e7a9c0        48736704
> r27            0x0      0
> r28            0x0      0
> r29            0x0      0
> r30            0x0      0
> r31            0x1750610        24446480
> pc             0x17507a4        24446884
> ps             0x100000000000d030       1152921504606900272
> cr             0x24284482       606618754
> lr             0x1750784        24446852
> ctr            0x90008540       2415953216
> xer            0x20000000       536870912
> mq             0x0      0
> fpscr          0x82004000       2181054464
> vscr           0x10000  65536
> vrsave         0x0      0
> (gdb)
>
>
>
> _______________________________________________
> Freetype-devel mailing list
> Freetype-devel@...
> http://lists.nongnu.org/mailman/listinfo/freetype-devel
>

文林 Wenlin Institute, Inc.        Software for Learning Chinese
E-mail: wenlin@...     Web: http://www.wenlin.com
Telephone: 1-877-4-WENLIN (1-877-493-6546)
☯







_______________________________________________
Freetype-devel mailing list
Freetype-devel@...
http://lists.nongnu.org/mailman/listinfo/freetype-devel

[mpsuzuki]

Dear Tim,

First of all, I'm sorry for your experience, and
I thank to Tom for the early request for detail.
I want to know the python program you used, to
reproduce the problem.

--

Taking a glance on gdb stracktrace, I guess as
following scenario.

1. fontconfig library (triggered by some Python+Cairo
   application) is trying to crawl all font files
   by passing all files to FT_New_Face() of FreeType2.

2. A font-like file is passed to FT_New_Face(), and
   it makes some MacOS-specific code unrecoverably
   crashed.
   # At least, even if FreeType2 cannot load the font-
   # like file, FreeType2 is expected to return safely.
   # fontconfig expects so.

Thus, I want to know if it's a problem caused by a
specific font-like file, or, it's independent with
font file (but depends on building or running environment).
One of my anxiety is that the platform is G5. I suppose
Mac OS X 10.4 has no ppc64 Carbon, so the functionality
of ftmac.c is unavailable.

--

Tim, please let me know which file causes the crash
by following step.

1. Setting a breakpoint on FT_New_Face() by gdb, before
   running the python script, like this.

   $ gdb /usr/bin/python
   GNU gdb 6.3.50-20050815 (Apple version gdb-573) (Fri Oct 20 15:54:33 GMT 2006)
   Copyright 2004 Free Software Foundation, Inc.
   GDB is free software, covered by the GNU General Public License, and you are
   welcome to change it and/or distribute copies of it under certain conditions.
   Type "show copying" to see the conditions.
   There is absolutely no warranty for GDB.  Type "show warranty" for details.
   This GDB was configured as "powerpc-apple-darwin"...Reading symbols for shared libraries ..... done

   (gdb) break FT_New_Face
   Function "FT_New_Face" not defined.
   Make breakpoint pending on future shared library load? (y or [n]) y
   Breakpoint 1 (FT_New_Face) pending.

2. Prepare the command to be executed when gdb stops
   the execution at the breakpoint.

   (gdb) commands 1
   Type commands for when breakpoint 1 is hit, one per line.
   End with a line saying just "end".
   >silent
   >printf "FT_New_Face() tries %s\n", pathname
   >cont
   >end  

   (gdb)

3. Run the python program.

   (gdb) run /the/path/to/python/script the_argument_to_the_script
   ...

   If gdb successfully sets the breakpoint and commands,
   gdb generates the messages whenever FT_New_Face() is
   called, like,

   FT_New_Face() tries /Library/Fonts/Impact

4. Please let me know the final font(-like) file that
   FT_New_Face() tried to open before the crash.
   It is the font(-like) file that made FreeType2 crashed.

5. If the font is bundled to Mac OS X 10.4, please let
   me know. I can investigate by my own Mac OS X 10.4
   machine - however I don't have G5. If the font is not
   bundled to Mac OS X, please let me know where I can
   obtain that.

6. If I cannot obtain the font easily, I want you to check
   the file by simpler programs, like, ftdump (see ft2demos),
   with FreeType2 built with debugging symbol.

Regards,
mpsuzuki

On Wed, 26 Mar 2008 16:55:29 -0700
Wenlin Institute <wenlin@...> wrote:

>
>On Mar 26, 2008, at 3:25 PM, Tim Lyons wrote:
>> freetype crashes in FT_New_Face_From_FOND.
>
>What program are you running when the crash occurs? The stack trace  
>shows libpangocairo calling libfontconfig, which is calling  
>libfreetype. But what program is calling libpangocairo? Without more  
>context, it's not clear that the crash is caused by a bug in  
>Freetype. The bug could be anywhere. Could you post code that  
>produces the problem?
>
>Best wishes,
>
>Tom Bishop
>
>
>> Mac OS X 10.4.8 on PowerPC G5. The backtrace (top entries) is shown  
>> below.
>>
>> I don't understand why FT_New_Face_From_FOND is being called from  
>> within FT_New_Face_From_Resource, but I think this may be due to  
>> optimisation in the compiler.
>>
>> At the point of the crash, I think the problem is that R30 is zero.  
>> The top frame is as shown below.
>>
>> I have tried running under gdb, and it does not appear to be the  
>> first call on FT_New_Face that fails - in fact  there seem to be  
>> many successful one before. Is it likely that libfontconfig is  
>> trying to load ALL the fonts on my system? (Or does it need to call  
>> FT_New_Face for every character output?
>>
>> I don't know how to display the parameters of the call, so I can't  
>> find out which particular font is causing the problem. Also, I  
>> don't know how to generate any more symbols in the library so that  
>> I can get more information about the crash (perhaps there are no  
>> more symbols, because everything in the de-compilation seems to be  
>> in registers). The crash seems to be just after a release resource,  
>> but I don't know where this comes from in the source (I have the de-
>> compilation - I am not sure it is the same as the otool, perhaps  
>> 'or' is the same as 'mr'). Note that I am building using MacPorts,  
>> so I don't know how I would change the parameters inthat to change  
>> the compilation is a different compiler option were needed.
>>
>> Could anyone help me to sort out this failure.
>>
>> Many thanks.
>> Tim Lyons
>>
>>
>>
>> Host Name:      hidden-G5
>> Date/Time:      2008-03-21 23:17:20.653 +0000
>> OS Version:     10.4.8 (Build 8L127)
>> Report Version: 4
>>
>> Command: python2.5
>> Path:    /opt/local/bin/python2.5
>> Parent:  bash [1279]
>>
>> Version: ??? (???)
>>
>> PID:    14610
>> Thread: 0
>>
>> Exception:  EXC_BAD_ACCESS (0x0001)
>> Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000
>>
>> Thread 0 Crashed:
>> 0   libfreetype.6.dylib       0x017007a4 FT_New_Face_From_FOND + 420
>> 1   libfreetype.6.dylib       0x01700a5c FT_New_Face_From_Resource  
>> + 476
>> 2   libfreetype.6.dylib       0x01700b04 FT_New_Face + 52
>> 3   libfontconfig.1.dylib     0x01782878 FcFreeTypeQuery + 72
>> 4   libfontconfig.1.dylib     0x0177f5c4 FcFileScanConfig + 196
>> 5   libfontconfig.1.dylib     0x0177f894 FcDirCacheScan + 452
>> 6   libfontconfig.1.dylib     0x0177b990 FcConfigAddDirList + 128
>> 7   libfontconfig.1.dylib     0x0177bc5c FcConfigBuildFonts + 92
>> 8   libfontconfig.1.dylib     0x01782e3c FcInitLoadConfigAndFonts  
>> + 44
>> 9   libfontconfig.1.dylib     0x017830c0 FcInit + 48
>> 10  libfontconfig.1.dylib     0x01778c9c FcConfigGetCurrent + 44
>> 11  libfontconfig.1.dylib     0x0177a838 FcConfigSubstituteWithPat  
>> + 56
>> 12  libpangocairo-1.0.0.dylib 0x015f7308  
>> pango_cairo_fc_font_map_context_substitute + 40
>>
>>
>> (gdb) info frame
>> Stack level 0, frame at 0xbfffab30:
>> pc = 0x17507a4 in FT_New_Face_From_FOND; saved pc 0x1750a5c
>> called by frame at 0xbfffb5f0
>> Arglist at 0xbfffab30, args:
>> Locals at 0xbfffab30, Previous frame's sp is 0xbfffb5f0
>> Saved registers:
>>   r25 at 0xbfffb5d4, r26 at 0xbfffb5d8, r27 at 0xbfffb5dc, r28 at  
>> 0xbfffb5e0, r29 at 0xbfffb5e4, r30 at 0xbfffb5e8, r31 at  
>> 0xbfffb5ec, lr at 0xbfffb5f8
>> This function was not called from a signal handler.
>> The function prologue begins at 0x1750600.
>> The function body begins at 0x175062c.
>> A stack frame has been allocated.
>> 2752 bytes of integer and floating-point registers have been saved:
>> 0x1750628 is the stack setup address.
>> General-purpose registers r25--r31 have been saved at offset  
>> 0xffffffe4.
>> No floating-point registers have been saved.
>> The link register has been saved at offset 0x8.
>> (gdb)
>>
>>
>>
>> (gdb) info reg
>> r0             0x0      0
>> r1             0xbfffab30       3221203760
>> r2             0xbfffa000       3221200896
>> r3             0x0      0
>> r4             0x0      0
>> r5             0xbfffab08       3221203720
>> r6             0x0      0
>> r7             0xffffffffffffffff       18446744073709551615
>> r8             0x19e2400        27141120
>> r9             0x0      0
>> r10            0x90bae680       2428167808
>> r11            0xa0b8af98       2696458136
>> r12            0x90008540       2415953216
>> r13            0x0      0
>> r14            0x0      0
>> r15            0x2e2bd50        48414032
>> r16            0x2e8b9e0        48806368
>> r17            0x0      0
>> r18            0x0      0
>> r19            0x0      0
>> r20            0xbfffc6bc       3221210812
>> r21            0x2e7a9c0        48736704
>> r22            0xbfffb62e       3221206574
>> r23            0xbfffbc28       3221208104
>> r24            0x2      2
>> r25            0xbfffbc28       3221208104
>> r26            0x2e7a9c0        48736704
>> r27            0x0      0
>> r28            0x0      0
>> r29            0x0      0
>> r30            0x0      0
>> r31            0x1750610        24446480
>> pc             0x17507a4        24446884
>> ps             0x100000000000d030       1152921504606900272
>> cr             0x24284482       606618754
>> lr             0x1750784        24446852
>> ctr            0x90008540       2415953216
>> xer            0x20000000       536870912
>> mq             0x0      0
>> fpscr          0x82004000       2181054464
>> vscr           0x10000  65536
>> vrsave         0x0      0
>> (gdb)

_______________________________________________
Freetype-devel mailing list
Freetype-devel@...
http://lists.nongnu.org/mailman/listinfo/freetype-devel

[guylinton]

mpsuzuki

Wonderful! Thanks very much for such a quick and comprehensive reply.

I couldn't run the sequence you suggested, because the freetype that  
was built with MacPorts did not have debug symbols. So I downloaded  
freetype from the website, did .configure and Make, and then moved  
the dylib into the place where MacPorts leaves it, and ran as you  
suggested.

As you surmise, fontconfig does crawl through all the font files, but  
using freetype with debug symbols, it managed to process 252 fonts,  
and then did not fail! (The application ran as expected).

I then tried to switch back to the failing dylib, but this didn't  
crawl the files at all. Today I have discovered the .fontconfig font  
cache, and have deleted that, and with the original build, the fault  
is back. Although I can't output the pathname I have output a text  
for each font crawled, and assuming that the order matches, it fails  
on the 137th font which seems to be the second occurrence of
FT_New_Face() tries /System/Library/Fonts/LucidaGrande.dfont

This file is (I think) bundled with Mac OS X. Its version 5.0d8e1  
dated 22 Aug 2005. I tried moving the font out of the way, but this  
messed up some displays on the system, and it still seemed to fail in  
the same place.

So... I think it seems to be a build or optimisation problem, but  
presumably related to that particular file font file (or one in that  
region). I have done a diff -rq on the expanded files downloaded from  
the freetype website and on the expanded files that MacPorts uses,  
and there are no differences reported (apart from .DS_Stores, some  
doc files which are only present in one copy).

It is no use comparing the dylib files, because these differ in the  
debug information. I am a bit stuck as to what to do next to resolve  
the  issue. Perhaps I could build freetype without the debug  
information (but I don't know what level of optimisation is used in  
MacPorts, so might not match that optimisation in the independent  
build of freetype).

[I appreciate that if I am looking at whether optimisation has any  
effect, I am getting very desperate!]

I am copying this Ryan, who is the maintainer of the freetype  
portfile, but he has already told me that he does not know how to  
build software so symbols are present, so maybe he cannot help.

Ryan, do you know what options are used in the build of freetype?

Any ideas on what to try next?

Regards,
Tim.



On 27 Mar 2008, at 05:05, mpsuzuki@... wrote:

> Dear Tim,
>
> First of all, I'm sorry for your experience, and
> I thank to Tom for the early request for detail.
> I want to know the python program you used, to
> reproduce the problem.
>
> --
>
> Taking a glance on gdb stracktrace, I guess as
> following scenario.
>
> 1. fontconfig library (triggered by some Python+Cairo
>    application) is trying to crawl all font files
>    by passing all files to FT_New_Face() of FreeType2.
>
> 2. A font-like file is passed to FT_New_Face(), and
>    it makes some MacOS-specific code unrecoverably
>    crashed.
>    # At least, even if FreeType2 cannot load the font-
>    # like file, FreeType2 is expected to return safely.
>    # fontconfig expects so.
>
> Thus, I want to know if it's a problem caused by a
> specific font-like file, or, it's independent with
> font file (but depends on building or running environment).
> One of my anxiety is that the platform is G5. I suppose
> Mac OS X 10.4 has no ppc64 Carbon, so the functionality
> of ftmac.c is unavailable.
>
> --
>
> Tim, please let me know which file causes the crash
> by following step.
>
> 1. Setting a breakpoint on FT_New_Face() by gdb, before
>    running the python script, like this.
>
>    $ gdb /usr/bin/python
>    GNU gdb 6.3.50-20050815 (Apple version gdb-573) (Fri Oct 20  
> 15:54:33 GMT 2006)
>    Copyright 2004 Free Software Foundation, Inc.
>    GDB is free software, covered by the GNU General Public License,  
> and you are
>    welcome to change it and/or distribute copies of it under  
> certain conditions.
>    Type "show copying" to see the conditions.
>    There is absolutely no warranty for GDB.  Type "show warranty"  
> for details.
>    This GDB was configured as "powerpc-apple-darwin"...Reading  
> symbols for shared libraries ..... done
>
>    (gdb) break FT_New_Face
>    Function "FT_New_Face" not defined.
>    Make breakpoint pending on future shared library load? (y or [n]) y
>    Breakpoint 1 (FT_New_Face) pending.
>
> 2. Prepare the command to be executed when gdb stops
>    the execution at the breakpoint.
>
>    (gdb) commands 1
>    Type commands for when breakpoint 1 is hit, one per line.
>    End with a line saying just "end".
>> silent
>> printf "FT_New_Face() tries %s\n", pathname
>> cont
>> end
>
>    (gdb)
>
> 3. Run the python program.
>
>    (gdb) run /the/path/to/python/script the_argument_to_the_script
>    ...
>
>    If gdb successfully sets the breakpoint and commands,
>    gdb generates the messages whenever FT_New_Face() is
>    called, like,
>
>    FT_New_Face() tries /Library/Fonts/Impact
>
> 4. Please let me know the final font(-like) file that
>    FT_New_Face() tried to open before the crash.
>    It is the font(-like) file that made FreeType2 crashed.
>
> 5. If the font is bundled to Mac OS X 10.4, please let
>    me know. I can investigate by my own Mac OS X 10.4
>    machine - however I don't have G5. If the font is not
>    bundled to Mac OS X, please let me know where I can
>    obtain that.
>
> 6. If I cannot obtain the font easily, I want you to check
>    the file by simpler programs, like, ftdump (see ft2demos),
>    with FreeType2 built with debugging symbol.
>
> Regards,
> mpsuzuki
>
> On Wed, 26 Mar 2008 16:55:29 -0700
> Wenlin Institute <wenlin@...> wrote:
>>
>> On Mar 26, 2008, at 3:25 PM, Tim Lyons wrote:
>>> freetype crashes in FT_New_Face_From_FOND.
>>
>> What program are you running when the crash occurs? The stack trace
>> shows libpangocairo calling libfontconfig, which is calling
>> libfreetype. But what program is calling libpangocairo? Without more
>> context, it's not clear that the crash is caused by a bug in
>> Freetype. The bug could be anywhere. Could you post code that
>> produces the problem?
>>
>> Best wishes,
>>
>> Tom Bishop
>>
>>
>>> Mac OS X 10.4.8 on PowerPC G5. The backtrace (top entries) is shown
>>> below.
>>>
>>> I don't understand why FT_New_Face_From_FOND is being called from
>>> within FT_New_Face_From_Resource, but I think this may be due to
>>> optimisation in the compiler.
>>>
>>> At the point of the crash, I think the problem is that R30 is zero.
>>> The top frame is as shown below.
>>>
>>> I have tried running under gdb, and it does not appear to be the
>>> first call on FT_New_Face that fails - in fact  there seem to be
>>> many successful one before. Is it likely that libfontconfig is
>>> trying to load ALL the fonts on my system? (Or does it need to call
>>> FT_New_Face for every character output?
>>>
>>> I don't know how to display the parameters of the call, so I can't
>>> find out which particular font is causing the problem. Also, I
>>> don't know how to generate any more symbols in the library so that
>>> I can get more information about the crash (perhaps there are no
>>> more symbols, because everything in the de-compilation seems to be
>>> in registers). The crash seems to be just after a release resource,
>>> but I don't know where this comes from in the source (I have the de-
>>> compilation - I am not sure it is the same as the otool, perhaps
>>> 'or' is the same as 'mr'). Note that I am building using MacPorts,
>>> so I don't know how I would change the parameters inthat to change
>>> the compilation is a different compiler option were needed.
>>>
>>> Could anyone help me to sort out this failure.
>>>
>>> Many thanks.
>>> Tim Lyons
>>>
>>>
>>>
>>> Host Name:      hidden-G5
>>> Date/Time:      2008-03-21 23:17:20.653 +0000
>>> OS Version:     10.4.8 (Build 8L127)
>>> Report Version: 4
>>>
>>> Command: python2.5
>>> Path:    /opt/local/bin/python2.5
>>> Parent:  bash [1279]
>>>
>>> Version: ??? (???)
>>>
>>> PID:    14610
>>> Thread: 0
>>>
>>> Exception:  EXC_BAD_ACCESS (0x0001)
>>> Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000
>>>
>>> Thread 0 Crashed:
>>> 0   libfreetype.6.dylib       0x017007a4 FT_New_Face_From_FOND +  
>>> 420
>>> 1   libfreetype.6.dylib       0x01700a5c FT_New_Face_From_Resource
>>> + 476
>>> 2   libfreetype.6.dylib       0x01700b04 FT_New_Face + 52
>>> 3   libfontconfig.1.dylib     0x01782878 FcFreeTypeQuery + 72
>>> 4   libfontconfig.1.dylib     0x0177f5c4 FcFileScanConfig + 196
>>> 5   libfontconfig.1.dylib     0x0177f894 FcDirCacheScan + 452
>>> 6   libfontconfig.1.dylib     0x0177b990 FcConfigAddDirList + 128
>>> 7   libfontconfig.1.dylib     0x0177bc5c FcConfigBuildFonts + 92
>>> 8   libfontconfig.1.dylib     0x01782e3c FcInitLoadConfigAndFonts
>>> + 44
>>> 9   libfontconfig.1.dylib     0x017830c0 FcInit + 48
>>> 10  libfontconfig.1.dylib     0x01778c9c FcConfigGetCurrent + 44
>>> 11  libfontconfig.1.dylib     0x0177a838 FcConfigSubstituteWithPat
>>> + 56
>>> 12  libpangocairo-1.0.0.dylib 0x015f7308
>>> pango_cairo_fc_font_map_context_substitute + 40
>>>
>>>
>>> (gdb) info frame
>>> Stack level 0, frame at 0xbfffab30:
>>> pc = 0x17507a4 in FT_New_Face_From_FOND; saved pc 0x1750a5c
>>> called by frame at 0xbfffb5f0
>>> Arglist at 0xbfffab30, args:
>>> Locals at 0xbfffab30, Previous frame's sp is 0xbfffb5f0
>>> Saved registers:
>>>   r25 at 0xbfffb5d4, r26 at 0xbfffb5d8, r27 at 0xbfffb5dc, r28 at
>>> 0xbfffb5e0, r29 at 0xbfffb5e4, r30 at 0xbfffb5e8, r31 at
>>> 0xbfffb5ec, lr at 0xbfffb5f8
>>> This function was not called from a signal handler.
>>> The function prologue begins at 0x1750600.
>>> The function body begins at 0x175062c.
>>> A stack frame has been allocated.
>>> 2752 bytes of integer and floating-point registers have been saved:
>>> 0x1750628 is the stack setup address.
>>> General-purpose registers r25--r31 have been saved at offset
>>> 0xffffffe4.
>>> No floating-point registers have been saved.
>>> The link register has been saved at offset 0x8.
>>> (gdb)
>>>
>>>
>>>
>>> (gdb) info reg
>>> r0             0x0      0
>>> r1             0xbfffab30       3221203760
>>> r2             0xbfffa000       3221200896
>>> r3             0x0      0
>>> r4             0x0      0
>>> r5             0xbfffab08       3221203720
>>> r6             0x0      0
>>> r7             0xffffffffffffffff       18446744073709551615
>>> r8             0x19e2400        27141120
>>> r9             0x0      0
>>> r10            0x90bae680       2428167808
>>> r11            0xa0b8af98       2696458136
>>> r12            0x90008540       2415953216
>>> r13            0x0      0
>>> r14            0x0      0
>>> r15            0x2e2bd50        48414032
>>> r16            0x2e8b9e0        48806368
>>> r17            0x0      0
>>> r18            0x0      0
>>> r19            0x0      0
>>> r20            0xbfffc6bc       3221210812
>>> r21            0x2e7a9c0        48736704
>>> r22            0xbfffb62e       3221206574
>>> r23            0xbfffbc28       3221208104
>>> r24            0x2      2
>>> r25            0xbfffbc28       3221208104
>>> r26            0x2e7a9c0        48736704
>>> r27            0x0      0
>>> r28            0x0      0
>>> r29            0x0      0
>>> r30            0x0      0
>>> r31            0x1750610        24446480
>>> pc             0x17507a4        24446884
>>> ps             0x100000000000d030       1152921504606900272
>>> cr             0x24284482       606618754
>>> lr             0x1750784        24446852
>>> ctr            0x90008540       2415953216
>>> xer            0x20000000       536870912
>>> mq             0x0      0
>>> fpscr          0x82004000       2181054464
>>> vscr           0x10000  65536
>>> vrsave         0x0      0
>>> (gdb)

_______________________________________________
Freetype-devel mailing list
Freetype-devel@...
http://lists.nongnu.org/mailman/listinfo/freetype-devel

[Ryan Schmidt-24]

On Mar 28, 2008, at 12:53, Tim Lyons wrote:

> FT_New_Face() tries /System/Library/Fonts/LucidaGrande.dfont
>
> This file is (I think) bundled with Mac OS X. Its version 5.0d8e1  
> dated 22 Aug 2005. I tried moving the font out of the way, but this  
> messed up some displays on the system, and it still seemed to fail  
> in the same place.


Lucide Grande is the Mac OS X system font... FontBook on my 10.4.11  
system says it's version 5.0d8e1 from 2005-1-27. On disk, the file  
was last modified 2007-03-10, is 2244215 bytes, and its sha1sum is  
634427accc111c7abe667c207df4904d4ad3c4d5.


> I am copying this Ryan, who is the maintainer of the freetype  
> portfile, but he has already told me that he does not know how to  
> build software so symbols are present, so maybe he cannot help.
>
> Ryan, do you know what options are used in the build of freetype?


You can see what options are specific to freetype by looking at the  
portfile, via "port cat freetype" or (if your EDITOR environment  
variable is set up properly) "port edit freetype". Or you can see  
where the portfile is on your hard disk with "port file freetype" or  
"open `port dir freetype`".

There are also some options that MacPorts sets for every port, which  
are not listed in the individual portfiles. For example, --prefix=/
opt/local (or whatever your MacPorts prefix is) is prepended to the  
configure arguments, -L/opt/local/lib and -I/opt/local/include are  
put into the LDFLAGS and CPPFLAGS respectively, and the optimization  
level is set to -O2 (same as you'd have when building manually).  
MACOSX_DEPLOYMENT_TARGET is also set to the correct value for your  
version of Mac OS X. You can see all the configuration options and  
environment variables as they're used by compiling with the debug  
flag ("sudo port -d install freetype").

If you want to try different options, you can edit the freetype  
portfile. Your changes will be overwritten next time you sync or  
selfupdate.

If you want to retain your changes, you can copy the freetype  
portfile (and its files directory) to any other directory on your  
hard disk and make changes there. To install that version, "cd" to  
that directory in the terminal and type "sudo port install" (without  
specifying a port name; this will make MacPorts use the portfile in  
the current directory).




_______________________________________________
Freetype-devel mailing list
Freetype-devel@...
http://lists.nongnu.org/mailman/listinfo/freetype-devel

[guylinton]

mpsuzuki and Ryan,

Thank you so much for your help in tracking this down. My previous  
suspicion is incorrect, it was not due to LucidaGrande.

I believe I have now tracked down the problem, and I think it is due  
to a peculiar font file, but was masked by a build discrepancy.

I had built freetype without any parameters to configure, with the  
consequence that the compile parameters were:
-c -Wall -g -O2 -DFT_CONFIG_OPTION_SYSTEM_ZLIB -DDARWIN_NO_CARBON -
DFT_CONFIG_CONFIG_H="<ftconfig.h>" -DFT2_BUILD_LIBRARY -
DFT_CONFIG_MODULES_H="<ftmodule.h>"

This worked even with the funny font.

MacPorts ran configure with:
org_release_ports_print_freetype/work/freetype-2.3.5" && ./configure  
--prefix=/opt/local --with-old-mac-fonts'
with the result that the compilation options were:
-c  -O2 -DFT_CONFIG_OPTION_SYSTEM_ZLIB -DHAVE_ANSI_OS_INLINE=1 -
DFT_CONFIG_CONFIG_H="<ftconfig.h>" -DFT2_BUILD_LIBRARY -
DFT_CONFIG_MODULES_H="<ftmodule.h>"
which resulted in scanning many more fonts (this mislead me in my  
previous diagnosis) and crashed on the peculiar font file.

__Should I be using --with-old-fonts on Mac OS X 10 with PPC G5?__
I don't understand what I should be doing from the various read-me  
files.

I have rebuilt freetype with --with-old-mac-fonts, and -g, and rerun  
the application. (I was previously mislead because the working run  
only looked at one font in most of the font files, while the failing  
one looks at many more fonts per file). It now crashes as follows:

FT_New_Face /Library/Fonts/MshtakanOblique.ttf
FT_New_Face /Library/Fonts/MshtakanRegular.ttf
FT_New_Face /Library/Fonts/N Helvetica Narrow
FT_New_Face /Library/Fonts/N Helvetica Narrow

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
FT_New_Face_From_FOND (library=0x306af20, fond=0x0, face_index=0,  
aface=0xbfffbbe8) at /Users/tim/Downloads/freetype-2.3.5copy/src/base/
ftmac.c:818
818         ft_memcpy( sfnt_data, *sfnt, sfnt_size );
(gdb)

I removed this font (actually two font files, one normal and one  
bold), and the application worked OK.

Font Book says the following about the  font:

Helvetica Narrow
Helvetica Narrow, 18 pt.

        PostScript name Helvetica-Narrow
        Full name Helvetica Narrow
        Family Helvetica
        Style Narrow
        Kind TrueType
        Language English, German, French, Italian, Spanish, Danish, Finnish,  
Portuguese, Swedish
        Version 1.1
        Location /Library/Fonts/N Helvetica Narrow
        Unique name Apple Computer Helvetica Narrow
        Copyright Copyright © 1992 Linotype Hell/Apple Computer Inc./Type  
Solutions, Inc.
        Trademark Helvetica is a registered trademark of Linotype AG
        Enabled Yes
        Duplicate Yes


Fontbook displays the font OK.

Finder get info says this is a Font.mdimporter Document. Double  
clicking on it opens OS 9, but then this says FontUpdater could not  
be found.

I don't know where this font came from, but think it may be from the  
Apple Laserwriter in OS 7. There is another version of the font which  
is a font suitcase which works OK.

The ironic thing is that all this scanning of all the font files is  
actually a waste of time, because the application probably only uses  
a single font - anyway there does not seem to be any way to choose  
different fonts!, and even more ironic, once the scan has been done  
once, the information is cached, and the scan is not repeated.

regards,
Tim Lyons.




_______________________________________________
Freetype-devel mailing list
Freetype-devel@...
http://lists.nongnu.org/mailman/listinfo/freetype-devel

[mpsuzuki]

Dear Tim,

Great thank you for hard working to track down the problem.
Sorry, now I have to disconnect the network to go Norway,
but here I send a quick reply.

On Sat, 29 Mar 2008 16:41:07 +0000
Tim Lyons <guy.linton@...> wrote:

>I believe I have now tracked down the problem, and I think it is due  
>to a peculiar font file, but was masked by a build discrepancy.
>
>I had built freetype without any parameters to configure, with the  
>consequence that the compile parameters were:
>-c -Wall -g -O2 -DFT_CONFIG_OPTION_SYSTEM_ZLIB -DDARWIN_NO_CARBON -
>DFT_CONFIG_CONFIG_H="<ftconfig.h>" -DFT2_BUILD_LIBRARY -
>DFT_CONFIG_MODULES_H="<ftmodule.h>"
>
>This worked even with the funny font.

OK.

>MacPorts ran configure with:
>org_release_ports_print_freetype/work/freetype-2.3.5" && ./configure  
>--prefix=/opt/local --with-old-mac-fonts'
>with the result that the compilation options were:
>-c  -O2 -DFT_CONFIG_OPTION_SYSTEM_ZLIB -DHAVE_ANSI_OS_INLINE=1 -
>DFT_CONFIG_CONFIG_H="<ftconfig.h>" -DFT2_BUILD_LIBRARY -
>DFT_CONFIG_MODULES_H="<ftmodule.h>"
>which resulted in scanning many more fonts (this mislead me in my  
>previous diagnosis) and crashed on the peculiar font file.

OK. There is significant difference: your own building
has "-DDARWIN_NO_CARBON", but MacPorts doesn't have it
and has "-DHAVE_ANSI_OS_INLINE". Your binary uses a
Carbon-free suitcase font support, but MacPorts binary
uses legacy Carbon-dependent suitcase font support.
I guess, the Carbon framework on Mac OS X 10.4 for PPC
G5 is incompleted and Carbon-dependent suitcase font
support in FreeType2 does not work well.

Why MacPorts' option differs from yours? I guess, the
reason is that the options are automatically set by
configure script: if configured on Mac OS X with working
Carbon, options are set to use it as MacPorts. if
configured on Mac OS X with broken Carbon, options are
set to ignore it as yours.

>__Should I be using --with-old-fonts on Mac OS X 10 with PPC G5?__
>I don't understand what I should be doing from the various read-me  
>files.

Sorry for confusing document, I have to revise it.
More easier and detailed documents to avoid such
trouble is needed. I will write next message about
following part of your mail within a week (if I
could connect to the internet from Norway),
please wait it.

Regards,
mpsuzuki

>I have rebuilt freetype with --with-old-mac-fonts, and -g, and rerun  
>the application. (I was previously mislead because the working run  
>only looked at one font in most of the font files, while the failing  
>one looks at many more fonts per file). It now crashes as follows:
>
>FT_New_Face /Library/Fonts/MshtakanOblique.ttf
>FT_New_Face /Library/Fonts/MshtakanRegular.ttf
>FT_New_Face /Library/Fonts/N Helvetica Narrow
>FT_New_Face /Library/Fonts/N Helvetica Narrow
>
>Program received signal EXC_BAD_ACCESS, Could not access memory.
>Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
>FT_New_Face_From_FOND (library=0x306af20, fond=0x0, face_index=0,  
>aface=0xbfffbbe8) at /Users/tim/Downloads/freetype-2.3.5copy/src/base/
>ftmac.c:818
>818         ft_memcpy( sfnt_data, *sfnt, sfnt_size );
>(gdb)
>
>I removed this font (actually two font files, one normal and one  
>bold), and the application worked OK.
>
>Font Book says the following about the  font:
>
>Helvetica Narrow
>Helvetica Narrow, 18 pt.
>
> PostScript name Helvetica-Narrow
> Full name Helvetica Narrow
> Family Helvetica
> Style Narrow
> Kind TrueType
> Language English, German, French, Italian, Spanish, Danish, Finnish,  
>Portuguese, Swedish
> Version 1.1
> Location /Library/Fonts/N Helvetica Narrow
> Unique name Apple Computer Helvetica Narrow
>Solutions, Inc.
> Trademark Helvetica is a registered trademark of Linotype AG
> Enabled Yes
> Duplicate Yes
>
>
>Fontbook displays the font OK.
>
>Finder get info says this is a Font.mdimporter Document. Double  
>clicking on it opens OS 9, but then this says FontUpdater could not  
>be found.

>I don't know where this font came from, but think it may be from the  
>Apple Laserwriter in OS 7. There is another version of the font which  
>is a font suitcase which works OK.
>
>The ironic thing is that all this scanning of all the font files is  
>actually a waste of time, because the application probably only uses  
>a single font - anyway there does not seem to be any way to choose  
>different fonts!, and even more ironic, once the scan has been done  
>once, the information is cached, and the scan is not repeated.


_______________________________________________
Freetype-devel mailing list
Freetype-devel@...
http://lists.nongnu.org/mailman/listinfo/freetype-devel