I still get an even more random segfault when using the ipython -pylab option. Here is about the closest thing I can do to reproduce (most of the time).
plot(rand(100))
f = get_current_fig_manager()
f.canvas.get_width_height()
s = f.canvas.tostring_rgb()
f.canvas.<tab>Segmentation fault
Here is more verbosity if it helps.
.....
In [4]:f.canvas.get_width_height
------>f.canvas.get_width_height()
Out[4]:(640, 480)
In [5]:f.canvas.
Display all 294 possibilities? (y or n) <typed "n">
In [5]:f.canvas.to
f.canvas.tostring_argb f.canvas.tostring_rgb
In [5]:s = f.canvas.tostring_rgb()
In [6]:f.canvas.Segmentation fault
Thanks,
Charlie
Charles Moad wrote:
I still get an even more random segfault when using the ipython -pylab option. Here is about the closest thing I can do to reproduce (most of the time).
plot(rand(100))
f = get_current_fig_manager()
f.canvas.get_width_height()
s = f.canvas.tostring_rgb()
f.canvas.<tab>Segmentation fault
Here is more verbosity if it helps.
What backend are you using? Can you try with different ones (ipython -pylab adapts automatically, just change your default backend in your ~/.matplotlib/matplotlibrc file). What version of matplotlib are you using?
Here's what I get, using matplotlib 0.83.2 (official release):
- TkAgg, QtAgg, WXAgg: no problem, can't reproduce your crash, works normally.
- GTKAgg: instant crash on my box (even before getting to where it crashes for you):
In [1]: plot(rand(100))
···
---------------------------------------------------------------------------
exceptions.SystemError Traceback (most recent call last)
SystemError: Objects/moduleobject.c:48: bad argument to internal function
Segmentation fault
I won't worry about this one, as it may be that I screwed something up in the build, and I don't use GTK ever anyway.
But knowing what backends trigger your crash will help narrow things down.
Cheers,
f
I can't seem to crash TkAgg, but WXAgg and GTKAgg still do. This seems to not be related to the repr issue from before. This is all mpl-cvs btw.
- Charlie
Fernando Perez wrote:
···
Charles Moad wrote:
I still get an even more random segfault when using the ipython -pylab option. Here is about the closest thing I can do to reproduce (most of the time).
plot(rand(100))
f = get_current_fig_manager()
f.canvas.get_width_height()
s = f.canvas.tostring_rgb()
f.canvas.<tab>Segmentation fault
Here is more verbosity if it helps.
What backend are you using? Can you try with different ones (ipython -pylab adapts automatically, just change your default backend in your ~/.matplotlib/matplotlibrc file). What version of matplotlib are you using?
Here's what I get, using matplotlib 0.83.2 (official release):
- TkAgg, QtAgg, WXAgg: no problem, can't reproduce your crash, works normally.
- GTKAgg: instant crash on my box (even before getting to where it crashes for you):
In [1]: plot(rand(100))
---------------------------------------------------------------------------
exceptions.SystemError Traceback (most recent call last)
SystemError: Objects/moduleobject.c:48: bad argument to internal function
Segmentation fault
I won't worry about this one, as it may be that I screwed something up in the build, and I don't use GTK ever anyway.
But knowing what backends trigger your crash will help narrow things down.
Cheers,
f
Charles Moad wrote:
I can't seem to crash TkAgg, but WXAgg and GTKAgg still do. This seems to not be related to the repr issue from before. This is all mpl-cvs btw.
OK, I'm afraid this one may require John's help to debug. I don't know the mpl internals nearly well enough to even begin to guess where this could be coming from.
The fact that it's a segfault and not an uncaught exception means the bug is triggered inside C code. <TAB> triggers dir() and getattr() calls, which have to traverse the object's internal dictionary. If the object is implemented in C/C++, that traversal can do arbitrary things, including any number of segfault-inducing manipulations.
One last thing: do you have Qt installed? If so, can you test with QtAgg as your backend? That might help John narrow which parts of the code may or may not be involved in this.
Sorry to be so vague...
Cheers,
f