Segfaults with wxpython 3.0.2.0 backend

I see segfaults when using simple maplotlib/pylab features:

$ ipython --matplotlib
import pylab
import numpy as np
x = np.random.randn(16, 16)
pylab.imshow(x)
exit()
Segmentation fault

My matplotlibrc:

backend: WXAgg

This is on Linux w/ matplotlib 1.5.0, python 2.7.10 and wxPython 3.0.2.0. I got this failures using Enthought Canopy, but could reproduce it w/ anaconda and debian packages (debian being 1.5.0rc2). I could also see it on windows and mac, so I don't think it is a packaging issue.

Sounds related to #3316

Indeed. I can get you a traceback on Linux, but it would be nice to reproduce this without depending on MPL (I suspect this is a wxpython 3 issue more than matplotlib). Would be happy to work w/ someone from the team if that helps

If I remember correctly, it is a combination of a matplotlib/wxpython
issue. There is something about the way we clean things up that is causing
a freeing of uninitialized memory in wxpython. More specifically, by not
starting the event loop in wxpython, but having an instantiated wx
application, I think.

Again, this is all from memory.

On Thu, Dec 3, 2015 at 8:45 AM, David Cournapeau notifications@github.com
wrote:

Indeed. I can get you a traceback on Linux, but it would be nice to
reproduce this without depending on MPL (I suspect this is a wxpython 3
issue more than matplotlib). Would be happy to work w/ someone from the
team if that helps

—
Reply to this email directly or view it on GitHub
#5609 (comment)
.

FWIW: I can't reproduce on Fedora 23 with (all system packages) Python 2.7.10, wxPython 3.0.2 and matplotlib 1.5.0 installed from source. This is true both at the raw Python repl and in IPython 3.2.1. What version of IPython are you on? It installs an inputhook.

https://github.com/ipython/ipython/blob/40c34d3369c3d271149e13ac07f1bd2f5a716635/IPython/lib/inputhookwx.py

Can you get us a gdb backtrace? Even if not isolated from matplotlib, it might be helpful to see where the segfault is occurring.

This is the gdb stacktrace I get:

