MPL segfault...

Hi all,

I'm getting:

planck[examples]> python pylab_segfault.py
Numpy version: 1.0.3.dev3651
Segmentation fault (core dumped)

with this trivial code

planck[examples]> cat pylab_segfault.py
import sys
import numpy as N
import pylab as P

print "Numpy version:",N.__version__
sys.stdout.flush()

P.imshow(N.ones((4,4),dtype=N.uint8))
P.show()

# EOF

Is anyone else seeing this? My matplotlib build is SVN:

planck[scipy]> svn info matplotlib/
Path: matplotlib
URL: https://svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib
Repository Root: https://svn.sourceforge.net/svnroot/matplotlib
Repository UUID: f61c4167-ca0d-0410-bb4a-bb21726e55ed
Revision: 3141
Node Kind: directory
Schedule: normal
Last Changed Author: efiring
Last Changed Rev: 3141
Last Changed Date: 2007-04-01 18:19:08 -0600 (Sun, 01 Apr 2007)
Properties Last Updated: 2006-07-08 22:39:32 -0600 (Sat, 08 Jul 2006)

And I get the above error with all GUI backends I've tested so far
(Tk, GTK, Qt and WX).

planck[examples]> python pylab_segfault.py -dWXAgg
Numpy version: 1.0.3.dev3651
Segmentation fault (core dumped)
planck[examples]> python pylab_segfault.py -dTkAgg
Numpy version: 1.0.3.dev3651
Segmentation fault (core dumped)
planck[examples]> python pylab_segfault.py -dQtAgg
Numpy version: 1.0.3.dev3651
Segmentation fault (core dumped)
planck[examples]> python pylab_segfault.py -dGTKAgg
Numpy version: 1.0.3.dev3651
Segmentation fault (core dumped)
planck[examples]> python pylab_segfault.py -dGTK
Numpy version: 1.0.3.dev3651
Segmentation fault (core dumped)
planck[examples]> python pylab_segfault.py -dQt
Numpy version: 1.0.3.dev3651
Segmentation fault (core dumped)
planck[examples]> python pylab_segfault.py -dTk
Numpy version: 1.0.3.dev3651
Segmentation fault (core dumped)

The TkAgg and the GTKAgg get as far as making the pylab window, but
then they crash.

I should add that this same example ran fine for me about a week ago;
I can try to track down the exact versions of numpy and matplotlib I
was using at the time, but if someone has a fix for this, it would be
enormously appreciated.

Cheers,

f

let us know....

···

On 4/6/07, Fernando Perez <fperez.net@...149...> wrote:

planck[examples]> python pylab_segfault.py
Numpy version: 1.0.3.dev3651
Segmentation fault (core dumped)

sudo rm -rf build
sudo python setup.py install

Yep, I also see it, with svn 3163. It looks like the problem is only with the
uint8 data type, I cant reproduce it with any other types.

Darren

···

On Friday 06 April 2007 04:37:46 pm Fernando Perez wrote:

import sys
import numpy as N
import pylab as P

print "Numpy version:",N.__version__
sys.stdout.flush()

P.imshow(N.ones((4,4),dtype=N.uint8))
P.show()

Yup. I'm trying to work around the crash in the original code by
recasting to some other type, but no luck so far...

John: my build scripts always do a full clean, so I'm pretty sure that
it's not picking up stray extensions. They remove all traces of the
previous build as well as the currently installed code...

Cheers,

f

···

On 4/6/07, Darren Dale <dd55@...143...> wrote:

On Friday 06 April 2007 04:37:46 pm Fernando Perez wrote:
> import sys
> import numpy as N
> import pylab as P
>
> print "Numpy version:",N.__version__
> sys.stdout.flush()
>
> P.imshow(N.ones((4,4),dtype=N.uint8))
> P.show()

Yep, I also see it, with svn 3163. It looks like the problem is only with the
uint8 data type, I cant reproduce it with any other types.

Fernando Perez wrote:

import sys
import numpy as N
import pylab as P

print "Numpy version:",N.__version__
sys.stdout.flush()

P.imshow(N.ones((4,4),dtype=N.uint8))
P.show()

Yep, I also see it, with svn 3163. It looks like the problem is only with the
uint8 data type, I cant reproduce it with any other types.

uint8 is treated very differently from anything else:

     def set_data(self, A, shape=None):
         """
         Set the image array

         ACCEPTS: numeric/numarray/PIL Image A"""
         # check if data is PIL Image without importing Image
         if hasattr(A,'getpixel'): X = pil_to_array(A)
         else: X = ma.asarray(A) # assume array

         if (typecode(X) != UInt8
             or len(X.shape) != 3
             or X.shape[2] > 4
             or X.shape[2] < 3):
             cm.ScalarMappable.set_array(self, X)
         else:
             self._A = X

         self._imcache =None

and

     def make_image(self, magnification=1.0):
         if self._A is None:
             raise RuntimeError('You must first set the image array or the image attribute')

         if self._imcache is None:
             if typecode(self._A) == UInt8:
                 im = _image.frombyte(self._A, 0)
                 im.is_grayscale = False
             else:

so presumably _image.frombyte is what is choking. It looks like you want colormapping, but that uint8 is serving as a flag incorrectly indicating that you are passing in some special pre-made image type instead.

Eric

···

On 4/6/07, Darren Dale <dd55@...143...> wrote:

On Friday 06 April 2007 04:37:46 pm Fernando Perez wrote:

Yup. I'm trying to work around the crash in the original code by
recasting to some other type, but no luck so far...

John: my build scripts always do a full clean, so I'm pretty sure that
it's not picking up stray extensions. They remove all traces of the
previous build as well as the currently installed code...

Cheers,

f

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Fernando Perez wrote:

import sys
import numpy as N
import pylab as P

print "Numpy version:",N.__version__
sys.stdout.flush()

P.imshow(N.ones((4,4),dtype=N.uint8))
P.show()

Yep, I also see it, with svn 3163. It looks like the problem is only with the
uint8 data type, I cant reproduce it with any other types.

char _image_module_frombyte__doc__[] =
"frombyte(A, isoutput)\n"
"\n"
"Load the image from a byte array.\n"
"By default this function fills the input buffer, which can subsequently\n"
"be resampled using resize. If isoutput=1, fill the output buffer.\n"
"This is used to support raw pixel images w/o resampling."
;
Py::Object
_image_module::frombyte(const Py::Tuple& args) {
   _VERBOSE("_image_module::frombyte");

   args.verify_length(2);

   Py::Object x = args[0];
   int isoutput = Py::Int(args[1]);

   PyArrayObject *A = (PyArrayObject *) PyArray_ContiguousFromObject(x.ptr(), PyArray_UBYTE, 3, 3);

   if (A->dimensions[2]<3 || A->dimensions[2]>4)
       throw Py::ValueError("Array dimension 3 must have size 3 or 4");

It looks to me like the return from PyArray_ContiguousFromObject needs to be checked, and an exception thrown if necessary.

Unless I hear shortly that someone else is already fixing this, or that I am misdiagnosing the problem, I will proceed. It may be that checking for 3-D needs to be done earlier in the mpl python code as well, but it certainly seems like it should be done here.

Eric

···

On 4/6/07, Darren Dale <dd55@...143...> wrote:

On Friday 06 April 2007 04:37:46 pm Fernando Perez wrote:

Hi Eric,

Unless I hear shortly that someone else is already fixing this, or that
I am misdiagnosing the problem, I will proceed. It may be that checking
for 3-D needs to be done earlier in the mpl python code as well, but it
certainly seems like it should be done here.

I was just on the phone with John when your email came, he has no
computer access right now.

He says to go ahead, his only comment is that you might want to CC
Nick Young, who's the only other person likely to have worked on this
particular part of the code recently.

Many thanks!

f

Fernando Perez wrote:

Hi Eric,

Unless I hear shortly that someone else is already fixing this, or that
I am misdiagnosing the problem, I will proceed. It may be that checking
for 3-D needs to be done earlier in the mpl python code as well, but it
certainly seems like it should be done here.

I was just on the phone with John when your email came, he has no
computer access right now.

He says to go ahead, his only comment is that you might want to CC
Nick Young, who's the only other person likely to have worked on this
particular part of the code recently.

OK, but I don't have any record of Nick Young's email address--if someone knows it, please send it to me.

Thanks.

Eric

I found this in my gmail archive:

Nicholas Young <matplotlib-devel@...211...>

Cheers,

f

···

On 4/6/07, Eric Firing <efiring@...229...> wrote:

OK, but I don't have any record of Nick Young's email address--if
someone knows it, please send it to me.

Fernando Perez wrote:

Hi all,

I'm getting:

planck[examples]> python pylab_segfault.py
Numpy version: 1.0.3.dev3651
Segmentation fault (core dumped)

with this trivial code

planck[examples]> cat pylab_segfault.py
import sys
import numpy as N
import pylab as P

print "Numpy version:",N.__version__
sys.stdout.flush()

P.imshow(N.ones((4,4),dtype=N.uint8))
P.show()

# EOF

I have fixed this in two ways: by raising an exception in _image.cpp if the input to frombyte lacks 3 dimensions--this prevents the segfault--and by checking uint8 arrays for 3 dimensions in image.py before sending them to frombyte in the first place.

The problem cropped up recently because of another change I made. cm.ScalarMappable.set_array had been making all float arrays float32, and all int arrays int16. This was causing problems with int32 arrays, of course, and I could not figure out any reason why it was needed, so I eliminated it. (I think I put that conversion in in the first place a long time ago; presumably I had a reason, and I hope I am correct that if it ever was necessary, it no longer is. The backend_driver tests are happy with the present state of affairs.)

Eric

···

Is anyone else seeing this? My matplotlib build is SVN:

planck[scipy]> svn info matplotlib/
Path: matplotlib
URL: https://svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib
Repository Root: https://svn.sourceforge.net/svnroot/matplotlib
Repository UUID: f61c4167-ca0d-0410-bb4a-bb21726e55ed
Revision: 3141
Node Kind: directory
Schedule: normal
Last Changed Author: efiring
Last Changed Rev: 3141
Last Changed Date: 2007-04-01 18:19:08 -0600 (Sun, 01 Apr 2007)
Properties Last Updated: 2006-07-08 22:39:32 -0600 (Sat, 08 Jul 2006)

And I get the above error with all GUI backends I've tested so far
(Tk, GTK, Qt and WX).

planck[examples]> python pylab_segfault.py -dWXAgg
Numpy version: 1.0.3.dev3651
Segmentation fault (core dumped)
planck[examples]> python pylab_segfault.py -dTkAgg
Numpy version: 1.0.3.dev3651
Segmentation fault (core dumped)
planck[examples]> python pylab_segfault.py -dQtAgg
Numpy version: 1.0.3.dev3651
Segmentation fault (core dumped)
planck[examples]> python pylab_segfault.py -dGTKAgg
Numpy version: 1.0.3.dev3651
Segmentation fault (core dumped)
planck[examples]> python pylab_segfault.py -dGTK
Numpy version: 1.0.3.dev3651
Segmentation fault (core dumped)
planck[examples]> python pylab_segfault.py -dQt
Numpy version: 1.0.3.dev3651
Segmentation fault (core dumped)
planck[examples]> python pylab_segfault.py -dTk
Numpy version: 1.0.3.dev3651
Segmentation fault (core dumped)

The TkAgg and the GTKAgg get as far as making the pylab window, but
then they crash.

I should add that this same example ran fine for me about a week ago;
I can try to track down the exact versions of numpy and matplotlib I
was using at the time, but if someone has a fix for this, it would be
enormously appreciated.

Cheers,

f

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Many thanks, Eric. Greatly appreciated.

Not only does the toy code work, but the real codes where I originally
got the segfaults are working fine as well, so what ever you did was
good.

Regards,

f

···

On 4/6/07, Eric Firing <efiring@...229...> wrote:

I have fixed this in two ways: by raising an exception in _image.cpp if
the input to frombyte lacks 3 dimensions--this prevents the
segfault--and by checking uint8 arrays for 3 dimensions in image.py
before sending them to frombyte in the first place.

The problem cropped up recently because of another change I made.
cm.ScalarMappable.set_array had been making all float arrays float32,
and all int arrays int16. This was causing problems with int32 arrays,
  of course, and I could not figure out any reason why it was needed, so
I eliminated it. (I think I put that conversion in in the first place a
long time ago; presumably I had a reason, and I hope I am correct that
if it ever was necessary, it no longer is. The backend_driver tests are
happy with the present state of affairs.)