Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

set_xlim() crashes kernel if interpolation='none' #3091

Closed
bennettbrowniowa opened this issue May 27, 2014 · 9 comments · Fixed by #3102
Closed

set_xlim() crashes kernel if interpolation='none' #3091

bennettbrowniowa opened this issue May 27, 2014 · 9 comments · Fixed by #3102

Comments

@bennettbrowniowa
Copy link

Using matplotlib 1.3.1-3, the following code causes my Python kernel to crash.

img = plt.imread("cat.png")
fig, ax = plt.subplots(1, 3)
ax[0].imshow(img, interpolation='none')
ax[0].set_xlim(135,165) # larger than image
fig.show()

@Tillsten
Copy link
Contributor

Cannot reproduce, backend?

@bennettbrowniowa
Copy link
Author

I was using Canopy from Enthought with the Qt backend. I reproduced it from the Windows run command line.

Bennett Brown
Director of Instruction, Computer Science
Project Lead The Way, Inc.
3939 Priority Way South Drive, Suite 200
Indianapolis, IN 46240
phone: 317.669.0847
fax: 317.663.8296
www.pltw.orghttp://www.pltw.org/
PLTW | Launch
Amazing discoveries start herehttp://www.youtube.com/watch?v=jEiBf33RM3s.
Learn more and register for PLTW Launch today at pltw.org/launchhttp://www.pltw.org/launch.
Confidentiality Notice: The information transmitted is the property of the sender and is intended only for the person or entity to which it is addressed and may contain confidential and or privileged material. Statements and opinions expressed in this e-mail may not represent those of Project Lead The Way, Inc. Any unauthorized review, retransmission, dissemination and other use of, or taking of any action in reliance upon, this information is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message and delete the material from any computer. If you are the intended recipient but do not wish to receive communications through this medium, please so advise the sender immediately.

From: Till Stensitzki [mailto:notifications@github.com]
Sent: Tuesday, May 27, 2014 7:01 PM
To: matplotlib/matplotlib
Cc: Bennett Brown
Subject: Re: [matplotlib] set_xlim() crashes kernel if interpolation='none' (#3091)

Cannot reproduce, backend?


Reply to this email directly or view it on GitHubhttps://github.com//issues/3091#issuecomment-44346335.

@Tillsten
Copy link
Contributor

Could you try to replace your img with just img = np.random.rand(50, 50)? Because i still can't reproduce it, maybe imshow isn't the culprit.

@bennettbrowniowa
Copy link
Author

With the Qt4 backend, I do get the error with the 50x50 random array. I do not get the error if I change the value of the second argument of set_xlim() from 185 to 265.

img = np.random.rand(50, 50)
fig, ax = plt.subplots(1, 1)
ax.imshow(img, interpolation='none')
ax.set_xlim(165,185)
fig.show()

@efiring
Copy link
Member

efiring commented May 28, 2014

I have reproduced this on a Mac with Anaconda, qt4agg backend, and with mpl master on linux, qt4agg, tkagg, and plain agg backends; therefore it is not gui-related. In all cases, the reported error is "Floating point exception".

On Linux, gdb opened the core file with:
Program terminated with signal 8, Arithmetic exception.
#0 0x00007f88db1ab275 in wrap_mode_reflect (size=0, this=0x7fffa49de274)
at extern/agg24/include/agg_image_accessors.h:379
379 m_value(0)

relevant part of the backtrace is:
#0 0x00007f88db1ab275 in wrap_mode_reflect (size=0, this=0x7fffa49de274)
at extern/agg24/include/agg_image_accessors.h:379
#1 image_accessor_wrap (pixf=..., this=0x7fffa49de260)
at extern/agg24/include/agg_image_accessors.h:244
#2 Image::resize (this=0x203a150, args=..., kwargs=...) at src/_image.cpp:439
#3 0x00007f88db1adfe5 in Py::PythonExtension::method_keyword_call_handler (
_self_and_name_tuple=, _args=, _keywords=)
at extern/CXX/Python2/ExtensionOldType.hxx:321

@efiring
Copy link
Member

efiring commented May 28, 2014

Reproduce with a script with the following:

import numpy as np
import matplotlib as mpl
mpl.use('agg')
import matplotlib.pyplot as plt
img = np.random.rand(50, 50)
fig, ax = plt.subplots(1, 1)
ax.imshow(img, interpolation='none')
ax.set_xlim(165,185)
plt.draw()

As noted by @bennettbrowniowa, it doesn't crash for all values; but as a simpler example that does crash, use np.random.rand(5, 5) and ax.set_xlim(10, 12). Change that last to (10, 15) and it doesn't crash.

@Tillsten
Copy link
Contributor

Maybe this helps people with more knowledge:

The crash happens while calling the image.resize() method in _image.cpp.
The python call to it happens in image.py line 326: im.resize(numcols, numrows).
Note that im.get_size() returns (50, 0).

`

@Tillsten
Copy link
Contributor

Oh sorry, i overlooked @efiring first post.

@tacaswell tacaswell added this to the v1.4.0 milestone May 28, 2014
@efiring
Copy link
Member

efiring commented May 28, 2014

@Tillsten, no worries, you added useful information.

@leejjoon or @mdboom, any chance either of you could take a look at this soon? I suspect a sanity check in an Image method would provide the quickest fix; backing it up with a sanity check in _image.cpp could wait.
AxesImage.make_image is checking for invalid numrows, numcols, but _AxesBase._draw_unsampled_image is not, and this is where the crash is being triggered.

efiring added a commit to efiring/matplotlib that referenced this issue Jun 1, 2014
Two methods in the _image extension module now raise an
exception if the number of rows or columns is zero;
previously they could segfault.  A particular
circumstance that can cause this (setting xlim completely
outside the image extent) is handled directly in the
image module without raising an exception.

Closes matplotlib#3091.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants