From: Friedrich R. <fri...@gm...> - 2011-11-14 14:04:34
|
2011/11/14 Michael Droettboom <md...@st...>: > 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. 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 |