Segfault in _path.so plugin when importing matplotlib in Chaco script

Tony_S_Yu2 · July 8, 2010, 4:13pm

The recent "nasty import behavior" thread motivated me to post an issue I've been having with matplotlib and chaco. (I've posted to the Chaco list previously, without much luck.)

If I import matplotlib and chaco at the same time, I get a segmentation fault in the _path.so plugin. Below is a simple script that segfaults on my computer.

I should note that this is installation dependent; someone on the Chaco list only had the issue with certain versions of Python. Just for reference, I'm on OS X 10.6, Python 2.6.1, and matplotlib/chaco trunk.

-Tony

P.S. In reality, there's no reason to import matplotlib when using Chaco, but I have some helper modules with some tangled imports (i.e. need to be refactored).

···

#---

import matplotlib.pyplot as plt

import enthought.traits.api as traits
import enthought.traits.ui.api as ui
import enthought.chaco.api as chaco
from enthought.enable.component_editor import ComponentEditor

class LinePlot(traits.HasTraits):
    plot = traits.Instance(chaco.Plot)
    traits_view = ui.View(
        ui.Item('plot', editor=ComponentEditor()),
                width=500, height=500, resizable=True)

    def __init__(self):
        plotdata = chaco.ArrayPlotData(x=[1,2,3], y=[1,2,3])
        self.plot = chaco.Plot(plotdata)
        self.plot.plot(('x', 'y'))

viewer = LinePlot()
viewer.configure_traits()

_John_Hunter · July 8, 2010, 4:16pm

First question -- are you compiling both yourself and are they
compiled against the same version of numpy. If not, I suspect we are
seeing a numpy version conflict.

···

On Thu, Jul 8, 2010 at 11:13 AM, Tony S Yu <tsyu80@...149...> wrote:

The recent "nasty import behavior" thread motivated me to post an issue I've been having with matplotlib and chaco. (I've posted to the Chaco list previously, without much luck.)

If I import matplotlib and chaco at the same time, I get a segmentation fault in the _path.so plugin. Below is a simple script that segfaults on my computer.

I should note that this is installation dependent; someone on the Chaco list only had the issue with certain versions of Python. Just for reference, I'm on OS X 10.6, Python 2.6.1, and matplotlib/chaco trunk.

-Tony

P.S. In reality, there's no reason to import matplotlib when using Chaco, but I have some helper modules with some tangled imports (i.e. need to be refactored).

Michael_Droettboom · July 8, 2010, 4:27pm

Can you get a gdb backtrace?

Mike

···

On 07/08/2010 12:13 PM, Tony S Yu wrote:

The recent "nasty import behavior" thread motivated me to post an issue I've been having with matplotlib and chaco. (I've posted to the Chaco list previously, without much luck.)

If I import matplotlib and chaco at the same time, I get a segmentation fault in the _path.so plugin. Below is a simple script that segfaults on my computer.

I should note that this is installation dependent; someone on the Chaco list only had the issue with certain versions of Python. Just for reference, I'm on OS X 10.6, Python 2.6.1, and matplotlib/chaco trunk.

-Tony

P.S. In reality, there's no reason to import matplotlib when using Chaco, but I have some helper modules with some tangled imports (i.e. need to be refactored).

#---

import matplotlib.pyplot as plt

import enthought.traits.api as traits
import enthought.traits.ui.api as ui
import enthought.chaco.api as chaco
from enthought.enable.component_editor import ComponentEditor

class LinePlot(traits.HasTraits):
     plot = traits.Instance(chaco.Plot)
     traits_view = ui.View(
         ui.Item('plot', editor=ComponentEditor()),
                 width=500, height=500, resizable=True)

     def __init__(self):
         plotdata = chaco.ArrayPlotData(x=[1,2,3], y=[1,2,3])
         self.plot = chaco.Plot(plotdata)
         self.plot.plot(('x', 'y'))

viewer = LinePlot()
viewer.configure_traits()

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Tony_S_Yu2 · July 8, 2010, 5:58pm

I am compiling both myself. I did clean compiles of both when Numpy had the whole ABI change (and change back). I've recompiled since then, but without cleaning out compiled code.

I can try clean builds, but that will have to be later in the day. I'll post an update.

Thanks,
-Tony

···

On Jul 8, 2010, at 12:16 PM, John Hunter wrote:

On Thu, Jul 8, 2010 at 11:13 AM, Tony S Yu <tsyu80@...149...> wrote:

