freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Tim Lyons
Subject: Re: [ft-devel] freetype crashes in Mac OS X
Date: Fri, 28 Mar 2008 17:53:10 +0000

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]