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
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?
-- 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
Could you try a “divide and conquer” approach to narrow down which svn revision introduced the breakage. I realize this is tedious, especially since the bug manifestation is variable, but it if we could figure out the revision number, we’d be more likely to be able to fix it.
···
On Mon, Dec 20, 2010 at 6:31 PM, Russell E. Owen <rowen@…552…748…> wrote:
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
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](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.
2010/12/21 Russell E. Owen <rowen@...748...>:
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
> 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