When I exit my application I get a handful of these:
WARNING: Unexpected error: ( <class ‘wx._core.PyDeadObjectError’> , The C++ part of the SessionTargetConsole object has been deleted, attribute access no longer allowed. , <traceback object at 0x2630ab8> )
WARNING: Unexpected error: ( <class ‘wx._core.PyDeadObjectError’> , The C++ part of the StatsPane object has been deleted, attribute access no longer allowed. , <traceback object at 0x2630a70> )
I’m guessing this is probably due to some asynchronous, non-WxPython events occurring after windows have been destroyed. Is there any way to get more information on for those errors. The actual traceback would be nice. I’m using 2.9.4.1 (patched) on x64 Linux.
When I exit my application I get a handful of these:
WARNING: Unexpected error: ( <class 'wx._core.PyDeadObjectError'> , The C++
part of the SessionTargetConsole object has been deleted, attribute access
no longer allowed. , <traceback object at 0x2630ab8> )
WARNING: Unexpected error: ( <class 'wx._core.PyDeadObjectError'> , The C++
part of the StatsPane object has been deleted, attribute access no longer
allowed. , <traceback object at 0x2630a70> )
I'm guessing this is probably due to some asynchronous, non-WxPython events
occurring after windows have been destroyed. Is there any way to get more
information on for those errors. The actual traceback would be nice. I'm
using 2.9.4.1 (patched) on x64 Linux.
Is it possible that you are using some wx.CallAfter thing that tries
to access a window being destroyed? Are you handling the wx.EVT_CLOSE
event and, if yes, do you do anything special in it?
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
The PyDeadObjectError is raised if you try to access an attribute of a wrapped C++ object after the C++ object has been deleted. (IOW, only the Python proxy object still exists.)
You can get errors without tracebacks if the exceptions happen in __del__ methods, and since it is happening during shutdown in your case then it is compounded by the fact that Python will get to the point of forcibly deleting objects during its shutdown/cleanup phase if the objects are not cleaned up naturally by simple reference counting and gc.
There are two things you can do to try and eliminate these errors. First, try to ensure that all wx windows are closed before you actually exit your main application script. For example, Close() all frames and Destroy() all dialogs. You can use wx.GetTopLevelWindows() to find out what TLWs may still exist. You should also ensure that any timers are stopped and wx.TaskBarIcons are destroyed. You should try doing these before MainLoop exits so it can do the final cleanup of these windows before returning.
Secondly, you can try to protect code that may be executed from __del__ methods or in event handlers or callbacks that might triggered while the application is shutting down. One way would be to set a global shuttingDown flag that you check before doing anything in the function. Or you can check the window objects themselves since anything that would raise a PyDeadObjectError will also return False from __nonzero__. That means that if you have some code like this that you suspect may be called after the C++ part of self has been deleted:
value = self.GetValue()
self.doSomething(value)
Then you can protect it like this:
if self:
value = self.GetValue()
self.doSomething(value)
···
On 11/29/12 9:41 PM, Mears wrote:
When I exit my application I get a handful of these:
WARNING: Unexpected error: ( <class 'wx._core.PyDeadObjectError'> , The
C++ part of the SessionTargetConsole object has been deleted, attribute
access no longer allowed. , <traceback object at 0x2630ab8> )
WARNING: Unexpected error: ( <class 'wx._core.PyDeadObjectError'> , The
C++ part of the StatsPane object has been deleted, attribute access no
longer allowed. , <traceback object at 0x2630a70> )
I'm guessing this is probably due to some asynchronous, non-WxPython
events occurring after windows have been destroyed. Is there any way to
get more information on for those errors. The actual traceback would be
nice. I'm using 2.9.4.1 (patched) on x64 Linux.