Re: [matplotlib-devel] trunk rev 8843 crash on Snow Leopard

[Friedrich R. <fri...@gm...>]

2010/12/21 Russell E. Owen <ro...@uw...>:
> I built a binary installer for matplotlib trunk rev 8843 (because it
> leaks memory less than 1.0.0 release). I built it the same way I built
> the 1.0.0 binary
> <http://www.astro.washington.edu/users/rowen/BuildingMatplotlibForMac.htm
> l> on Mac OS X 10.4 using python.org Python 2.6.x (where x is probably
> 6).
>
> The binary is available here:
> <http://www.astro.washington.edu/users/rowen/python/matplotlib-1.0.0+svn8
> 843-python.org-py2.6-macosx10.3.dmg>
>
> It work fine on Mac OS X 10.4 and 10.5, but on 10.6 attempting to import
> pylab almost always segfaults (and the few times I've gotten it to work
> on 10.6 I can break it by deleting ~/.fontconfig and ~/.matplotlib and
> running Python again). I've tried it on newly created accounts and it
> segfaults. Another user of Snow Leopard first reported the problem. So
> it's not just me.
>
> I've appended part of a crash log.
>
> I built this binary the same way I built the matplotlib 1.0.0 binary,
> which has no problems.
>
> Any ideas?

Yap; did you make any progress on this?

I found that approximately that time on my machine was the
NISC18030.ttf font installed (I see it from the date of birth) and it
breaks the FontManager of nearly all matplotlibs including the recent
one (from last week).

Friedrich

> -- Russell
>
> Exception Type:  EXC_BAD_ACCESS (SIGABRT)
> Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
> Crashed Thread:  0  Dispatch queue: com.apple.main-thread
>
> Application Specific Information:
> abort() called
>
> Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
> 0   libSystem.B.dylib               0x90e1b176 __kill + 10
> 1   libSystem.B.dylib               0x90e1b168 kill$UNIX2003 + 32
> 2   libSystem.B.dylib               0x90ead89d raise + 26
> 3   libSystem.B.dylib               0x90ec39bc abort + 93
> 4   org.python.python               0x004e3e99 Py_FatalError + 73
> 5   libSystem.B.dylib               0x90e2046b _sigtramp + 43
> 6   ???                             0000000000 0 + 0
> 7   libSystem.B.dylib               0x90e29378
> _Unwind_GetLanguageSpecificData + 24
> 8   libstdc++.6.dylib               0x940c4d86 __gxx_personality_v0 + 120
> 9   libgcc_s.1.dylib                0x0389f476 _Unwind_Backtrace + 278
> 10  libgcc_s.1.dylib                0x0389f890 _Unwind_Resume + 112
> 11  ft2font.so                      0x03d5c3a3
> FT2Font::FT2Font(std::string) + 4385
> 12  ft2font.so                      0x03d5c805
> ft2font_module::new_ft2font(Py::Tuple const&) + 505
> 13  ft2font.so                      0x03dc89c2
> Py::ExtensionModule<ft2font_module>::invoke_method_varargs(void*,
> Py::Tuple const&) + 90
> 14  ft2font.so                      0x03d7170c
> method_varargs_call_handler + 342
> 15  org.python.python               0x004bcd25 PyEval_EvalFrameEx + 19429
> 16  org.python.python               0x004bee9d PyEval_EvalCodeEx + 2109
> 17  org.python.python               0x004bcf0c PyEval_EvalFrameEx + 19916

Michael, here you probably have the traceback you asked for (assumed
I'm right with my assumption above) :-)

Friedrich