 |
From: Sam Partington <sam.parting...@gmail.com>
Date: Wed, 19 Sep 2012 10:40:14 +0100
Local: Wed, Sep 19 2012 5:40 am
Subject: Re: [wxPython-dev] Segmentation faults - a theory
On 18 September 2012 20:21, Robin Dunn <ro...@alldunn.com> wrote:
> Python's GC doesn't (and can't) deal with C/C++ memory and object
Yes and no. Pythons GC could be used to track all deletions if *all*
> allocations. Only with Python objects. allocated objects were owned by PyObject's objects. This is not trivial though, and would require a lot of changes to wxWidgets. This could be done upstream though, if hooks were put into wxWidgets to make all allocations go through a wxTrackObject fn, and all deletes go through a similar wxUntrackObject. The default wxWidgets implementation of these would be
template<typename T> T* wxTrackObject(T* t) { return t; }
Every allocation would then do (the first new I found in the source):
wxAuiToolBarArt* wxAuiDefaultToolBarArt::Clone()
}
And every delete would then do:
wxAuiToolBar::~wxAuiToolBar()
}
wxPython could then somehow replace that with something that created a
PyObject with appropriate tp_new and tp_free. It gets slightly more complicated with container types because you have to help the GC out, but it's not terribly hard. I am not really suggesting we do this, and it would be an enormous
> IMO there are a few normal, legitimate uses of Destroy, and one legitimate
(skip several valid use cases)
> but abnormal use case. The normal cases are things like: If there is even one valid use case then it must be supported. If it
> I suppose I could add something like this:
The problem is that you don't always know that you are self
> def SelfDestruct(self): # or maybe SafelyCommitSuicide ? ;-)
destructing. In a complex app many code paths can mean that an event handler for a fn is far away up the callstack from the code that is actually doing the destroy. In our most recent crash on win32 a double click in a dialog mysteriously got converted into a drag message in the frame that was behind the dialog, which caused the edit control which owned the dialog to be destroyed, in turn destroying the dialog. In this case a simple CallAfter did not resolve the problem, we had to capture all mouse events for the lifetime of that dialog. Nor would hiding the dialog be appropriate in this case. What makes me nervous is that these things keep cropping up in ways
> def SelfDestruct(self):
The problem with that is that (at least in my version of the source,
> self.Hide() > wx.GetApp().ScheduleForDestruction(self) 2.9.4) DeletePendingObjets only seems to be called at application shutdown. Doing this for every destroy would result in an ever expanding working
Sam
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||