The recent "nasty import behavior" thread motivated me to post an issue I've been having with matplotlib and chaco. (I've posted to the Chaco list previously, without much luck.)

If I import matplotlib and chaco at the same time, I get a segmentation fault in the _path.so plugin. Below is a simple script that segfaults on my computer.

I should note that this is installation dependent; someone on the Chaco list only had the issue with certain versions of Python. Just for reference, I'm on OS X 10.6, Python 2.6.1, and matplotlib/chaco trunk.

-Tony

P.S. In reality, there's no reason to import matplotlib when using Chaco, but I have some helper modules with some tangled imports (i.e. need to be refactored).

First question -- are you compiling both yourself and are they
compiled against the same version of numpy. If not, I suspect we are
seeing a numpy version conflict.

Tony_S_Yu2 · July 8, 2010, 6:05pm

This is as far as I can get with gdb:

···

On Jul 8, 2010, at 12:27 PM, Michael Droettboom wrote:

Can you get a gdb backtrace?

Mike

#---------

$ gdb python
GNU gdb 6.3.50-20050815 (Apple version gdb-1461.2) (Fri Mar 5 04:43:10 UTC 2010)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ... done

(gdb) run test_import_chaco_and_plt.py
Starting program: /usr/bin/python test_import_chaco_and_plt.py
Reading symbols for shared libraries .++..... done

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007fff5fc01028 in __dyld__dyld_start ()
(gdb) bt
#0 0x00007fff5fc01028 in __dyld__dyld_start ()
#1 0x0000000100000000 in ?? ()
(gdb)

#---------

I'm not very experienced with gdb, so I'm not sure if I'm doing something wrong.

Thanks,
-Tony

On 07/08/2010 12:13 PM, Tony S Yu wrote:

The recent "nasty import behavior" thread motivated me to post an issue I've been having with matplotlib and chaco. (I've posted to the Chaco list previously, without much luck.)

If I import matplotlib and chaco at the same time, I get a segmentation fault in the _path.so plugin. Below is a simple script that segfaults on my computer.

Tony_S_Yu2 · July 8, 2010, 6:25pm

Ignore my last email. The crash occurs here:

···

On Jul 8, 2010, at 12:27 PM, Michael Droettboom wrote:

Can you get a gdb backtrace?

Mike

#—

Continuing.

Reading symbols for shared libraries . done

Reading symbols for shared libraries + done

2010-07-08 14:15:20.218 Python[60899:d13] *** __NSAutoreleaseNoPool(): Object 0x1048a86d0 of class NSCFNumber autoreleased with no pool in place - just leaking

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: KERN_INVALID_ADDRESS at address: 0x0000003000000040

agg::pod_bvector<agg::point_base, 6u>::~pod_bvector (this=0x7fff5fbf8130) at agg_array.h:521

521 pod_allocator::deallocate(*blk, block_size);

#—

and the first few lines of the traceback are here:

#—

#0 agg::pod_bvector<agg::point_base, 6u>::~pod_bvector (this=0x7fff5fbf8130) at agg_array.h:521

#1 0x0000000101795b65 in ~vertex_sequence [inlined] () at /Users/Tony/python/devel/mpl/agg24/include/agg_vertex_sequence.h:525

#2 0x0000000101795b65 in agg::vcgen_stroke::~vcgen_stroke (this=0x7fff5fbf80c8) at agg_vcgen_stroke.h:32

#3 0x000000011a45ea07 in ~rasterizer_cells_aa [inlined] () at kiva_graphics_context.h:410

#4 0x000000011a45ea07 in ~rasterizer_scanline_aa [inlined] () at /Users/Tony/python/devel/enthought/Enable/enthought/kiva/agg/agg-24/include/agg_rasterizer_cells_aa.h:101

#—

I posted the full traceback on pastebin: http://pastebin.com/ViefksDC

Are there conflicting versions of agg?

-Tony

On 07/08/2010 12:13 PM, Tony S Yu wrote:

The recent “nasty import behavior” thread motivated me to post an issue I’ve been having with matplotlib and chaco. (I’ve posted to the Chaco list previously, without much luck.)

If I import matplotlib and chaco at the same time, I get a segmentation fault in the _path.so plugin. Below is a simple script that segfaults on my computer.

I should note that this is installation dependent; someone on the Chaco list only had the issue with certain versions of Python. Just for reference, I’m on OS X 10.6, Python 2.6.1, and matplotlib/chaco trunk.

-Tony

_John_Hunter · July 8, 2010, 6:38pm

Could be -- we both use 2.4 but Maxim was somewhat infamous for doing
several 2.4 release without changing any version numbers. Can you
diff the two agg_rasterizer_cells_a.h files? The problems could lie
in a different file, but this would be a start. You might recursively
diff the src dirs as well.

···

On Thu, Jul 8, 2010 at 1:25 PM, Tony S Yu <tsyu80@...149...> wrote:

On Jul 8, 2010, at 12:27 PM, Michael Droettboom wrote:

Can you get a gdb backtrace?

Mike

Ignore my last email. The crash occurs here:
#---
Continuing.
Reading symbols for shared libraries . done
Reading symbols for shared libraries + done
2010-07-08 14:15:20.218 Python[60899:d13] *** __NSAutoreleaseNoPool():
Object 0x1048a86d0 of class NSCFNumber autoreleased with no pool in place -
just leaking
Reading symbols for shared libraries + done
Reading symbols for shared libraries + done
Reading symbols for shared libraries ++ done
Reading symbols for shared libraries + done
Reading symbols for shared libraries + done
Reading symbols for shared libraries + done
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: KERN_INVALID_ADDRESS at address: 0x0000003000000040
agg::pod_bvector<agg::point_base<double>, 6u>::~pod_bvector
(this=0x7fff5fbf8130) at agg_array.h:521
521 pod_allocator<T>::deallocate(*blk, block_size);
#---
and the first few lines of the traceback are here:
#---
#0 agg::pod_bvector<agg::point_base<double>, 6u>::~pod_bvector
(this=0x7fff5fbf8130) at agg_array.h:521
#1 0x0000000101795b65 in ~vertex_sequence [inlined] () at
/Users/Tony/python/devel/mpl/agg24/include/agg_vertex_sequence.h:525
#2 0x0000000101795b65 in agg::vcgen_stroke::~vcgen_stroke
(this=0x7fff5fbf80c8) at agg_vcgen_stroke.h:32
#3 0x000000011a45ea07 in ~rasterizer_cells_aa [inlined] () at
kiva_graphics_context.h:410
#4 0x000000011a45ea07 in ~rasterizer_scanline_aa [inlined] () at
/Users/Tony/python/devel/enthought/Enable/enthought/kiva/agg/agg-24/include/agg_rasterizer_cells_aa.h:101
#---
I posted the full traceback on pastebin: http://pastebin.com/ViefksDC
Are there conflicting versions of agg?

Michael_Droettboom · July 8, 2010, 6:51pm

We also have some custom changes in the matplotlib tree -- because upstream agg 2.4 is basically closed.

Mike

···

On 07/08/2010 02:38 PM, John Hunter wrote:

On Thu, Jul 8, 2010 at 1:25 PM, Tony S Yu<tsyu80@...149...> wrote:


On Jul 8, 2010, at 12:27 PM, Michael Droettboom wrote:

Can you get a gdb backtrace?

Mike

Ignore my last email. The crash occurs here:
#---
Continuing.
Reading symbols for shared libraries . done
Reading symbols for shared libraries + done
2010-07-08 14:15:20.218 Python[60899:d13] *** __NSAutoreleaseNoPool():
Object 0x1048a86d0 of class NSCFNumber autoreleased with no pool in place -
just leaking
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: KERN_INVALID_ADDRESS at address: 0x0000003000000040
agg::pod_bvector<agg::point_base<double>, 6u>::~pod_bvector
(this=0x7fff5fbf8130) at agg_array.h:521
521 pod_allocator<T>::deallocate(*blk, block_size);
#---
and the first few lines of the traceback are here:
#---
#0 agg::pod_bvector<agg::point_base<double>, 6u>::~pod_bvector
(this=0x7fff5fbf8130) at agg_array.h:521
#1 0x0000000101795b65 in ~vertex_sequence [inlined] () at
/Users/Tony/python/devel/mpl/agg24/include/agg_vertex_sequence.h:525
#2 0x0000000101795b65 in agg::vcgen_stroke::~vcgen_stroke
(this=0x7fff5fbf80c8) at agg_vcgen_stroke.h:32
#3 0x000000011a45ea07 in ~rasterizer_cells_aa [inlined] () at
kiva_graphics_context.h:410
#4 0x000000011a45ea07 in ~rasterizer_scanline_aa [inlined] () at
/Users/Tony/python/devel/enthought/Enable/enthought/kiva/agg/agg-24/include/agg_rasterizer_cells_aa.h:101
#---
I posted the full traceback on pastebin: http://pastebin.com/ViefksDC
Are there conflicting versions of agg?


Could be -- we both use 2.4 but Maxim was somewhat infamous for doing
several 2.4 release without changing any version numbers. Can you
diff the two agg_rasterizer_cells_a.h files? The problems could lie
in a different file, but this would be a start. You might recursively
diff the src dirs as well.

--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Tony_S_Yu2 · July 8, 2010, 7:14pm

Can you get a gdb backtrace?

Mike

Ignore my last email. The crash occurs here:
#---
Continuing.
Reading symbols for shared libraries . done
Reading symbols for shared libraries + done
2010-07-08 14:15:20.218 Python[60899:d13] *** __NSAutoreleaseNoPool():
Object 0x1048a86d0 of class NSCFNumber autoreleased with no pool in place -
just leaking
Reading symbols for shared libraries + done
Reading symbols for shared libraries + done
Reading symbols for shared libraries ++ done
Reading symbols for shared libraries + done
Reading symbols for shared libraries + done
Reading symbols for shared libraries + done
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: KERN_INVALID_ADDRESS at address: 0x0000003000000040
agg::pod_bvector<agg::point_base<double>, 6u>::~pod_bvector
(this=0x7fff5fbf8130) at agg_array.h:521
521 pod_allocator<T>::deallocate(*blk, block_size);
#---
and the first few lines of the traceback are here:
#---
#0 agg::pod_bvector<agg::point_base<double>, 6u>::~pod_bvector
(this=0x7fff5fbf8130) at agg_array.h:521
#1 0x0000000101795b65 in ~vertex_sequence [inlined] () at
/Users/Tony/python/devel/mpl/agg24/include/agg_vertex_sequence.h:525
#2 0x0000000101795b65 in agg::vcgen_stroke::~vcgen_stroke
(this=0x7fff5fbf80c8) at agg_vcgen_stroke.h:32
#3 0x000000011a45ea07 in ~rasterizer_cells_aa [inlined] () at
kiva_graphics_context.h:410
#4 0x000000011a45ea07 in ~rasterizer_scanline_aa [inlined] () at
/Users/Tony/python/devel/enthought/Enable/enthought/kiva/agg/agg-24/include/agg_rasterizer_cells_aa.h:101
#---
I posted the full traceback on pastebin: http://pastebin.com/ViefksDC
Are there conflicting versions of agg?


Could be -- we both use 2.4 but Maxim was somewhat infamous for doing
several 2.4 release without changing any version numbers. Can you
diff the two agg_rasterizer_cells_a.h files? The problems could lie
in a different file, but this would be a start. You might recursively
diff the src dirs as well.


We also have some custom changes in the matplotlib tree -- because upstream agg 2.4 is basically closed.

Mike

I've attached a diff of the file you suggested, John.There's a pretty significant output when diff-ing recursively. It doesn't sound like there's much to be done about this issue if matplotlib and enthought are using different versions of Agg (assuming this difference is actually the cause of the segfault).

In any case, I'll just refactor my code so that I don't run into this conflict.

Thanks,
-Tony

$ diff -b mpl/agg24/include/agg_rasterizer_cells_aa.h enthought/Enable/enthought/kiva/agg/agg-24/include/agg_rasterizer_cells_aa.h32,33d31
< #include "CXX/Exception.hxx"
< #include <exception>
38a37

40a40

52c52
< cell_block_limit = 4096

···

On Jul 8, 2010, at 2:51 PM, Michael Droettboom wrote:

On 07/08/2010 02:38 PM, John Hunter wrote:

On Thu, Jul 8, 2010 at 1:25 PM, Tony S Yu<tsyu80@...149...> wrote:

On Jul 8, 2010, at 12:27 PM, Michael Droettboom wrote:

---

cell_block_limit = 1024

186,194c186
< if(m_num_blocks >= cell_block_limit) {
< static Py::Exception e(
< Py::OverflowError(
< "Agg rendering complexity exceeded. Consider downsampling or decimating your data."));
<
< /* If this exception is thrown too often, one can
< increase cell_block_limit */
< throw e;
< }
---

if(m_num_blocks >= cell_block_limit) return;

654a647

678,679d670
< i = m_num_cells & cell_block_mask;
< if (i) {
680a672

i = m_num_cells & cell_block_mask;

686d677
< }
713,714d703
< i = m_num_cells & cell_block_mask;
< if (i) {
715a705

i = m_num_cells & cell_block_mask;

723d712
< }