Created attachment 42530 [details]
Xserver Debuginfo

Created attachment 42531 [details]
xpdf strace

Created attachment 42532 [details]
xpdf strace -f -eopen

I found one easily reproducible crash with freetype 2.1.10 

mfabian@magellan:~$ ftview 50 /usr/X11R6/lib/X11/fonts/truetype/airmoleq.ttf
available pixmap formats
depth  pixbits  scanpad
   1       1       32
   4       8       32
   8       8       32
  15      16       32
  16      16       32
  24      32       32
>   RGB ff0000:ff00:00ff, colors 256, bits  8  TrueColor
セグメンテーション違反です (core dumped)
mfabian@magellan:~$

It crashes after pressing Arrow-up 13 times after the window pops up.

I'm not yet sure whether this is related to the Xserver crash
but it certainly looks like a freetype bug.

Looks like comment #4 only happens on x86_64 and *not* on i386. So this might be
different to the initial freetype Xserver module problem.

Looks like the Xserver freetype module uses some internal interfaces of
freetype2, which changed in version 2.1.10. :-(

Created attachment 42577 [details]
Patch, which avoids Xserver crashes on my i386 machine.

Unfortunately it didn't help on Mike's x86_64 machine. :-(

See also:

http://lists.gnu.org/archive/html/freetype-devel/2005-07/msg00020.html

Yes, that's exactly the same I figured out. 

Created attachment 42629 [details]
bugzilla-97202-fix-x-crash.patch

This patch can be used to avoid the Xserver crash. To use this
patch, FT_OPTIMIZE_MEMORY needs to be disabled again.

This patch reverses a change between freetype 2.1.9 and freetype
2.1.10.  Probably this change was done on purpose though, therefore
this patch is only a workaround.

It works fine for me though and does not only avoid the Xserver crash
but also makes embedded bitmaps work again in applications using Xft.

Severity →　Normal, because we have a workaround now.

Mike, any news from freetype2 developers? 

From: "Turner, David" <DTurner@nds.com>
Subject: RE: [ft-devel] Re: xorg crashes with freetype2-2.1.10
To: "Werner LEMBERG" <wl@gnu.org>, <marcus@FreeBSD.org>
Cc: gnome@FreeBSD.org, hintak_leung@yahoo.co.uk, freetype-devel@nongnu.org
Date: Wed, 3 Aug 2005 18:35:35 +0200
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello everyone,

I'm back from vacation and have some hints regarding this infamous
crash.

- First of all, the reason why some pointers have been set to NULL in
  the latest package is really that:

     * the functions were _not_ used by the rest of the library,
       nor exposed through a public API. And I couldn't reasonnably
       guess what the X.org code was doing

     * the functions are completely removed in the heap-optimized
       version of the library.

  If you want to correct it safely, line 370 of 'src/sfnt/sfdriver.c' 
  should read instead:

          #ifdef FT_OPTIMIZE_MEMORY
            0 /* tt_find_sbit_image */,
            0 /* tt_load_sbit_metrics */,
          #else
            tt_find_sbit_image,
            tt_load_sbit_metrics,
          #endif


- The real problem is that the X.org code relies on features that
  are internal to the library. This is ok as long as its sources
  are embedded within the X Server (or X Font Server), but breaks
  when trying to rely on the library installed on the system.


There aren't that many solutions, but they do exist:

A/ Forget about the "optimization", load the glyphs twice
   and be done with it.

B/ Keep a copy of the FreeType sources within X.org, and never
   use the system-installed version of the library.

C/ Ask for a dedicated public API for the problem, which will
   appear in a later release of the library (e.g. 2.2.0). Do
   some twisted magic at compile-time:

     - if the version of FreeType headers used at compile time
       are < 2.2.0, forget about the optimization

This is the only way to generate correct code that will never
break in the future.

By the way, I don't think I'll be able to produce a patch for
X.org in the coming weeks !!

Hope this helps,

- David Turner
- The FreeType Project  (www.freetype.org)

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

From: Werner LEMBERG <wl@gnu.org>
Subject: Re: [ft-devel] Re: xorg crashes with freetype2-2.1.10
To: DTurner@nds.com
Cc: gnome@FreeBSD.org, hintak_leung@yahoo.co.uk, marcus@FreeBSD.org, freetype-devel@nongnu.org
Date: Wed, 03 Aug 2005 19:59:07 +0200 (CEST)
X-Mailer: Mew version 4.2.50 on Emacs 22.0.50.1 / Mule 5.0 (SAKAKI)
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


>   If you want to correct it safely, line 370 of
>   'src/sfnt/sfdriver.c' should read instead:
> 
>           #ifdef FT_OPTIMIZE_MEMORY
>             0 /* tt_find_sbit_image */,
>             0 /* tt_load_sbit_metrics */,
>           #else
>             tt_find_sbit_image,
>             tt_load_sbit_metrics,
>           #endif

I'll do that as a temporary fix.


    Werner


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

That seems to confirm that our current workaround/fix is reasonable
and good enough until there is a new api for that (in freetype 2.2.0).

→ FIXED.

> - The real problem is that the X.org code relies on features that
>   are internal to the library. This is ok as long as its sources
>   are embedded within the X Server (or X Font Server), but breaks
>   when trying to rely on the library installed on the system.

I thought we got this issue resolved. The problem is that there are some
functions exposed thru headers which are however not considered public by the
freetype folks. 
These are the functions that the X-TT guy Chisato Yamauchi added to freetype to
do the strange font rendering speedup optimization. We had an uphill battle to
get this into freetype and I really don't want to go thru this again as it was
painful enough.
Also I thought this was part of a public API.
I thought that this was the case.

> C/ Ask for a dedicated public API for the problem, which will
>   appear in a later release of the library (e.g. 2.2.0). Do
>   some twisted magic at compile-time:

>     - if the version of FreeType headers used at compile time
>       are < 2.2.0, forget about the optimization

I've checked Chisato's patch that he had sent to the freetype folks.
It's still available at:
  http://x-tt.sourceforge.jp/arch/xtt2-sbit-improvement2c3_freetype2.patch

His changes are included in a header file (freetype2/freetype/internal/sfnt.h
which is 'publically' available but contains private APIs.
This header file is a constant source of trouble because people make use of
functions in there.
I hope that this interface will be moved to a fully public header in the future
so that we can finally resolve this issue.
After all with this we were able to retire XTT.

Created attachment 45896 [details]
X.Org patch which restores the old behavior if function pointers are NULL

This patch does the same as attachment #42577 [details] but also restores the behavior of
this library that applies when built for freetype < 2.8.
Mike, can you check if this is an imporevemnt over the other patch?

Reopen, so it won't get lost.

Created attachment 45959 [details]
New freetype module with Egbert's patch applied

Mike, please test. 

The module is for x86_64. :-) 

I build a freetype2 without our workaround patch and installed it together
with Stefan's freetype module from comment #21.

xpdf does NOT crash.

But embedded bitmap apprently don't work.

I'll attach screen shots.

Created attachment 46074 [details]
embedded-bitmaps-do-not-work.png

screen shot created with

xfd -fn "-misc-ipagothic-medium-r-normal--16-0-0-0-p-0-iso10646-1"

Glyphs don't look nice.

Created attachment 46075 [details]
embedded-bitmaps-work.png

This screen shot is created with

    xfd -fa "IPAGothic:pixelsize=16"

(and embedded bitmaps are enabled in the fontconfig setup,
this is the default on SuSE 10.0 Beta1).

Compare the screen shots in comment #27 and comment #28:

The screen shot created with "xfd -fa" shows the embedded bitmaps.
The screen shot from comment #27 which uses the X core font system
should show identical glyphs, but it doesn't.

I reverted again to the freetype2 with our workaround patch and
to Stefan's "normal" xorg-x11-server package.

Then embedded bitmaps work, i.e.

    xfd -fn "-misc-ipagothic-medium-r-normal--16-0-0-0-p-0-iso10646-1"

shows exactly the same, nice glyphs as in the screen shot in
comment #28 (which was created using Xft2).

Created attachment 52034 [details]
freetype module patch

Created attachment 52035 [details]
libfreetype patch

Argh. Wrong Bugzilla. 

Created attachment 73826 [details]
Just for the record. The adjusted freetype module patch

freetype 2.2.1 doesn't seem to need a patch anymore to avoid this
crash.  I removed bugzilla-97202-fix-x-crash.patch and didn't disable
FT_OPTIMIZE_MEMORY (now enabled by default) and I couldn't reproduce
any crashes so far.

Mike, this is with the freetype module patch (see comment #35) still active ...

Xorg seems to need a new patch by David Turner though which avoids
that libXfont uses internal freetype APIs.

See:

https://bugs.freedesktop.org/show_bug.cgi?id=6918

This patch is applied by now. The previous freetype module patch to prevent the crash is obsolete. Closing as fixed.