matplotlib-devel Mailing List for matplotlib

Here is sample code demonstrating the problem I'm having with
pyhd5/numpy/matplotlib
import h5py
import numpy
import re
import sys
import os
import gtk
import pdb
import gc
from matplotlib.figure import Figure
from matplotlib.backends.backend_gtkagg import FigureCanvasGTKAgg as
FigureCanvas
def doplot(widget,box1):
 id=h5py.h5f.open("MLS-Aura_L1BRADD_v02-23-c01_2009d001.h5")
 data_id = h5py.h5d.open(id,"R1A:118.B22D:PT.S0.DACS-4")
 dataspaceID = h5py.h5d.DatasetID.get_space(data_id)
 noDims = h5py.h5s.SpaceID.get_simple_extent_ndims(dataspaceID)
 dims = h5py.h5s.SpaceID.get_simple_extent_dims(dataspaceID)
 start=tuple([0]*noDims)
 h5py.h5s.SpaceID.select_hyperslab(dataspaceID,start,dims,None,None,
 h5py.h5s.SELECT_SET)
 memory_space_id = h5py.h5s.create_simple(dims)
 data=numpy.memmap('tmpdat',dtype=numpy.float64,mode='w+',shape=dims)
 h5py.h5d.DatasetID.read(data_id,memory_space_id,dataspaceID,data)
 del data
 data=numpy.memmap('tmpdat',dtype=numpy.float64,mode='r',shape=dims)
 fig = Figure(figsize=(5,5), dpi=100)
 ax = fig.add_subplot(111)
 plot_data=data[0,0:,0]
 mif=numpy.arange(plot_data.shape[0])
 #if the next line is commented out, all is good
 ax.plot(plot_data,mif)
 canvas = FigureCanvas(fig)
 box1.pack_start(canvas, True, True, 0)
 canvas.show()
 id.close()
 del data
 del fig
 del ax
 del plot_data
 del canvas
 gc.collect()
 #the following line fails
 os.remove('tmpdat')
def delete_event(widget, event, data=None):
 return False
window = gtk.Window(gtk.WINDOW_TOPLEVEL)
window.connect("destroy", lambda x: gtk.main_quit())
box1 = gtk.HBox(False, 0)
window.add(box1)
button = gtk.Button("Hello World")
box1.pack_start(button, True, True, 0)
#window.add(box1)
button.show()
button.connect("clicked", doplot, box1)
box1.show()
window.set_default_size(500,400)
window.show()
gtk.main()

On Mon, Nov 30, 2009 at 12:14 PM, Matthew Brett <mat...@gm...> wrote:
> Hi,
>
> Can I suggest the following generalization in the make.osx make file?
> It makes it a bit easier to configure for odd builds like mine...
>
Sure -- committed to svn HEAD.
Thanks,
JDH

Hi,
Can I suggest the following generalization in the make.osx make file?
It makes it a bit easier to configure for odd builds like mine...
Thanks a lot,
Matthew

Hi,
>>  I've been having an almost identical problem with described above with
>> the MacOSX backend. When I switched to the TkAgg backend, the segfault
>> occurs when I try pylab.close() instead.
>>
> I may have had the same problem. Do you happen to be on a recent revision?
>
> Christoph Gohlke pointed out a typo introduced in r7985 (see bug report). The patch below fixed the segfaults on my system.
Yes - thanks - segfault gone for me...
Cheers,
Matthew

Andrew Straw wrote:
> I'm a little mystified as to the actual cause, but it 
> again looks like some freetype problem. Mike, do you think it could 
> somehow be related to your recent font work?
>
> 
OK, in the absence of a fix, I just checked in the images that were 
being generated. They didn't look too bad -- probably just a weird 
freetype font hinting difference between the original and re-generated 
images.
Anyhow, now all the tests are passing again, and therefore we shouldn't 
have any more severe bugs like that in r7985 creeping in unnoticed. I 
take this as evidence that it's good to fix (or disable) minor failing 
tests right away so they don't obscure more severe failures.

Tony S Yu wrote:
>
> On Nov 30, 2009, at 4:34 AM, Andrew Straw wrote:
>> However, with svn r7985, the trunk fails to find the tests. This is so
>> weird. There's nothing in that commit that I can see that should cause
>> the failure, but it seems repeatable. r7984 doesn't have it and r7985
>> does. And it appears to be more or less the issue that the scons branch
>> had. Sigh.
>
> Could this failure be related to the bug filed by Christoph Gohlke 
> (see tracker 
> <http://sourceforge.net/tracker/?func=detail&aid=2903596&group_id=80706&atid=560720>)? 
> The change corresponds to r7985 and affects setupext.py. I'm not sure 
> if the numscons build uses setupext.py, but it may be worth checking out.
Thanks Tony (and Christoph) -- this fixed it.
I wonder why I wasn't getting a more severe error on linux? This might 
offer a clue as to the testing weirdness we've been experiencing lately.
Anyhow, I got the tests passing on the buildbots again so that we should 
immediately be notified upon new failures. I think we need to work hard 
to keep the buildbots green so we can catch things like this.
-Andrew

On Nov 30, 2009, at 9:09 AM, Jcmottram wrote:
> 
> Hi,
> I've been having an almost identical problem with described above with
> the MacOSX backend. When I switched to the TkAgg backend, the segfault
> occurs when I try pylab.close() instead. 
> 
> 
I may have had the same problem. Do you happen to be on a recent revision?
Christoph Gohlke pointed out a typo introduced in r7985 (see bug report). The patch below fixed the segfaults on my system.
Best,
-Tony
Index: setupext.py
===================================================================
--- setupext.py	(revision 7987)
+++ setupext.py	(working copy)
@@ -122,7 +122,7 @@
 'backend': None}
 
 defines = [
-	('PY_ARRAYAUNIQUE_SYMBOL', 'MPL_ARRAY_API'),
+	('PY_ARRAY_UNIQUE_SYMBOL', 'MPL_ARRAY_API'),
 	('PYCXX_ISO_CPP_LIB', '1')]
 
 # Based on the contents of setup.cfg, determine the build options

Sorry this thread fell through the cracks. Thanks for the reminder.
The error is not actually on importing and parsing the .py file (it 
seems to do that just fine). The error is on printing to the console, 
at which point it tries to convert the Unicode string to ascii (which 
fails because it has character points > 127). One way around this is to 
encode Unicode as UTF-8 (which seems to be the default for most modern 
Linux X terminals etc.), eg.:
 print(u"accent aigus é".encode("utf8"))