#0  0x000000000162f1f0 in ?? ()
#1  0x00002aaab9a7853e in _wrap_Window_Destroy (args=<value optimized out>) at src/gtk/_core_wrap.cpp:37543
#2  0x00002aaaaab8cfb2 in ext_do_call (f=0x2aaac02f8050, throwflag=<value optimized out>) at Python/ceval.c:4343
#3  PyEval_EvalFrameEx (f=0x2aaac02f8050, throwflag=<value optimized out>) at Python/ceval.c:2718
#4  0x00002aaaaab8f32a in PyEval_EvalCodeEx (co=0x2aaab32b0e30, globals=<value optimized out>, locals=<value optimized out>, args=0x2aaac02dec68, argcount=1, kws=0x2aaaaae75068, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3265
#5  0x00002aaaaab1db32 in function_call (func=0x2aaabca67140, arg=0x2aaac02dec50, kw=0x2aaab932be88) at Objects/funcobject.c:526
#6  0x00002aaaaaaf6c48 in PyObject_Call (func=0x2aaabca67140, arg=0x2aaac02dec50, kw=0x2aaab932be88) at Objects/abstract.c:2529
#7  0x00002aaaaab0511d in instancemethod_call (func=<value optimized out>, arg=0x2aaac02dec50, kw=0x2aaab932be88) at Objects/classobject.c:2602
#8  0x00002aaaaaaf6c48 in PyObject_Call (func=0x2aaabda026e0, arg=0x2aaac02dec50, kw=0x2aaab932be88) at Objects/abstract.c:2529
#9  0x00002aaaaab88825 in ext_do_call (f=0x2aaac0271da8, throwflag=<value optimized out>) at Python/ceval.c:4346
#10 PyEval_EvalFrameEx (f=0x2aaac0271da8, throwflag=<value optimized out>) at Python/ceval.c:2718
#11 0x00002aaaaab8f32a in PyEval_EvalCodeEx (co=0x2aaab324b830, globals=<value optimized out>, locals=<value optimized out>, args=0x2aaac0289ec8, argcount=1, kws=0x2aaac0289ed0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3265
#12 0x00002aaaaab8d177 in call_function (f=0x2aaac0289d38, throwflag=<value optimized out>) at Python/ceval.c:4129
#13 PyEval_EvalFrameEx (f=0x2aaac0289d38, throwflag=<value optimized out>) at Python/ceval.c:2679
#14 0x00002aaaaab8f32a in PyEval_EvalCodeEx (co=0x2aaab32513b0, globals=<value optimized out>, locals=<value optimized out>, args=0x2aaac02f61e8, argcount=1, kws=0x2aaac02f61f0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3265
#15 0x00002aaaaab8d177 in call_function (f=0x2aaac02f6050, throwflag=<value optimized out>) at Python/ceval.c:4129
#16 PyEval_EvalFrameEx (f=0x2aaac02f6050, throwflag=<value optimized out>) at Python/ceval.c:2679
#17 0x00002aaaaab8f32a in PyEval_EvalCodeEx (co=0x2aaab6fcae30, globals=<value optimized out>, locals=<value optimized out>, args=0x2aaab6ecf8e8, argcount=1, kws=0x2aaaaae75068, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3265
#18 0x00002aaaaab1db32 in function_call (func=0x2aaab72ba5f0, arg=0x2aaab6ecf8d0, kw=0x2aaab72b95c8) at Objects/funcobject.c:526
#19 0x00002aaaaaaf6c48 in PyObject_Call (func=0x2aaab72ba5f0, arg=0x2aaab6ecf8d0, kw=0x2aaab72b95c8) at Objects/abstract.c:2529
#20 0x00002aaaaab88825 in ext_do_call (f=0x2aaac02b4810, throwflag=<value optimized out>) at Python/ceval.c:4346
#21 PyEval_EvalFrameEx (f=0x2aaac02b4810, throwflag=<value optimized out>) at Python/ceval.c:2718
#22 0x00002aaaaab8f32a in PyEval_EvalCodeEx (co=0x2aaab6fdebb0, globals=<value optimized out>, locals=<value optimized out>, args=0x2aaaaae75068, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3265
#23 0x00002aaaaab1db32 in function_call (func=0x2aaab6f8ea28, arg=0x2aaaaae75050, kw=0x0) at Objects/funcobject.c:526
#24 0x00002aaaaaaf6c48 in PyObject_Call (func=0x2aaab6f8ea28, arg=0x2aaaaae75050, kw=0x0) at Objects/abstract.c:2529
#25 0x00002aaaaab86e26 in PyEval_CallObjectWithKeywords (func=0x2aaab6f8ea28, arg=0x2aaaaae75050, kw=0x0) at Python/ceval.c:3902
#26 0x00002aaaaaba9d8e in call_sys_exitfunc () at Python/pythonrun.c:1751
#27 Py_Finalize () at Python/pythonrun.c:424
#28 0x00002aaaaabbb14f in Py_Main (argc=1, argv=0x7fffffffe5b8) at Modules/main.c:755
#29 0x00000000004012c5 in main (argc=2, argv=0x7fffffffe5b8) at ./Modules/python.c:448

With the following script (ran from python, not ipython):

import numpy as np
import pylab

pylab.imshow(np.random.randn(12, 12))

Any chance you could get a Python backtrace from gdb as well? I usually set up gdb like this, then I can do py-bt to get a Python backtrace as well.

(I found a few typos in your gdbinit, and the link is now broken for libpython.py)

This is what it should look like I think:

python
import gdb
import sys
sys.path.insert(0, os.path.expanduser("~/.config/gdb")

def setup_python(event):
    import libpython
gdb.events.new_objfile.connect(setup_python)
end

I am afraid I can't get py-bt to work, though. I get this error:

$ py-bt
Python Exception <class 'gdb.error'> There is no member named "ob_sval"

I am running debian unstable, which OS are you running gdb w/ py-bt support on ? I can try to get that working on a VM ?

Sorry about that. I've updated the blog post. Not sure why you're getting that error message. Never seen it before.

Fedora 23 has built-in gdb Python debugging support (if you install python-debuginfo and use the system packages) -- in that event it doesn't require my "hack" to make it work for any Python. But that's the same OS I'm unable to reproduce the bug on, so the likelihood of it breaking so you can debug it there is slim.

In any event, the crash is happening in the Window destructor (Window.Destroy), but it's not clear which window. (You probably know that Window in wx.Window is the base class of most widgets, not an app window). You could try to see which call to Destroy in backend_wx.py is crashing through tracing or print statements.

In terms of trying to have a minimal example to pass this to the wx folks, my money is on the wx.Frame (main application window). matplotlib does override the destructor here: https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/backends/backend_wx.py#L1326
Maybe try to make a wx app with a wx.Frame that does something like that and see if you can reproduce? Or, heck, try commenting out the Destroy method at L1326 and see if that resolves the issue.

See PR #5639

closed by #5639 ping if you can still reproduce to have it reopened

@DietmarSchwertberger

@DietmarSchwertberger There have been various fixes to the wx backend since this was opened so it's likely that its fixed. I dont use this on a regular basis so I havn't tested it

I still have a segfault at exit on py2.7 mpl2.1.2 wxpython 3.0.2.0 arch linux.

Seems to work for me on Python 2.7.13, IPython 5.5.0, wxPython 3.0.2.0 (wx-3.0-gtk2), mpl 2.1.2, ArchLinux 2017.08
No crash with the plot window open or closed when entering exit().

Without the check for self.IsBeingDeleted from PR #5639 I can see the core dump when using exit() while the window is open.

@anntzer

@anntzer: do you have a pure Python+wx+Matplotlib script that causes the crash? I.e. without Ipython or similar? Is it with stock Python/mpl/wxpython installations or with a distribution like Anaconda?

It's Arch Linux's distro python2+wxpython+matplotlib, just

MPLBACKEND=wxagg python2 -c 'from pylab import *; plot(); show()'

@anntzer

@anntzer : still can't reproduce it...

For what it's worth, I've had various issues when using wxPython with pylab, though not this particular problem. It has been suggested to me to import directly from matplotlib and numpy, etc., and not use pylab at all. That has resolved all my problems.

$ MPLBACKEND=wxagg python2 -c 'from matplotlib import pyplot as plt; plt.plot(); plt.show()'

also segfaults.

However, I realized that I also have a warning (when importing wx) that's likely relevant :-)

In [1]: import wx
/usr/lib/python2.7/site-packages/wx-3.0-gtk3/wx/_core.py:16629: UserWarning: wxPython/wxWidgets release number mismatch
  warnings.warn("wxPython/wxWidgets release number mismatch")

fwiw:

In [3]: wx._core.RELEASE_VERSION
Out[3]: 2

In [4]: wx._core_.RELEASE_VERSION
Out[4]: 3

Perhaps a distro packaging issue?

I see the warning as well, but not the segfault.

Closing as only affecting wx3 (wx4 does not appear to suffer from the issue), which is not supported by mpl3.

Still left a target of 2.2.3, in case anyone wants to visit this...

Navigation Menu

Repository navigation

Segfaults with wxpython 3.0.2.0 backend #5609

10 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Segfaults with wxpython 3.0.2.0 backend #5609

Description

Activity

jenshnielsen commented on Dec 3, 2015

cournape commented on Dec 3, 2015

WeatherGod commented on Dec 3, 2015

mdboom commented on Dec 3, 2015

cournape commented on Dec 3, 2015

mdboom commented on Dec 3, 2015

cournape commented on Dec 3, 2015

cournape commented on Dec 3, 2015

cournape commented on Dec 3, 2015

mdboom commented on Dec 3, 2015

RobinD42 commented on Dec 8, 2015

jenshnielsen commented on Dec 9, 2015

10 remaining items

jenshnielsen commented on Feb 8, 2018

anntzer commented on Feb 8, 2018

DietmarSchwertberger commented on Feb 8, 2018

DietmarSchwertberger commented on Feb 17, 2018

anntzer commented on Feb 17, 2018

DietmarSchwertberger commented on Feb 17, 2018

zong commented on Feb 18, 2018

anntzer commented on Feb 18, 2018

DietmarSchwertberger commented on Feb 18, 2018

anntzer commented on Apr 24, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions