Re: freetype crashes in Mac OS X

> 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)