Hi,

Am 14. November 2011 15:04 schrieb Friedrich Romstedt
<friedrichromst...@gmail.com>:
> 2011/11/14 Michael Droettboom <md...@stsci.edu>:
>> Thanks for all the time you've devoted to this.  It does look like possibly
>> some kind of compiler bug.  The font loads and renders fine on Linux, for
>> what it's worth (just as a data point).
>>
>> To confirm this theory: if you move NISC1803.ttf somewhere temporary, delete
>> ~/.matplotlibrc/fontList.cache and then import matplotlib, do you get the
>> crash?  That at least confirms that loading this font file triggers the bug
>> (wherever the bug may be).  Test with matplotlib 1.1.0 or git master so we
>> have a sense of the current behavior.
>
> Hi Mike,
>
> the following fonts on my system are offending:
>
> /Library/Fonts/NISC18030.ttf
> /Library/Fonts/AppleMyungjo.ttf
> /Library/Fonts/Gungseouche.ttf
>
> With these fonts made unfindable by matplotlib (:file:`*.ttf_`) it
> exits cleanly.
>
> I will provide with a patch to matplotlib for an rc setting
> "fonts.bus-error : ...", e.g. ``fonts.bus-error : NISC18030.ttf,
> AppleMyungjo.ttf, Gungseouche.ttf`` in the next days.

I just took the time to recompile the whole thingy, including
supporting libraries.  I used:

–  libfreetype-2.4.9
–  matplotlib-1.1.0
–  MACOSX_DEPLOYMENT_TARGET=10.5
–  The files noted in the citation above are in place (i.e.,
accessible as .ttf files)

My theory was that a compiler error triggers the error with the font
files in question.  Because recompiling ft2font.so with a different
MACOSX_DEPLOYMENT_TARGET made the crash disappear I supposed that
ft2font would trigger that compiler error.  It needed to be a compiler
error because that environment variable was the only change that made
the crash disappear.  Now it is the question if with more recent
software that error still persists.  I have found that this is not the
case.  I recompiled with the libraries noted above (all compiled from
source), and I can successfully import matplotlib.figure.  This import
previously provoked the crash.  So I believe that either I was wrong
in some respect, or the more recent software toolchain no longer
provokes the crash, because its code changed.  Since it works just
flawlessly on my system now, I see little need to implement the
mechanism for excluding font files from being loaded – if it is not
needed I will not code it.

Friedrich

P.S.: Of course I moved the font cache before, so that it is recreated
when importing matplotlib.figure for the first time.
P.P.S.: One more difference is that the current Python is not a
framework Python anymore, but a regular Python.

> It was clear from the beginning (well, from the point I got a handle
> on it), that loading the font makes the 2009 matplotlib crash.  The
> only question unanswered is where the codepath is that triggers this
> compiler bug (I think the compiler but hypothesis is not disproven and
> works well atm).  If the code path is in ft2font.cpp, we could (you
> could) reformulate ft2font.cpp in an equivalent way with the exception
> that it is not equivalent in crashing.  You might want to augment
> ft2font.cpp by printf() or something to see if the crash appears
> inside a call to libfreetype or if all those calls return cleanly.
>
> To my understanding, since recompiling ft2font.so without
> MACOSX_DEPLOYMENT_TARGET different from 10.6 helps, ft2font.cpp should
> be the culprit resp. victim.  The only alternative I'm seeing would be
> that it has to to do with the load mechanism of the dylib, but I deem
> this rather unlikely.  Well, unlikely is not the best word in this
> context, since all this things here were pretty unlikely.
>
> If the codepath is in libfreetype this would be an issue for their list. ...
>
> Friedrich

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Reply via email to