On Wed, 18 Jun 2008 18:03:49 +0000 (UTC), Kevin Watters <[EMAIL PROTECTED]> wrote: > There's a comment in siplib.c:5300ish in the sip_api_is_py_method > function that I'll reproduce here: > > /* > * Note that the callable is never garbage collected. The main > * reason for this is that it's not possible to get hold of the > * method cache without make incompatible changes to the SIP > * API, particularly to support the cyclic garbage collector. > * It would be a lot easier if the cache was held in the > * Python object rather than the derived C++ class (and this > * function would be passed a cache index instead of a pointer > * to the cache entry). Dropping the cache completely should > * also be considered which would have the advantage of making > * monkey patching predictable. With cyclic garbage collector > * support we could also just save a reference to a > * reimplementation that was a method rather than save the > * separate components, which would also allow a borrowed > * reference to the reimplementation to be returned so that the > * virtual handler wouldn't need to decrement its reference > * count. > */ > > I'm tracking down a memory leak in my app--and I think it's boiling > down to a virtual method on one of my classes that has an extra > reference, one not coming from any Python object. > > This virtual method is /bound/, though, so my understanding is that > it carries "self" in its im_self attribute and is keeping the rest of > my objects alive when they shouldn't be. Should I be worried about > that comment--and specifically that objects using virtual methods will > leak? Reading the code seems to say otherwise; that the comment is > applying to the case when a monkeypatched callable has been set on the > class--not when you override a method in a subclass like usual. > > Phil, do you mind explaining the limitation this comment is describing > a bit more? I appreciate any help!
It should be fixed in tonight's SIP snapshot. It was just a Py_DECREF() that got dropped. Phil _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
