wx crashes on exit if figure not shown and not explicitly closed

[ibell]

On windows, with the wxagg backend, if the figure is not explicitly closed, python crashes. This crashes:

python -c "import matplotlib.pyplot as plt; plt.plot([0,1],[1,4])"

versions:

C:\Users\Belli>python
Python 2.7.6 |Continuum Analytics, Inc.| (default, May 27 2014, 15:00:33) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
Anaconda is brought to you by Continuum Analytics.
Please check out: http://continuum.io and https://binstar.org
>>> import matplotlib
>>> matplotlib.__version__
'1.3.1'
>>> import wx
>>> wx.version()
'3.0.0.0 msw (classic)'

[mdboom]

Can you provide the full output from the crash?

[WeatherGod]

Does anybody remember if 1.3.1 has the updated wx Backend or not?
On Jul 27, 2014 9:33 AM, "Ian Bell" notifications@github.com wrote:

On windows, with the wxagg backend, if the figure is not explicitly
closed, python crashes. This crashes:

python -c "import matplotlib.pyplot as plt; plt.plot([0,1],[1,4])"

versions:

C:\Users\Belli>python
Python 2.7.6 |Continuum Analytics, Inc.| (default, May 27 2014, 15:00:33) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
Anaconda is brought to you by Continuum Analytics.
Please check out: http://continuum.io and https://binstar.org

import matplotlib
matplotlib.version
'1.3.1'
import wx
wx.version()
'3.0.0.0 msw (classic)'

—
Reply to this email directly or view it on GitHub
#3316.

[ibell]

All I get is a "python has stopped working" popup, no other output.

On Sun, Jul 27, 2014 at 7:31 PM, Benjamin Root notifications@github.com
wrote:

Does anybody remember if 1.3.1 has the updated wx Backend or not?
On Jul 27, 2014 9:33 AM, "Ian Bell" notifications@github.com wrote:

On windows, with the wxagg backend, if the figure is not explicitly
closed, python crashes. This crashes:

python -c "import matplotlib.pyplot as plt; plt.plot([0,1],[1,4])"

versions:

C:\Users\Belli>python
Python 2.7.6 |Continuum Analytics, Inc.| (default, May 27 2014,
15:00:33) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
Anaconda is brought to you by Continuum Analytics.
Please check out: http://continuum.io and https://binstar.org

import matplotlib
matplotlib.version
'1.3.1'
import wx
wx.version()
'3.0.0.0 msw (classic)'

—
Reply to this email directly or view it on GitHub
#3316.

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

[tacaswell]

@Tillsten can you reproduce this?

[tacaswell]

@ibell Could you re-try this with one of the RCs for 1.4.0?

[ericdill]

Running the OP's command does not produce an error on my machine (win 7 x64).

However, at the advice of @tacaswell , running python -c "import matplotlib; matplotlib.use('wxagg'); import matplotlib.pyplot as plt; plt.plot([0,1],[1,4])" gives the python.exe has stopped working window:
.

If I click Debug the program, VS2008 pops up and shows that python terminated due to an Unhandled exception at 0x08b1fb72 in python.exe: 0xC0000005: Access violation reading location 0xffffffffffffffff.

Digging a little deeper results in a list of disassembly code with an arrow pointing to this line: 0000000008B1FB72 call qword ptr [rdx+0A0h]

As this was not terribly helpful (at least for me), running the same code in debug mode of PyCharm Community results in this error: Exception TypeError: "'NoneType' object is not callable" in <bound method Pen.<lambda> of <wx._gdi.Pen; proxy of <Swig Object of type 'wxPen *' at 0x77963a0> >> ignored (The code that produces this is below)

import matplotlib
matplotlib.use('wxagg')
import matplotlib.pyplot as plt
plt.plot([0,1],[1,4])

Hope this helps, mpl devs!

[ibell]

binaries? Building on windows isn't exactly a lot of fun...

On Sun, Aug 17, 2014 at 11:48 PM, Thomas A Caswell <notifications@github.com

wrote:

@ibell https://github.com/ibell Could you re-try this with one of the
RCs for 1.4.0?

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

[tacaswell]

@ibell https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.4.0rc2/

[tacaswell]

And the code runs fine on linux.

[ibell]

Nope, same problem (same versions) when I try to run

python -c "import matplotlib; matplotlib.use('wxagg'); import
matplotlib.pyplot as plt; plt.plot([0,1],[1,4])"

On Mon, Aug 18, 2014 at 12:35 AM, Thomas A Caswell <notifications@github.com

wrote:

And the code runs fine on linux.

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

[tacaswell]

The matplotlib.use('wxagg') is just to make sure that wx backend is used. We had similar smelling issues with the qt backend a while ago which was related to the order in which objects were torn down.

[ibell]

Yeah I reset my default backend to TkAgg due to the crashing with WXAgg :(

On Mon, Aug 18, 2014 at 12:44 AM, Thomas A Caswell <notifications@github.com

wrote:

The matplotlib.use('wxagg') is just to make sure that wx backend is used.
We had similar smelling issues with the qt backend a while ago which was
related to the order in which objects were torn down.

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

[tacaswell]

If you are going to run the code with out showing the figure, I would use the agg backend. If you throw a plt.show() in it will show the figure and block until you close it (which explicitly closes the figure). Now that I think about it a bit more, I think the problem might be that the figure is never shown and hence never finished setting up.

Does python -c "import matplotlib; matplotlib.use('wxagg'); import matplotlib.pyplot as plt; plt.plot([0,1],[1,4]); plt.close('all')" prevent the error?

Does python -c "import matplotlib; matplotlib.use('wxagg'); import matplotlib.pyplot as plt; plt.plot([0,1],[1,4]); plt.show()" prevent the error?

[ibell]

Yes, the plt.close('all') does "fix" it. As does the plt.show()

In general it's nicer to just be able to always use WXAgg since I do a
hybrid of on-screen plotting and saving to file in my workflow and it is
extremely annoying to be getting crashes of matplotlib.

On Mon, Aug 18, 2014 at 1:04 AM, Thomas A Caswell notifications@github.com
wrote:

If you are going to run the code with out showing the figure, I would use
the agg backend. If you throw a plt.show() in it will show the figure and
block until you close it (which explicitly closes the figure). Now that I
think about it a bit more, I think the problem might be that the figure is
never shown and hence never finished setting up.

Does python -c "import matplotlib; matplotlib.use('wxagg'); import
matplotlib.pyplot as plt; plt.plot([0,1],[1,4]); plt.close('all')"
prevent the error?

Does python -c "import matplotlib; matplotlib.use('wxagg'); import
matplotlib.pyplot as plt; plt.plot([0,1],[1,4]); plt.show()" prevent the
error?

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

[efiring]

If this is a problem only upon shutdown, then perhaps an "atexit" function could be registered to clean up; I don't know whether it would be called early enough to prevent the crash. It could be registered when pyplot is imported, and simply do "plt.close('all')".

[efiring]

To clarify: this would be part of pyplot, so user code would not need to bother with it.
Aha! We already have this; it is in _pylab_helpers, and calls Gcf.destroy_all. Evidently that is too little and/or too late. It is equivalent to plt.close('all'), so it must be coming too late.

[cgohlke]

I can reproduce this with wx 3.0.0.0 but not with wx 2.8.12.1.

Faulthandler gives the following output (using matplotlib 1.4.0rc4):

Fatal Python error: Segmentation fault

Current thread 0x000025ec:
  File "X:\Python27\lib\site-packages\wx-3.0-msw\wx\_core.py", line 9185 in Destroy
  File "X:\Python27\lib\site-packages\matplotlib\backends\backend_wx.py", line 1394 in Destroy
  File "X:\Python27\lib\site-packages\matplotlib\backends\backend_wx.py", line 1433 in destroy
  File "X:\Python27\lib\site-packages\matplotlib\_pylab_helpers.py", line 89 in destroy_all
  File "X:\Python27\lib\atexit.py", line 24 in _run_exitfuncs

The crash is in the wx._core_.pyd extension module (I don't have the debug symbols for it):

7265626d()  
_core_.pyd!06d526c5()   
[Frames below may be incorrect and/or missing, no symbols loaded for _core_.pyd]    
python27.dll!PyCFunction_Call(_object * func=0x026145f8, _object * arg=0x0651dd10, _object * kw=0x06409db0)  Line 101 + 0x7 bytes   C
python27.dll!ext_do_call(_object * func=0x026145f8, _object * * * pp_stack=0x00000000, int flags=3, int na=0, int nk=0)  Line 4345  C
python27.dll!PyEval_EvalFrameEx(_frame * f=0x06531190, int throwflag=0)  Line 2720  C
python27.dll!PyEval_EvalCodeEx(PyCodeObject * co=0x05e8c890, _object * globals=0x06531190, _object * locals=0x00000000, _object * * args=0x064efe9c, int argcount=1, _object * * kws=0x01db103c, int kwcount=0, _object * * defs=0x00000000, int defcount=0, _object * closure=0x00000000)  Line 3265 + 0xc bytes   C
python27.dll!function_call(_object * func=0x05f76a30, _object * arg=0x064efe90, _object * kw=0x064de9c0)  Line 531 + 0x2a bytes C
python27.dll!PyObject_Call(_object * func=0x05f76a30, _object * arg=0x064efe90, _object * kw=0x064de9c0)  Line 2529 + 0xd bytes C
python27.dll!instancemethod_call(_object * func=0x05f73170, _object * arg=0x064efe90, _object * kw=0x064de9c0)  Line 2602 + 0x10 bytes  C
python27.dll!PyObject_Call(_object * func=0x05f73170, _object * arg=0x064efe90, _object * kw=0x064de9c0)  Line 2529 + 0xd bytes C
python27.dll!ext_do_call(_object * func=0x05f73170, _object * * * pp_stack=0x00000000, int flags=3, int na=1, int nk=0)  Line 4346 + 0x8 bytes  C
python27.dll!PyEval_EvalFrameEx(_frame * f=0x0652b480, int throwflag=0)  Line 2720  C
python27.dll!PyEval_EvalCodeEx(PyCodeObject * co=0x05d8eda0, _object * globals=0x0652b480, _object * locals=0x00000000, _object * * args=0x0652f2d8, int argcount=1, _object * * kws=0x0652f2dc, int kwcount=0, _object * * defs=0x00000000, int defcount=0, _object * closure=0x00000000)  Line 3265 + 0xc bytes   C
python27.dll!fast_function(_object * func=0x00000000, _object * * * pp_stack=0x0027fba4, int n=0, int na=1, int nk=0)  Line 4132 + 0x34 bytes   C
python27.dll!call_function(_object * * * pp_stack=0x0027fba4, int oparg=0)  Line 4054 + 0x12 bytes  C
python27.dll!PyEval_EvalFrameEx(_frame * f=0x0652f198, int throwflag=0)  Line 2682  C
python27.dll!PyEval_EvalCodeEx(PyCodeObject * co=0x05d8ef50, _object * globals=0x0652f198, _object * locals=0x00000000, _object * * args=0x06526f30, int argcount=1, _object * * kws=0x06526f34, int kwcount=0, _object * * defs=0x00000000, int defcount=0, _object * closure=0x00000000)  Line 3265 + 0xc bytes   C
python27.dll!fast_function(_object * func=0x00000000, _object * * * pp_stack=0x0027fcb0, int n=0, int na=1, int nk=0)  Line 4132 + 0x34 bytes   C
python27.dll!call_function(_object * * * pp_stack=0x0027fcb0, int oparg=0)  Line 4054 + 0x12 bytes  C
python27.dll!PyEval_EvalFrameEx(_frame * f=0x06526df0, int throwflag=0)  Line 2682  C
python27.dll!PyEval_EvalCodeEx(PyCodeObject * co=0x053698d8, _object * globals=0x06526df0, _object * locals=0x00000000, _object * * args=0x01db103c, int argcount=0, _object * * kws=0x01db103c, int kwcount=0, _object * * defs=0x00000000, int defcount=0, _object * closure=0x00000000)  Line 3265 + 0xc bytes   C
python27.dll!function_call(_object * func=0x053c3cf0, _object * arg=0x01db1030, _object * kw=0x053be810)  Line 531 + 0x2a bytes C
python27.dll!PyObject_Call(_object * func=0x053c3cf0, _object * arg=0x01db1030, _object * kw=0x053be810)  Line 2529 + 0xd bytes C
python27.dll!ext_do_call(_object * func=0x053c3cf0, _object * * * pp_stack=0x00000000, int flags=3, int na=0, int nk=0)  Line 4346 + 0x8 bytes  C
python27.dll!PyEval_EvalFrameEx(_frame * f=0x06530030, int throwflag=0)  Line 2720  C
python27.dll!PyEval_EvalCodeEx(PyCodeObject * co=0x052e17b8, _object * globals=0x06530030, _object * locals=0x00000000, _object * * args=0x01db103c, int argcount=0, _object * * kws=0x00000000, int kwcount=0, _object * * defs=0x00000000, int defcount=0, _object * closure=0x00000000)  Line 3265 + 0xc bytes   C
python27.dll!function_call(_object * func=0x053c3b30, _object * arg=0x01db1030, _object * kw=0x00000000)  Line 531 + 0x2a bytes C
python27.dll!PyObject_Call(_object * func=0x053c3b30, _object * arg=0x01db1030, _object * kw=0x00000000)  Line 2529 + 0xd bytes C
python27.dll!PyEval_CallObjectWithKeywords(_object * func=0x053c3b30, _object * arg=0x00000000, _object * kw=0x00000000)  Line 3902 + 0xc bytes C
python27.dll!call_sys_exitfunc()  Line 1757 + 0xa bytes C
python27.dll!Py_Finalize()  Line 430    C
python27.dll!Py_Main(int argc=2, char * * argv=0x007f8a08)  Line 665 + 0x5 bytes    C
python.exe!__tmainCRTStartup()  Line 586 + 0x17 bytes   C
kernel32.dll!@BaseThreadInitThunk@12()  + 0xe bytes 
ntdll.dll!__RtlUserThreadStart()  + 0x24 bytes  
ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes    

[heroxbd]

Reproduced the bug with the following setup.

OS: GNU/Linux amd64
python: 2.7.9
matplotlib: 1.4.3
wxPython: 3.0.2.0

$ python -c "import matplotlib; matplotlib.use('wxagg'); import matplotlib.pyplot as plt; plt.plot([0,1],[1,4]); plt.close('all')"
$ python -c "import matplotlib; matplotlib.use('wxagg'); import matplotlib.pyplot as plt; plt.plot([0,1],[1,4]); plt.show()"
$ python -c "import matplotlib; matplotlib.use('wxagg'); import matplotlib.pyplot as plt; plt.plot([0,1],[1,4]);"
Segmentation fault

[WeatherGod]

WxAgg just underwent a major overhaul in the master branch. Could someone
check using that?

On Tue, Jun 30, 2015 at 12:42 AM, heroxbd notifications@github.com wrote:

Reproduced the bug with the following setup.

OS: GNU/Linux amd64
python: 2.7.9
matplotlib: 1.4.3
wxPython: 3.0.2.0

$ python -c "import matplotlib; matplotlib.use('wxagg'); import matplotlib.pyplot as plt; plt.plot([0,1],[1,4]); plt.close('all')"
$ python -c "import matplotlib; matplotlib.use('wxagg'); import matplotlib.pyplot as plt; plt.plot([0,1],[1,4]); plt.show()"
$ python -c "import matplotlib; matplotlib.use('wxagg'); import matplotlib.pyplot as plt; plt.plot([0,1],[1,4]);"
Segmentation fault

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

[jenshnielsen]

I can reproduce the seg fault on current master on OSX wx and wxpython 3.0.2 from brew

[jenshnielsen]

For what is worth it doesn't seqfault using python 3 and wx phoenix but raises a runtime error

Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/usr/local/lib/python3.4/site-packages/matplotlib-1.5.dev1-py3.4-macosx-10.10-x86_64.egg/matplotlib/_pylab_helpers.py", line 92, in destroy_all
    manager.destroy()
  File "/usr/local/lib/python3.4/site-packages/matplotlib-1.5.dev1-py3.4-macosx-10.10-x86_64.egg/matplotlib/backends/backend_wx.py", line 1376, in destroy
    self.frame.Destroy()
  File "/usr/local/lib/python3.4/site-packages/matplotlib-1.5.dev1-py3.4-macosx-10.10-x86_64.egg/matplotlib/backends/backend_wx.py", line 1334, in Destroy
    wx.Frame.Destroy(self, *args, **kwargs)
RuntimeError: wrapped C/C++ object of type FigureFrameWxAgg has been deleted

[jenshnielsen]

Looks to me like it is trying to destroy a frame which was never created because show was never called.

[heroxbd]

@WeatherGod
Tested with master branch with
OS: GNU/Linux amd64
python: 2.7.9
wxPython: 3.0.2.0

$ python -c "import matplotlib; print matplotlib.__version__"
1.5.dev1

$ python -c "import matplotlib; matplotlib.use('wxagg'); import matplotlib.pyplot as plt; plt.plot([0,1],[1,4]);"
Segmentation fault

[tacaswell]

Interestingly this lead me to find: #4572

For reference (even if it looks a bit useless to me):

22:15 $ gdb -return-child-result -batch -ex r -ex bt --args python2  -c "import matplotlib; matplotlib.use('wxagg'); import matplotlib.pyplot as plt; plt.plot([0,1],[1,4]);"  
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
22:15:35: Warning: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1008,wx containers,compatible with 2.8),
and wxPython used 3.0 (wchar_t,compiler with C++ ABI 1002,wx containers,compatible with 2.8).

Program received signal SIGSEGV, Segmentation fault.
0x0000555556b9eb80 in ?? ()
#0  0x0000555556b9eb80 in ?? ()
#1  0x00007fffeb9c6075 in ?? () from /usr/lib/python2.7/site-packages/wx-3.0-gtk2/wx/_core_.so
#2  0x00007ffff7af4d6d in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#3  0x00007ffff7af5abc in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0
#4  0x00007ffff7a824ad in function_call () from /usr/lib/libpython2.7.so.1.0
#5  0x00007ffff7a5d9e3 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
#6  0x00007ffff7a6c7c7 in instancemethod_call () from /usr/lib/libpython2.7.so.1.0
#7  0x00007ffff7a5d9e3 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
#8  0x00007ffff7af2671 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#9  0x00007ffff7af5abc in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0
#10 0x00007ffff7af4786 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#11 0x00007ffff7af5abc in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0
#12 0x00007ffff7af4786 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#13 0x00007ffff7af5abc in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0
#14 0x00007ffff7a824ad in function_call () from /usr/lib/libpython2.7.so.1.0
#15 0x00007ffff7a5d9e3 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
#16 0x00007ffff7af2671 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#17 0x00007ffff7af5abc in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0
#18 0x00007ffff7a823cc in function_call () from /usr/lib/libpython2.7.so.1.0
#19 0x00007ffff7a5d9e3 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
#20 0x00007ffff7aeeed7 in PyEval_CallObjectWithKeywords () from /usr/lib/libpython2.7.so.1.0
#21 0x00007ffff7b10bf7 in Py_Finalize () from /usr/lib/libpython2.7.so.1.0
#22 0x00007ffff7b22dd4 in Py_Main () from /usr/lib/libpython2.7.so.1.0
#23 0x00007ffff7474790 in __libc_start_main () from /usr/lib/libc.so.6
#24 0x0000555555554859 in _start ()

If you try to call destroy on an un-shown figure manager you don't get a seg-fault. This looks like a race-condition between the atexit function between wx and matplotlib.

22:21 $ git diff
diff --git a/lib/matplotlib/_pylab_helpers.py b/lib/matplotlib/_pylab_helpers.py
index c5ea8cc..cf6011c 100644
--- a/lib/matplotlib/_pylab_helpers.py
+++ b/lib/matplotlib/_pylab_helpers.py
@@ -149,4 +149,4 @@ class Gcf(object):
             if force or f_mgr.canvas.figure.stale:
                 f_mgr.canvas.draw_idle()

-atexit.register(Gcf.destroy_all)
+# atexit.register(Gcf.destroy_all)

prevents the segfault.

I would be interested if this could be reproduced using only WX classes.

I have re-milestoned this as 'proposed next point release' as I do not think that this should be a blocker for the next release (but am open to arguments otherwise).

[OceanWolf]

From reading the above it looks like this bug affects more than Windows, I couldn't tell if it affects Linux though, anyway, we should change the title of this bug.

Basically if I know what to test, I can see if MEP27 fixes it as a lot of code involved in window generation/destruction has been refactored, if this happened due to a race condition (or even another problem), then it stands a good chance that I have already fixed it...

[heroxbd]

@OceanWolf, thanks for your input. Unfortunately backend-refactor-wx at https://github.com/OceanWolf/matplotlib.git does not fix the bug.

$ python -c "import matplotlib; matplotlib.use('wxagg'); import matplotlib.pyplot as plt; plt.plot([0,1],[1,4]);"
Segmentation fault

[WeatherGod]

I am thinking that a quick-n-dirty solution to this problem would be for us
to register a wrapped function for atexit() that would detect if
destruction has already happened. The other way to approach this is to
figure out what is it that plt.show() does in Wx that prevents this from
happening.

Just curious, does the segfault happen if you do a fig.savefig()?

On Thu, Jul 9, 2015 at 5:55 AM, heroxbd notifications@github.com wrote:

@OceanWolf https://github.com/OceanWolf, thanks for your input.
Unfortunately backend-refactor-wx at
https://github.com/OceanWolf/matplotlib.git does not fix the bug.

$ python -c "import matplotlib; matplotlib.use('wxagg'); import
matplotlib.pyplot as plt; plt.plot([0,1],[1,4]);"
Segmentation fault

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

[OceanWolf]

I think I see the problem, we create a window, but never actually show it, so we never have anything GUI to close.

@heroxbd Thanks for the code. I can see why MEP27 doesn't fix it, though I think it will make it easier to fix (note also that backend-refactor-wx only has a rough implementation of MEP27 needing a rebase from the main MEP27 branch which will happen as soon as I get the all clear to carry on, i.e. once @tacaswell has the time to do a full read through).

When I resume the MEP27 work on the other backends I will take a look at fixing this (though I might need a reminder).

[heroxbd]

Benjamin Root notifications@github.com writes:

Just curious, does the segfault happen if you do a fig.savefig()?

Yes, it segfaults no matter if you called savefig() or not.

[RobinD42]

Hi all,

I finally got a chance to dig into this issue with the debugger. The guesses so far have been on the right track about a conflict with wx's cleanup and atexit processing. Specifically the frame was already in the process of being deleted when the Destroy method was being calling again, and so it tried using a now-bad pointer to call the C++ Destroy method. The reason it didn't happen when with window was shown is because the frame would delete itself when it was closed, before the atexit code started.

PR #5639 will fix this and should be safe for all versions of wx.

[bikramditya]

Hi All,
I am using WXpython to build GUI. I observed the same issue when closing the second frame.
Where should i add the fix suggested by RobinD42

[zong]

Same as @bikramditya, can repro on OSX Yosemite with matplotlib 1.5.1 and wxPython 3.0.2.0 with the following three-line program, which hangs on the last line:

import wx
import pylab
app = wx.App(False)

Does not occur if wx alone is imported. Does not occur with either matplotlib 1.4.3 or wxPython 2.8.12.1.

[efiring]

@ZonG0 I think you are seeing a different problem. If you are creating your own wx.App you should not be using pylab at all. See the embedding examples in http://matplotlib.org/examples/user_interfaces/index.html.

[zong]

I gave that only as a minimal example. There is something obviously wrong when two imports cannot coexist.

Edit: Was able to get past the last line hanging by prepending

import matplotlib
matplotlib.use("wxAgg")