Mike
On 11/25/2009 02:11 PM, Sébastien Barthélemy wrote:
> Hi,
>
> just wanted to raise this problem on the devel list, where it probably 
> belongs. Also, if nobody has time to look at it now and you prefer me 
> to file a bug, please don't hesitate to tell it.
>
> the original post is there: 
> http://thread.gmane.org/gmane.comp.python.matplotlib.general/20411
>
> Cheers
>
> Le 21 novembre 2009 17:50, Sébastien Barthélemy <bar...@cr... 
> <mailto:bar...@cr...>> a écrit :
>
> Le 18 novembre 2009 17:24, Michael Droettboom <md...@st...
> <mailto:md...@st...>> a écrit :
>
> This is a bug -- but it has a fairly straightforward fix: to
> use Sphinx's "include" directive rather than roll our own as
> we currently do. This has been fixed in SVN r7972.
> plot-directive now takes an "encoding" option, exactly like
> the Sphinx include directive. It does not do automatic
> encoding detection (meaning it ignores the "# coding: latin1"
> comments), just as the Sphinx include directive does.
>
>
> Hello Michael,
>
> thank you for your fast reply and action. I just tried with the
> version from trunk (r7978) and I still have an encoding problem on
> the same test case. It seems to happen when the file is ran (to
> produce the figure) rather than when it is included. I had a look
> at the code, but cannot understand what is happenning, I would
> have expected imp to proprely guess the encoding.
>
> Could you tell me if you have the same problem ? Do you have any
> idea of what is going on ?
>
> Thanks !
>
> $ git clone git://github.com/sbarthelemy/SphinxEncoding.git
> <http://github.com/sbarthelemy/SphinxEncoding.git>
> $ cd SphinxEncoding/
> $ make html
> sphinx-build -b html -d _build/doctrees . _build/html
> Making output directory...
> Running Sphinx v0.6.2
> loading pickled environment... not found
> building [html]: targets for 1 source files that are out of date
> updating environment: 1 added, 0 changed, 0 removed
> /home/barthelemy/.local/lib/python2.6/site-packages/matplotlib/sphinxext/plot_directive.py:273:
> UserWarning: Exception running plot ./fileutf8.py
> Traceback (most recent call last):
> File
> "/home/barthelemy/.local/lib/python2.6/site-packages/matplotlib/sphinxext/plot_directive.py",
> line 270, in render_figures
> run_code(plot_path, function_name, plot_code)
> File
> "/home/barthelemy/.local/lib/python2.6/site-packages/matplotlib/sphinxext/plot_directive.py",
> line 182, in run_code
> "__plot__", fd, fname, ('py', 'r', imp.PY_SOURCE))
> File "fileutf8.py", line 2, in <module>
> print(u"accent aigus é")
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9'
> in position 13: ordinal not in range(128)
>
>

On Nov 30, 2009, at 4:34 AM, Andrew Straw wrote:
> However, with svn r7985, the trunk fails to find the tests. This is so 
> weird. There's nothing in that commit that I can see that should cause 
> the failure, but it seems repeatable. r7984 doesn't have it and r7985 
> does. And it appears to be more or less the issue that the scons branch 
> had. Sigh.
Could this failure be related to the bug filed by Christoph Gohlke (see tracker)? The change corresponds to r7985 and affects setupext.py. I'm not sure if the numscons build uses setupext.py, but it may be worth checking out.
-Tony

Hi,
 I've been having an almost identical problem with described above with
the MacOSX backend. When I switched to the TkAgg backend, the segfault
occurs when I try pylab.close() instead. 
Do you get the segmentation fault also with other backends (e.g. Tkagg) or
only with the MacOSX backend?
-- 
View this message in context: http://old.nabble.com/Segmentation-fault-from-fresh-OSX-snow-leopard-build-tp26560316p26575340.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Do you get the segmentation fault also with other backends (e.g. Tkagg) or only with the MacOSX backend?
--Michiel.
--- On Sun, 11/29/09, Matthew Brett <mat...@gm...> wrote:
> From: Matthew Brett <mat...@gm...>
> Subject: Re: [matplotlib-devel] Segmentation fault from fresh OSX snow leopard build
> To: mat...@li...
> Date: Sunday, November 29, 2009, 1:26 PM
> On Sun, Nov 29, 2009 at 9:49 AM,
> Jouni K. Seppänen <jk...@ik...> wrote:
> > Matthew Brett <mat...@gm...>
> > writes:
> >
> >>> Can you get a backtrace in gdb?
> >>
> >> Program received signal EXC_BAD_ACCESS, Could not
> access memory.
> >> Reason: 13 at address: 0x0000000000000000
> >> 0x0000000102d96ffb in
> py_to_agg_transformation_matrix
> >> (obj=0x102d794d0, errors=false) at
> src/agg_py_transforms.cpp:21
> >> 21      matrix = (PyArrayObject*)
> PyArray_FromObject(obj,
> >> PyArray_DOUBLE, 2, 2);
> >
> > Can you type "bt" in gdb at this point to see the
> whole call stack?
> 
> Sorry - yes - here:
> 
> Program received signal EXC_BAD_ACCESS, Could not access
> memory.
> Reason: 13 at address: 0x0000000000000000
> 0x0000000102cf703b in py_to_agg_transformation_matrix
> (obj=0x102cde590, errors=false) at
> src/agg_py_transforms.cpp:21
> 21      matrix =
> (PyArrayObject*) PyArray_FromObject(obj,
> PyArray_DOUBLE, 2, 2);
> (gdb) bt
> #0 0x0000000102cf703b in
> py_to_agg_transformation_matrix
> (obj=0x102cde590, errors=false) at
> src/agg_py_transforms.cpp:21
> #1 0x0000000102cf762c in get_path_iterator
> (path=0x102cde710,
> trans=<value temporarily unavailable, due to
> optimizations>,
> remove_nans=1, do_clip=0, rect=0x7fff5fbf9480,
> quantize_mode=QUANTIZE_AUTO, do_simplify=1) at
> src/path_cleanup.cpp:58
> #2 0x0000000102ce9e90 in GraphicsContext_draw_path
> (self=0x102cd19d0,
> args=<value temporarily unavailable, due to
> optimizations>) at
> src/_macosx.m:881
> #3 0x00000001000b31d8 in PyEval_EvalFrameEx
> (f=0x102b65f50,
> throwflag=<value temporarily unavailable, due to
> optimizations>) at
> Python/ceval.c:3706
> #4 0x00000001000b3f30 in PyEval_EvalCodeEx
> (co=0x102cd0be8,
> globals=<value temporarily unavailable, due to
> optimizations>,
> locals=<value temporarily unavailable, due to
> optimizations>,
> args=0x102b61900, argcount=5, kws=0x102b61928, kwcount=0,
> defs=0x102cde1a8, defcount=1, closure=0x0) at
> Python/ceval.c:2968
> #5 0x00000001000b1f1d in fast_function [inlined] ()
> at
> /Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3802
> #6 0x00000001000b1f1d in PyEval_EvalFrameEx
> (f=0x102b61720,
> throwflag=<value temporarily unavailable, due to
> optimizations>) at
> Python/ceval.c:3727
> #7 0x00000001000b3f30 in PyEval_EvalCodeEx
> (co=0x10180ceb8,
> globals=<value temporarily unavailable, due to
> optimizations>,
> locals=<value temporarily unavailable, due to
> optimizations>,
> args=0x102cae2a8, argcount=2, kws=0x0, kwcount=0,
> defs=0x0,
> defcount=0, closure=0x0) at Python/ceval.c:2968
> #8 0x00000001000362a5 in function_call
> (func=0x101839b18,
> arg=0x102cae290, kw=0x0) at Objects/funcobject.c:524
> #9 0x0000000100006fe2 in PyObject_Call
> (func=0x101839b18,
> arg=0x102cae290, kw=0x0) at Objects/abstract.c:2492
> #10 0x00000001000ae352 in PyEval_EvalFrameEx
> (f=0x102b61530,
> throwflag=<value temporarily unavailable, due to
> optimizations>) at
> Python/ceval.c:4019
> #11 0x00000001000b3f30 in PyEval_EvalCodeEx
> (co=0x1014647b0,
> globals=<value temporarily unavailable, due to
> optimizations>,
> locals=<value temporarily unavailable, due to
> optimizations>,
> args=0x102b61100, argcount=2, kws=0x102b61110, kwcount=0,
> defs=0x0,
> defcount=0, closure=0x101825dc0) at Python/ceval.c:2968
> #12 0x00000001000b1f1d in fast_function [inlined] () at
> /Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3802
> #13 0x00000001000b1f1d in PyEval_EvalFrameEx
> (f=0x102b60f00,
> throwflag=<value temporarily unavailable, due to
> optimizations>) at
> Python/ceval.c:3727
> #14 0x00000001000b3f30 in PyEval_EvalCodeEx
> (co=0x102c90288,
> globals=<value temporarily unavailable, due to
> optimizations>,
> locals=<value temporarily unavailable, due to
> optimizations>,
> args=0x102cae260, argcount=2, kws=0x0, kwcount=0,
> defs=0x0,
> defcount=0, closure=0x0) at Python/ceval.c:2968
> #15 0x00000001000362a5 in function_call (func=0x102cad1b8,
> arg=0x102cae248, kw=0x0) at Objects/funcobject.c:524
> #16 0x0000000100006fe2 in PyObject_Call (func=0x102cad1b8,
> arg=0x102cae248, kw=0x0) at Objects/abstract.c:2492
> #17 0x00000001000ae352 in PyEval_EvalFrameEx
> (f=0x102b607f0,
> throwflag=<value temporarily unavailable, due to
> optimizations>) at
> Python/ceval.c:4019
> #18 0x00000001000b3f30 in PyEval_EvalCodeEx
> (co=0x1014647b0,
> globals=<value temporarily unavailable, due to
> optimizations>,
> locals=<value temporarily unavailable, due to
> optimizations>,
> args=0x102cae218, argcount=2, kws=0x0, kwcount=0,
> defs=0x0,
> defcount=0, closure=0x102c8d6e0) at Python/ceval.c:2968
> #19 0x00000001000362a5 in function_call (func=0x102cad320,
> arg=0x102cae200, kw=0x0) at Objects/funcobject.c:524
> #20 0x0000000100006fe2 in PyObject_Call (func=0x102cad320,
> arg=0x102cae200, kw=0x0) at Objects/abstract.c:2492
> #21 0x000000010001905d in instancemethod_call
> (func=0x102cad320,
> arg=0x102cae200, kw=0x0) at Objects/classobject.c:2579
> #22 0x0000000100006fe2 in PyObject_Call (func=0x102aa7fa0,
> arg=0x100438c90, kw=0x0) at Objects/abstract.c:2492
> #23 0x000000010000a760 in call_function_tail [inlined] ()
> at
> /Users/mb312/stable_trees/Python-2.6.4/Objects/abstract.c:2524
> #24 0x000000010000a760 in PyObject_CallMethod (o=<value
> temporarily
> unavailable, due to optimizations>, name=<value
> temporarily
> unavailable, due to optimizations>, format=0x102cfd504
> "O") at
> Objects/abstract.c:2601
> #25 0x0000000102ce5653 in -[View drawRect:]
> (self=0x102b50960,
> _cmd=<value temporarily unavailable, due to
> optimizations>,
> rect={origin = {x = 0, y = 0}, size = {width = 640, height
> = 480}}) at
> src/_macosx.m:4517
> #26 0x00007fff8676afae in -[NSView _drawRect:clip:] ()
> #27 0x00007fff86769c21 in -[NSView
> _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
> #28 0x00007fff86769f8b in -[NSView
> _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
> #29 0x00007fff86769f8b in -[NSView
> _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
> #30 0x00007fff867682f3 in -[NSView
> _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
> ()
> #31 0x00007fff86767e17 in -[NSThemeFrame
> _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
> ()
> #32 0x00007fff867646bf in -[NSView
> _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:]
> ()
> #33 0x00007fff866ddf37 in -[NSView displayIfNeeded] ()
> #34 0x00007fff866a5f87 in -[NSWindow
> _reallyDoOrderWindow:relativeTo:findKey:forCounter:force:isModal:]
> ()
> #35 0x00007fff866a5b1c in -[NSWindow
> orderWindow:relativeTo:] ()
> #36 0x00007fff866a349e in -[NSWindow makeKeyAndOrderFront:]
> ()
> #37 0x0000000102ce490e in FigureManager_init
> (self=0x102d30908,
> args=<value temporarily unavailable, due to
> optimizations>,
> kwds=<value temporarily unavailable, due to
> optimizations>) at
> src/_macosx.m:3338
> #38 0x000000010006533c in wrap_init (self=<value
> temporarily
> unavailable, due to optimizations>, args=<value
> temporarily
> unavailable, due to optimizations>, wrapped=<value
> temporarily
> unavailable, due to optimizations>, kwds=<value
> temporarily
> unavailable, due to optimizations>) at
> Objects/typeobject.c:4694
> #39 0x0000000100006fe2 in PyObject_Call (func=0x102cde6d0,
> arg=0x102cae1b8, kw=0x0) at Objects/abstract.c:2492
> #40 0x00000001000ab047 in PyEval_CallObjectWithKeywords
> (func=0x102cde6d0, arg=0x102cae1b8, kw=0x0) at
> Python/ceval.c:3575
> #41 0x0000000100024164 in wrapperdescr_call
> (descr=<value temporarily
> unavailable, due to optimizations>, args=0x102cae1b8,
> kwds=0x0) at
> Objects/descrobject.c:304
> #42 0x0000000100006fe2 in PyObject_Call (func=0x102cbecd0,
> arg=0x102c72b40, kw=0x0) at Objects/abstract.c:2492
> #43 0x00000001000af47e in do_call [inlined] () at
> /Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3924
> #44 0x00000001000af47e in call_function [inlined] () at
> /Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3729
> #45 0x00000001000af47e in PyEval_EvalFrameEx
> (f=0x102b56400,
> throwflag=<value temporarily unavailable, due to
> optimizations>) at
> Python/ceval.c:2389
> #46 0x00000001000b3f30 in PyEval_EvalCodeEx
> (co=0x102cd5f30,
> globals=<value temporarily unavailable, due to
> optimizations>,
> locals=<value temporarily unavailable, due to
> optimizations>,
> args=0x3, argcount=3, kws=0x0, kwcount=0, defs=0x0,
> defcount=0,
> closure=0x0) at Python/ceval.c:2968
> #47 0x00000001000362a5 in function_call (func=0x102cdfc80,
> arg=0x1002a4910, kw=0x0) at Objects/funcobject.c:524
> #48 0x0000000100006fe2 in PyObject_Call (func=0x102cdfc80,
> arg=0x1002a4910, kw=0x0) at Objects/abstract.c:2492
> #49 0x000000010001905d in instancemethod_call
> (func=0x102cdfc80,
> arg=0x1002a4910, kw=0x0) at Objects/classobject.c:2579
> #50 0x0000000100006fe2 in PyObject_Call (func=0x102aa7e60,
> arg=0x102c84128, kw=0x0) at Objects/abstract.c:2492
> #51 0x000000010006bf18 in slot_tp_init (self=<value
> temporarily
> unavailable, due to optimizations>, args=0x102c84128,
> kwds=0x0) at
> Objects/typeobject.c:5638
> #52 0x0000000100068b65 in type_call (type=0x102b44b30,
> args=0x102c84128, kwds=0x0) at Objects/typeobject.c:745
> #53 0x0000000100006fe2 in PyObject_Call (func=0x102b44b30,
> arg=0x102c84128, kw=0x0) at Objects/abstract.c:2492
> #54 0x00000001000af47e in do_call [inlined] () at
> /Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3924
> #55 0x00000001000af47e in call_function [inlined] () at
> /Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3729
> #56 0x00000001000af47e in PyEval_EvalFrameEx
> (f=0x102b3d120,
> throwflag=<value temporarily unavailable, due to
> optimizations>) at
> Python/ceval.c:2389
> #57 0x00000001000b3f30 in PyEval_EvalCodeEx
> (co=0x102cd5738,
> globals=<value temporarily unavailable, due to
> optimizations>,
> locals=<value temporarily unavailable, due to
> optimizations>,
> args=0x102cce848, argcount=1, kws=0x102b48370, kwcount=6,
> defs=0x0,
> defcount=0, closure=0x0) at Python/ceval.c:2968
> #58 0x00000001000363ad in function_call (func=0x102cdf6e0,
> arg=0x100421450, kw=0x101526720) at
> Objects/funcobject.c:524
> #59 0x0000000100006fe2 in PyObject_Call (func=0x102cdf6e0,
> arg=0x100421450, kw=0x101526720) at
> Objects/abstract.c:2492
> #60 0x00000001000ae352 in PyEval_EvalFrameEx
> (f=0x101526a60,
> throwflag=<value temporarily unavailable, due to
> optimizations>) at
> Python/ceval.c:4019
> #61 0x00000001000b3f30 in PyEval_EvalCodeEx
> (co=0x102cb5a08,
> globals=<value temporarily unavailable, due to
> optimizations>,
> locals=<value temporarily unavailable, due to
> optimizations>,
> args=0x8, argcount=0, kws=0x102b48188, kwcount=0,
> defs=0x102ccea08,
> defcount=7, closure=0x0) at Python/ceval.c:2968
> #62 0x00000001000b1f1d in fast_function [inlined] () at
> /Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3802
> #63 0x00000001000b1f1d in PyEval_EvalFrameEx
> (f=0x102b48000,
> throwflag=<value temporarily unavailable, due to
> optimizations>) at
> Python/ceval.c:3727
> #64 0x00000001000b237a in PyEval_EvalFrameEx
> (f=0x100357cf0,
> throwflag=<value temporarily unavailable, due to
> optimizations>) at
> Python/ceval.c:3792
> #65 0x00000001000b3f30 in PyEval_EvalCodeEx
> (co=0x102cb84e0,
> globals=<value temporarily unavailable, due to
> optimizations>,
> locals=<value temporarily unavailable, due to
> optimizations>,
> args=0x10035a950, argcount=0, kws=0x10035a950, kwcount=0,
> defs=0x0,
> defcount=0, closure=0x0) at Python/ceval.c:2968
> #66 0x00000001000b1f1d in fast_function [inlined] () at
> /Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3802
> #67 0x00000001000b1f1d in PyEval_EvalFrameEx
> (f=0x10035a7a0,
> throwflag=<value temporarily unavailable, due to
> optimizations>) at
> Python/ceval.c:3727
> #68 0x00000001000b3f30 in PyEval_EvalCodeEx
> (co=0x102cc4738,
> globals=<value temporarily unavailable, due to
> optimizations>,
> locals=<value temporarily unavailable, due to
> optimizations>,
> args=0x102cc0c30, argcount=2, kws=0x100359160, kwcount=1,
> defs=0x0,
> defcount=0, closure=0x0) at Python/ceval.c:2968
> #69 0x00000001000b1f1d in fast_function [inlined] () at
> /Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3802
> #70 0x00000001000b1f1d in PyEval_EvalFrameEx
> (f=0x100358fd0,
> throwflag=<value temporarily unavailable, due to
> optimizations>) at
> Python/ceval.c:3727
> #71 0x00000001000b3f30 in PyEval_EvalCodeEx
> (co=0x100426f30,
> globals=<value temporarily unavailable, due to
> optimizations>,
> locals=<value temporarily unavailable, due to
> optimizations>,
> args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
> defcount=0,
> closure=0x0) at Python/ceval.c:2968
> #72 0x00000001000b4016 in PyEval_EvalCode (co=<value
> temporarily
> unavailable, due to optimizations>, globals=<value
> temporarily
> unavailable, due to optimizations>, locals=<value
> temporarily
> unavailable, due to optimizations>) at
> Python/ceval.c:522
> #73 0x00000001000d8a5e in run_mod [inlined] () at
> /Users/mb312/stable_trees/Python-2.6.4/Python/pythonrun.c:1335
> #74 0x00000001000d8a5e in PyRun_FileExFlags
> (fp=0x7fff7092be80,
> filename=0x7fff5fbfe17a
> "scipybuild/matplotlib/examples/pylab_examples/simple_plot.py",
> start=<value temporarily unavailable, due to
> optimizations>,
> globals=0x100312ec0, locals=0x100312ec0, closeit=1,
> flags=0x7fff5fbfdfb0) at Python/pythonrun.c:1321
> #75 0x00000001000d8d19 in PyRun_SimpleFileExFlags
> (fp=0x7fff7092be80,
> filename=0x7fff5fbfe17a
> "scipybuild/matplotlib/examples/pylab_examples/simple_plot.py",
> closeit=1, flags=0x7fff5fbfdfb0) at Python/pythonrun.c:931
> #76 0x00000001000e835c in Py_Main (argc=2523360,
> argv=0x7fff5fbfe010)
> at Modules/main.c:599
> #77 0x0000000100001544 in start ()
> Current language: auto; currently c++
> 
> 
> Mathew
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal
> Reports 2008 30-Day 
> trial. Simplify your report design, integration and
> deployment - and focus on 
> what you do best, core application coding. Discover what's
> new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
 

David Cournapeau wrote:
> Andrew Straw wrote:
> 
>> I looked a little further, and it depends on the directory that the
>> tests are run from -- if I manually log into the build slave, I can
>> get the tests to run (in fact, one segfaults) if I try from a
>> different working directory. Anyhow, now that I have a handle on it, I
>> think I can probably get it working... Give me a couple days.
>> 
>
> great.
> 
Well, now the scons branch tests run properly (until they hit a segfault 
on matplotlib.tests.test_axes.test_basic_annotate)
However, with svn r7985, the trunk fails to find the tests. This is so 
weird. There's nothing in that commit that I can see that should cause 
the failure, but it seems repeatable. r7984 doesn't have it and r7985 
does. And it appears to be more or less the issue that the scons branch 
had. Sigh.
Don't forget to pass on your sourceforge username to John to get svn 
commit access. I think the scons build option should get merged into the 
trunk.
-Andrew

On Sun, Nov 29, 2009 at 9:49 AM, Jouni K. Seppänen <jk...@ik...> wrote:
> Matthew Brett <mat...@gm...>
> writes:
>
>>> Can you get a backtrace in gdb?
>>
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: 13 at address: 0x0000000000000000
>> 0x0000000102d96ffb in py_to_agg_transformation_matrix
>> (obj=0x102d794d0, errors=false) at src/agg_py_transforms.cpp:21
>> 21      matrix = (PyArrayObject*) PyArray_FromObject(obj,
>> PyArray_DOUBLE, 2, 2);
>
> Can you type "bt" in gdb at this point to see the whole call stack?
Sorry - yes - here:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x0000000102cf703b in py_to_agg_transformation_matrix
(obj=0x102cde590, errors=false) at src/agg_py_transforms.cpp:21
21	 matrix = (PyArrayObject*) PyArray_FromObject(obj,
PyArray_DOUBLE, 2, 2);
(gdb) bt
#0 0x0000000102cf703b in py_to_agg_transformation_matrix
(obj=0x102cde590, errors=false) at src/agg_py_transforms.cpp:21
#1 0x0000000102cf762c in get_path_iterator (path=0x102cde710,
trans=<value temporarily unavailable, due to optimizations>,
remove_nans=1, do_clip=0, rect=0x7fff5fbf9480,
quantize_mode=QUANTIZE_AUTO, do_simplify=1) at src/path_cleanup.cpp:58
#2 0x0000000102ce9e90 in GraphicsContext_draw_path (self=0x102cd19d0,
args=<value temporarily unavailable, due to optimizations>) at
src/_macosx.m:881
#3 0x00000001000b31d8 in PyEval_EvalFrameEx (f=0x102b65f50,
throwflag=<value temporarily unavailable, due to optimizations>) at
Python/ceval.c:3706
#4 0x00000001000b3f30 in PyEval_EvalCodeEx (co=0x102cd0be8,
globals=<value temporarily unavailable, due to optimizations>,
locals=<value temporarily unavailable, due to optimizations>,
args=0x102b61900, argcount=5, kws=0x102b61928, kwcount=0,
defs=0x102cde1a8, defcount=1, closure=0x0) at Python/ceval.c:2968
#5 0x00000001000b1f1d in fast_function [inlined] () at
/Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3802
#6 0x00000001000b1f1d in PyEval_EvalFrameEx (f=0x102b61720,
throwflag=<value temporarily unavailable, due to optimizations>) at
Python/ceval.c:3727
#7 0x00000001000b3f30 in PyEval_EvalCodeEx (co=0x10180ceb8,
globals=<value temporarily unavailable, due to optimizations>,
locals=<value temporarily unavailable, due to optimizations>,
args=0x102cae2a8, argcount=2, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2968
#8 0x00000001000362a5 in function_call (func=0x101839b18,
arg=0x102cae290, kw=0x0) at Objects/funcobject.c:524
#9 0x0000000100006fe2 in PyObject_Call (func=0x101839b18,
arg=0x102cae290, kw=0x0) at Objects/abstract.c:2492
#10 0x00000001000ae352 in PyEval_EvalFrameEx (f=0x102b61530,
throwflag=<value temporarily unavailable, due to optimizations>) at
Python/ceval.c:4019
#11 0x00000001000b3f30 in PyEval_EvalCodeEx (co=0x1014647b0,
globals=<value temporarily unavailable, due to optimizations>,
locals=<value temporarily unavailable, due to optimizations>,
args=0x102b61100, argcount=2, kws=0x102b61110, kwcount=0, defs=0x0,
defcount=0, closure=0x101825dc0) at Python/ceval.c:2968
#12 0x00000001000b1f1d in fast_function [inlined] () at
/Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3802
#13 0x00000001000b1f1d in PyEval_EvalFrameEx (f=0x102b60f00,
throwflag=<value temporarily unavailable, due to optimizations>) at
Python/ceval.c:3727
#14 0x00000001000b3f30 in PyEval_EvalCodeEx (co=0x102c90288,
globals=<value temporarily unavailable, due to optimizations>,
locals=<value temporarily unavailable, due to optimizations>,
args=0x102cae260, argcount=2, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2968
#15 0x00000001000362a5 in function_call (func=0x102cad1b8,
arg=0x102cae248, kw=0x0) at Objects/funcobject.c:524
#16 0x0000000100006fe2 in PyObject_Call (func=0x102cad1b8,
arg=0x102cae248, kw=0x0) at Objects/abstract.c:2492
#17 0x00000001000ae352 in PyEval_EvalFrameEx (f=0x102b607f0,
throwflag=<value temporarily unavailable, due to optimizations>) at
Python/ceval.c:4019
#18 0x00000001000b3f30 in PyEval_EvalCodeEx (co=0x1014647b0,
globals=<value temporarily unavailable, due to optimizations>,
locals=<value temporarily unavailable, due to optimizations>,
args=0x102cae218, argcount=2, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x102c8d6e0) at Python/ceval.c:2968
#19 0x00000001000362a5 in function_call (func=0x102cad320,
arg=0x102cae200, kw=0x0) at Objects/funcobject.c:524
#20 0x0000000100006fe2 in PyObject_Call (func=0x102cad320,
arg=0x102cae200, kw=0x0) at Objects/abstract.c:2492
#21 0x000000010001905d in instancemethod_call (func=0x102cad320,
arg=0x102cae200, kw=0x0) at Objects/classobject.c:2579
#22 0x0000000100006fe2 in PyObject_Call (func=0x102aa7fa0,
arg=0x100438c90, kw=0x0) at Objects/abstract.c:2492
#23 0x000000010000a760 in call_function_tail [inlined] () at
/Users/mb312/stable_trees/Python-2.6.4/Objects/abstract.c:2524
#24 0x000000010000a760 in PyObject_CallMethod (o=<value temporarily
unavailable, due to optimizations>, name=<value temporarily
unavailable, due to optimizations>, format=0x102cfd504 "O") at
Objects/abstract.c:2601
#25 0x0000000102ce5653 in -[View drawRect:] (self=0x102b50960,
_cmd=<value temporarily unavailable, due to optimizations>,
rect={origin = {x = 0, y = 0}, size = {width = 640, height = 480}}) at
src/_macosx.m:4517
#26 0x00007fff8676afae in -[NSView _drawRect:clip:] ()
#27 0x00007fff86769c21 in -[NSView
_recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#28 0x00007fff86769f8b in -[NSView
_recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#29 0x00007fff86769f8b in -[NSView
_recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#30 0x00007fff867682f3 in -[NSView
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
()
#31 0x00007fff86767e17 in -[NSThemeFrame
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
()
#32 0x00007fff867646bf in -[NSView
_displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:]
()
#33 0x00007fff866ddf37 in -[NSView displayIfNeeded] ()
#34 0x00007fff866a5f87 in -[NSWindow
_reallyDoOrderWindow:relativeTo:findKey:forCounter:force:isModal:] ()
#35 0x00007fff866a5b1c in -[NSWindow orderWindow:relativeTo:] ()
#36 0x00007fff866a349e in -[NSWindow makeKeyAndOrderFront:] ()
#37 0x0000000102ce490e in FigureManager_init (self=0x102d30908,
args=<value temporarily unavailable, due to optimizations>,
kwds=<value temporarily unavailable, due to optimizations>) at
src/_macosx.m:3338
#38 0x000000010006533c in wrap_init (self=<value temporarily
unavailable, due to optimizations>, args=<value temporarily
unavailable, due to optimizations>, wrapped=<value temporarily
unavailable, due to optimizations>, kwds=<value temporarily
unavailable, due to optimizations>) at Objects/typeobject.c:4694
#39 0x0000000100006fe2 in PyObject_Call (func=0x102cde6d0,
arg=0x102cae1b8, kw=0x0) at Objects/abstract.c:2492
#40 0x00000001000ab047 in PyEval_CallObjectWithKeywords
(func=0x102cde6d0, arg=0x102cae1b8, kw=0x0) at Python/ceval.c:3575
#41 0x0000000100024164 in wrapperdescr_call (descr=<value temporarily
unavailable, due to optimizations>, args=0x102cae1b8, kwds=0x0) at
Objects/descrobject.c:304
#42 0x0000000100006fe2 in PyObject_Call (func=0x102cbecd0,
arg=0x102c72b40, kw=0x0) at Objects/abstract.c:2492
#43 0x00000001000af47e in do_call [inlined] () at
/Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3924
#44 0x00000001000af47e in call_function [inlined] () at
/Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3729
#45 0x00000001000af47e in PyEval_EvalFrameEx (f=0x102b56400,
throwflag=<value temporarily unavailable, due to optimizations>) at
Python/ceval.c:2389
#46 0x00000001000b3f30 in PyEval_EvalCodeEx (co=0x102cd5f30,
globals=<value temporarily unavailable, due to optimizations>,
locals=<value temporarily unavailable, due to optimizations>,
args=0x3, argcount=3, kws=0x0, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2968
#47 0x00000001000362a5 in function_call (func=0x102cdfc80,
arg=0x1002a4910, kw=0x0) at Objects/funcobject.c:524
#48 0x0000000100006fe2 in PyObject_Call (func=0x102cdfc80,
arg=0x1002a4910, kw=0x0) at Objects/abstract.c:2492
#49 0x000000010001905d in instancemethod_call (func=0x102cdfc80,
arg=0x1002a4910, kw=0x0) at Objects/classobject.c:2579
#50 0x0000000100006fe2 in PyObject_Call (func=0x102aa7e60,
arg=0x102c84128, kw=0x0) at Objects/abstract.c:2492
#51 0x000000010006bf18 in slot_tp_init (self=<value temporarily
unavailable, due to optimizations>, args=0x102c84128, kwds=0x0) at
Objects/typeobject.c:5638
#52 0x0000000100068b65 in type_call (type=0x102b44b30,
args=0x102c84128, kwds=0x0) at Objects/typeobject.c:745
#53 0x0000000100006fe2 in PyObject_Call (func=0x102b44b30,
arg=0x102c84128, kw=0x0) at Objects/abstract.c:2492
#54 0x00000001000af47e in do_call [inlined] () at
/Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3924
#55 0x00000001000af47e in call_function [inlined] () at
/Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3729
#56 0x00000001000af47e in PyEval_EvalFrameEx (f=0x102b3d120,
throwflag=<value temporarily unavailable, due to optimizations>) at
Python/ceval.c:2389
#57 0x00000001000b3f30 in PyEval_EvalCodeEx (co=0x102cd5738,
globals=<value temporarily unavailable, due to optimizations>,
locals=<value temporarily unavailable, due to optimizations>,
args=0x102cce848, argcount=1, kws=0x102b48370, kwcount=6, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2968
#58 0x00000001000363ad in function_call (func=0x102cdf6e0,
arg=0x100421450, kw=0x101526720) at Objects/funcobject.c:524
#59 0x0000000100006fe2 in PyObject_Call (func=0x102cdf6e0,
arg=0x100421450, kw=0x101526720) at Objects/abstract.c:2492
#60 0x00000001000ae352 in PyEval_EvalFrameEx (f=0x101526a60,
throwflag=<value temporarily unavailable, due to optimizations>) at
Python/ceval.c:4019
#61 0x00000001000b3f30 in PyEval_EvalCodeEx (co=0x102cb5a08,
globals=<value temporarily unavailable, due to optimizations>,
locals=<value temporarily unavailable, due to optimizations>,
args=0x8, argcount=0, kws=0x102b48188, kwcount=0, defs=0x102ccea08,
defcount=7, closure=0x0) at Python/ceval.c:2968
#62 0x00000001000b1f1d in fast_function [inlined] () at
/Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3802
#63 0x00000001000b1f1d in PyEval_EvalFrameEx (f=0x102b48000,
throwflag=<value temporarily unavailable, due to optimizations>) at
Python/ceval.c:3727
#64 0x00000001000b237a in PyEval_EvalFrameEx (f=0x100357cf0,
throwflag=<value temporarily unavailable, due to optimizations>) at
Python/ceval.c:3792
#65 0x00000001000b3f30 in PyEval_EvalCodeEx (co=0x102cb84e0,
globals=<value temporarily unavailable, due to optimizations>,
locals=<value temporarily unavailable, due to optimizations>,
args=0x10035a950, argcount=0, kws=0x10035a950, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2968
#66 0x00000001000b1f1d in fast_function [inlined] () at
/Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3802
#67 0x00000001000b1f1d in PyEval_EvalFrameEx (f=0x10035a7a0,
throwflag=<value temporarily unavailable, due to optimizations>) at
Python/ceval.c:3727
#68 0x00000001000b3f30 in PyEval_EvalCodeEx (co=0x102cc4738,
globals=<value temporarily unavailable, due to optimizations>,
locals=<value temporarily unavailable, due to optimizations>,
args=0x102cc0c30, argcount=2, kws=0x100359160, kwcount=1, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2968
#69 0x00000001000b1f1d in fast_function [inlined] () at
/Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3802
#70 0x00000001000b1f1d in PyEval_EvalFrameEx (f=0x100358fd0,
throwflag=<value temporarily unavailable, due to optimizations>) at
Python/ceval.c:3727
#71 0x00000001000b3f30 in PyEval_EvalCodeEx (co=0x100426f30,
globals=<value temporarily unavailable, due to optimizations>,
locals=<value temporarily unavailable, due to optimizations>,
args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2968
#72 0x00000001000b4016 in PyEval_EvalCode (co=<value temporarily
unavailable, due to optimizations>, globals=<value temporarily
unavailable, due to optimizations>, locals=<value temporarily
unavailable, due to optimizations>) at Python/ceval.c:522
#73 0x00000001000d8a5e in run_mod [inlined] () at
/Users/mb312/stable_trees/Python-2.6.4/Python/pythonrun.c:1335
#74 0x00000001000d8a5e in PyRun_FileExFlags (fp=0x7fff7092be80,
filename=0x7fff5fbfe17a
"scipybuild/matplotlib/examples/pylab_examples/simple_plot.py",
start=<value temporarily unavailable, due to optimizations>,
globals=0x100312ec0, locals=0x100312ec0, closeit=1,
flags=0x7fff5fbfdfb0) at Python/pythonrun.c:1321
#75 0x00000001000d8d19 in PyRun_SimpleFileExFlags (fp=0x7fff7092be80,
filename=0x7fff5fbfe17a
"scipybuild/matplotlib/examples/pylab_examples/simple_plot.py",
closeit=1, flags=0x7fff5fbfdfb0) at Python/pythonrun.c:931
#76 0x00000001000e835c in Py_Main (argc=2523360, argv=0x7fff5fbfe010)
at Modules/main.c:599
#77 0x0000000100001544 in start ()
Current language: auto; currently c++
Mathew

Matthew Brett <mat...@gm...>
writes:
>> Can you get a backtrace in gdb?
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: 13 at address: 0x0000000000000000
> 0x0000000102d96ffb in py_to_agg_transformation_matrix
> (obj=0x102d794d0, errors=false) at src/agg_py_transforms.cpp:21
> 21	 matrix = (PyArrayObject*) PyArray_FromObject(obj,
> PyArray_DOUBLE, 2, 2);
Can you type "bt" in gdb at this point to see the whole call stack?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hi,
>> Can you get a backtrace in gdb?
>
> (gdb) run scipybuild/matplotlib/examples/pylab_examples/simple_plot.py
...
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: 13 at address: 0x0000000000000000
> 0x0000000102d96ffb in py_to_agg_transformation_matrix
> (obj=0x102d794d0, errors=false) at src/agg_py_transforms.cpp:21
> 21       matrix = (PyArrayObject*) PyArray_FromObject(obj,
> PyArray_DOUBLE, 2, 2);
>
> hum... I'm running from the latest svn numpy...
Same outcome with numpy 1.3 though...
Matthew

Hi,
On Sun, Nov 29, 2009 at 1:30 AM, Jouni K. Seppänen <jk...@ik...> wrote:
> Matthew Brett <mat...@gm...> writes:
>
>> I am rashly building matplotlib from source on Snow Leopard, and
>> getting a segmentation fault as soon as I try and do a plot.
>
> Can you get a backtrace in gdb?
(gdb) run scipybuild/matplotlib/examples/pylab_examples/simple_plot.py
...
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x0000000102d96ffb in py_to_agg_transformation_matrix
(obj=0x102d794d0, errors=false) at src/agg_py_transforms.cpp:21
21	 matrix = (PyArrayObject*) PyArray_FromObject(obj,
PyArray_DOUBLE, 2, 2);
hum... I'm running from the latest svn numpy...
Cheers,
Matthew

Matthew Brett <mat...@gm...> writes:
> I am rashly building matplotlib from source on Snow Leopard, and
> getting a segmentation fault as soon as I try and do a plot.
Can you get a backtrace in gdb? 
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

> I am rashly building matplotlib from source on Snow Leopard, and
> getting a segmentation fault as soon as I try and do a plot.
>
> me $ python -c 'import pylab; pylab.plot(range(10))'
> Segmentation fault
Sorry - here the is top of the build output:
export PKG_CONFIG_PATH="/Users/mb312/usr/local/lib/pkgconfig" &&\
	export MACOSX_DEPLOYMENT_TARGET=10.6 &&\
	export CFLAGS=" -I/Users/mb312/usr/local/include
-I/Users/mb312/usr/local/include/freetype2 -isysroot
/Developer/SDKs/MacOSX10.6.sdk" &&\
	export LDFLAGS=" -L/Users/mb312/usr/local/lib
-syslibroot,/Developer/SDKs/MacOSX10.6.sdk" &&\
	python2.6 setup.py install --prefix=/Users/mb312/usr/local
============================================================================
BUILDING MATPLOTLIB
 matplotlib: 1.0.svn
 python: 2.6.4 (r264:75706, Nov 29 2009, 00:03:57) [GCC
 4.2.1 (Apple Inc. build 5646) (dot 1)]
 platform: darwin
REQUIRED DEPENDENCIES
 numpy: 1.4.0.dev7803
 freetype2: found, but unknown version (no pkg-config)
 * WARNING: Could not find 'freetype2' headers in any
 * of '.', './freetype2'.
OPTIONAL BACKEND DEPENDENCIES
 libpng: found, but unknown version (no pkg-config)
 * Could not find 'libpng' headers in any of '.'
 Tkinter: Tkinter: 73770, Tk: 8.5, Tcl: 8.5
 wxPython: no
 * wxPython not found
 Gtk+: no
 * Building for Gtk+ requires pygtk; you must be able
 * to "import gtk" in your build/install environment
 Mac OS X native: yes
 Qt: no
 Qt4: no
 Cairo: no
OPTIONAL DATE/TIMEZONE DEPENDENCIES
 datetime: present, version unknown
 dateutil: matplotlib will provide
 pytz: 2008c
OPTIONAL USETEX DEPENDENCIES
 dvipng: no
 ghostscript: /bin/sh: gs: command not found
 latex: no
Thanks a lot,
Matthew

Hi,
I am rashly building matplotlib from source on Snow Leopard, and
getting a segmentation fault as soon as I try and do a plot.
me $ python -c 'import pylab; pylab.plot(range(10))'
Segmentation fault
I've built python myself with:
export MACOSX_DEPLOYMENT_TARGET=10.6
./configure --prefix=/Users/mb312/usr/local
Then numpy using the usual procedure (tests look good)
For matplotlib, I've hacked the make.osx file so the top looks like:
---- begin make.osx snippet ----
PYVERSION=2.6
PYTHON=python${PYVERSION}
ZLIBVERSION=1.2.3
PNGVERSION=1.2.40
FREETYPEVERSION=2.3.11
MACOSX_DEPLOYMENT_TARGET=10.6
OSX_SDK_VER=10.6
ARCH_FLAGS=
## You shouldn't need to configure past this point
PKG_CONFIG_PATH="${PREFIX}/lib/pkgconfig"
CFLAGS="${ARCH_FLAGS} -I${PREFIX}/include
-I${PREFIX}/include/freetype2 -isysroot
/Developer/SDKs/MacOSX${OSX_SDK_VER}.sdk"
LDFLAGS="${ARCH_FLAGS} -L${PREFIX}/lib
-syslibroot,/Developer/SDKs/MacOSX${OSX_SDK_VER}.sdk"
--- end make.osx snippet ---
This builds correctly but then causes the segfault above. I've tried
with the original make.osx package versions of freetype and libpng
with the same outcome.
Running simple_script.py:
blair:~ mb312$ python
scipybuild/matplotlib/examples/pylab_examples/simple_plot.py
--verbose-helpful
$HOME=/Users/mb312
CONFIGDIR=/Users/mb312/.matplotlib
matplotlib data path
/Users/mb312/usr/local/lib/python2.6/site-packages/matplotlib/mpl-data
loaded rc file /Users/mb312/usr/local/lib/python2.6/site-packages/matplotlib/mpl-data/matplotlibrc
matplotlib version 1.0.svn
verbose.level helpful
interactive is False
units is False
platform is darwin
Using fontManager instance from /Users/mb312/.matplotlib/fontList.cache
backend MacOSX version unknown
Segmentation fault
gcc version is i686-apple-darwin10-gcc-4.2.1
Did I take a mis-step somewhere in the build process? Any advice very
gratefully received...
Thanks a lot,
Matthew

Andrew Straw wrote:
> I looked a little further, and it depends on the directory that the
> tests are run from -- if I manually log into the build slave, I can
> get the tests to run (in fact, one segfaults) if I try from a
> different working directory. Anyhow, now that I have a handle on it, I
> think I can probably get it working... Give me a couple days.
great.
> As far as I'm concerned, that would be fine.
>
> Is PyMODINIT_FUNC pulled in from Python.h?
Yes - the init func should always be 'tagged' by this macro. On Unix,
any function is exported in a shared library by default, but the
behavior is the opposite on windows, where a function without it will
not be visible from external code.
David

Hi,
just wanted to raise this problem on the devel list, where it probably
belongs. Also, if nobody has time to look at it now and you prefer me to
file a bug, please don't hesitate to tell it.
the original post is there:
http://thread.gmane.org/gmane.comp.python.matplotlib.general/20411
Cheers
Le 21 novembre 2009 17:50, Sébastien Barthélemy <bar...@cr...> a
écrit :
> Le 18 novembre 2009 17:24, Michael Droettboom <md...@st...> a écrit :
>
> This is a bug -- but it has a fairly straightforward fix: to use Sphinx's
>> "include" directive rather than roll our own as we currently do. This has
>> been fixed in SVN r7972. plot-directive now takes an "encoding" option,
>> exactly like the Sphinx include directive. It does not do automatic
>> encoding detection (meaning it ignores the "# coding: latin1" comments),
>> just as the Sphinx include directive does.
>>
>
> Hello Michael,
>
> thank you for your fast reply and action. I just tried with the version
> from trunk (r7978) and I still have an encoding problem on the same test
> case. It seems to happen when the file is ran (to produce the figure) rather
> than when it is included. I had a look at the code, but cannot understand
> what is happenning, I would have expected imp to proprely guess the
> encoding.
>
> Could you tell me if you have the same problem ? Do you have any idea of
> what is going on ?
>
> Thanks !
>
> $ git clone git://github.com/sbarthelemy/SphinxEncoding.git
> $ cd SphinxEncoding/
> $ make html
> sphinx-build -b html -d _build/doctrees . _build/html
> Making output directory...
> Running Sphinx v0.6.2
> loading pickled environment... not found
> building [html]: targets for 1 source files that are out of date
> updating environment: 1 added, 0 changed, 0 removed
> /home/barthelemy/.local/lib/python2.6/site-packages/matplotlib/sphinxext/plot_directive.py:273:
> UserWarning: Exception running plot ./fileutf8.py
> Traceback (most recent call last):
> File
> "/home/barthelemy/.local/lib/python2.6/site-packages/matplotlib/sphinxext/plot_directive.py",
> line 270, in render_figures
> run_code(plot_path, function_name, plot_code)
> File
> "/home/barthelemy/.local/lib/python2.6/site-packages/matplotlib/sphinxext/plot_directive.py",
> line 182, in run_code
> "__plot__", fd, fname, ('py', 'r', imp.PY_SOURCE))
> File "fileutf8.py", line 2, in <module>
> print(u"accent aigus é")
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in
> position 13: ordinal not in range(128)
>

On Wed, Nov 25, 2009 at 10:57 AM, John Hunter <jd...@gm...> wrote:
> On Wed, Nov 25, 2009 at 10:52 AM, Andrew Straw <str...@as...> wrote:
>
>> Also, would you like svn commit access? That may just make things easier
>> -- John, what do you think? I think we can trust David. :)
>
> Absolutely -- send me an svn login and I can add him to the list of
> committers if he wants to, else we can manage his patches.
"svn login" means "sourceforge id"
JDH

On Wed, Nov 25, 2009 at 10:52 AM, Andrew Straw <str...@as...> wrote:
> Also, would you like svn commit access? That may just make things easier
> -- John, what do you think? I think we can trust David. :)
Absolutely -- send me an svn login and I can add him to the list of
committers if he wants to, else we can manage his patches.
JDH

David Cournapeau wrote:
> Andrew Straw wrote:
> 
>> Michael Droettboom wrote:
>> 
>>> I know it's been a while since you announced this, but I'm just
>>> looking into this now. 
>>> 
>> Also, I got some ways in making the buildbot build with numscons, but
>> I stopped at a bug where it looked like the matplotlib.tests.* modules
>> were not getting installed:
>>
>> http://mpl-buildbot.code.astraw.com/builders/Ubuntu%208.04%2C%20Python%202.5%2C%20amd64%2C%20scons/builds/13/steps/test/logs/stdio
>>
>>
>> 
>
> I will look at it. I would like to get some kind of automated testing
> for matplotlib on windows 64 (which is built using the numscons build),
> so I have the incentive :)
> 
I looked a little further, and it depends on the directory that the 
tests are run from -- if I manually log into the build slave, I can get 
the tests to run (in fact, one segfaults) if I try from a different 
working directory. Anyhow, now that I have a handle on it, I think I can 
probably get it working... Give me a couple days.
win64 builds wold be great.
> 
>> I haven't had a chance to debug this further, but I'm open to ideas.
>> Also, this branch is building from a git repository (a mirror of
>> David's which I can't clone normally, for some reason), for what it's
>> worth.
>> 
>
> I don't know why I have those problems either. Do you think it would be
> possible to just apply the patch suite to trunk in svn once we fix the
> test issue ? Since the patches do not touch the existing source tree
> (except for a few bugs on windows I can split up if required), it would
> be more practical to have all this in svn.
> 
As far as I'm concerned, that would be fine.
Is PyMODINIT_FUNC pulled in from Python.h?
Also, would you like svn commit access? That may just make things easier 
-- John, what do you think? I think we can trust David. :)
-Andrew

Andrew Straw wrote:
> Michael Droettboom wrote:
>> I know it's been a while since you announced this, but I'm just
>> looking into this now. 
>
> Also, I got some ways in making the buildbot build with numscons, but
> I stopped at a bug where it looked like the matplotlib.tests.* modules
> were not getting installed:
>
> http://mpl-buildbot.code.astraw.com/builders/Ubuntu%208.04%2C%20Python%202.5%2C%20amd64%2C%20scons/builds/13/steps/test/logs/stdio
>
>
I will look at it. I would like to get some kind of automated testing
for matplotlib on windows 64 (which is built using the numscons build),
so I have the incentive :)
> I haven't had a chance to debug this further, but I'm open to ideas.
> Also, this branch is building from a git repository (a mirror of
> David's which I can't clone normally, for some reason), for what it's
> worth.
I don't know why I have those problems either. Do you think it would be
possible to just apply the patch suite to trunk in svn once we fix the
test issue ? Since the patches do not touch the existing source tree
(except for a few bugs on windows I can split up if required), it would
be more practical to have all this in svn.
cheers,
David