Re: [ft-devel] freetype crashes in Mac OS X

[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 <address@hidden> 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)