After additional digging I found were the leek appears to be.  It
occurs in COMObject::__make_interface_pointer with the following
lines:

        for iid in iids:
            self._com_pointers_[iid] = pointer(pointer(vtbl))

I'm not sure why that the items in _com_pointers_ do not get free'd,
but as a work around I added the following to IUnknown_Release which
seems to resolve the issue (not much testing though).

        if result == 0:
            self.__unkeep__(self)
            # new code to fix leek
            self._com_pointers_ = {}

My guess is some part of creating the methods array in
__make_interface_pointer causes a reference to our class is a part of
the method  deinition then added to the vtbl which is then added to
self._com_pointers_ creating a typical python memory leek...

-mike

On Mon, Oct 19, 2009 at 4:54 AM, Michael Eddington <medding...@gmail.com> wrote:
> Further investigation shows this also occurs when the com object is
> created with out being first registered (e.g. just creating an
> instance of the object in python).  The following code reproduces this
> issue:
>
> import comtypes
> from comtypes.client import CreateObject
> import gc,time,threading
> import comtypes.server
> import comtypes.server.connectionpoints
> from comtypes import CoClass, GUID
>
> class TestComServer(CoClass):
>        _reg_clsid_ = GUID('{BCCF36F6-4310-4953-B357-0B358BAE2DF1}')
>        _reg_threading_ = "Both"
>        _reg_progid_ = "TestComServer.Testing.1"
>        _reg_novers_progid_ = "TestComServer.Testing"
>        _reg_desc_ = "Memoryleak testing"
>        _reg_clsctx_ = comtypes.CLSCTX_INPROC_SERVER
>        _com_interfaces_ = [comtypes.typeinfo.IProvideClassInfo2,
>        comtypes.errorinfo.ISupportErrorInfo,
>        comtypes.connectionpoints.IConnectionPointContainer]
>
> while True:
>        sink = TestComServer()
>        sink.IUnknown_Release(sink)
>        sink = None
>        gc.collect()
>
> # end
>
>
> On Mon, Oct 19, 2009 at 2:54 AM, Michael Eddington <medding...@gmail.com> 
> wrote:
>> Hello,
>>
>> I'm using the latest released comtypes version (0.6.1).  I have a long
>> running python process that creates and releases a com object also
>> written in python.  I noticed that this causes a memory leak.  This
>> does not occur if I perform the same operations on a com object
>> written in C++.
>>
>> Below is code for the python com server (inproc) and also the test
>> app.  To reproduce:
>>
>> 1. Open task manager
>> 2. python testcomsrver.py -regserver
>> 3. python testcom.py
>> 4. Notice process continues to grow in size...
>>
>> I'm using ActiveState Python v2.5.4 on 32bit Win7.
>>
>> -mike
>>
>> testcomsrver.py
>> ===========
>>
>> import comtypes
>> import comtypes.server
>> import comtypes.server.connectionpoints
>> from comtypes import CoClass, GUID
>>
>> class TestComServer(CoClass):
>>        _reg_clsid_ = GUID('{BCCF36F6-4310-4953-B357-0B358BAE2DF1}')
>>        _reg_threading_ = "Both"
>>        _reg_progid_ = "TestComServer.Testing.1"
>>        _reg_novers_progid_ = "TestComServer.Testing"
>>        _reg_desc_ = "Memoryleak testing"
>>        _reg_clsctx_ = comtypes.CLSCTX_INPROC_SERVER
>>
>>        _com_interfaces_ = [comtypes.typeinfo.IProvideClassInfo2,
>>                                                
>> comtypes.errorinfo.ISupportErrorInfo,
>>                                                
>> comtypes.connectionpoints.IConnectionPointContainer]
>>
>> if __name__ == "__main__":
>>    try:
>>        from comtypes.server.register import UseCommandLine
>>        UseCommandLine(TestComServer)
>>    except Exception:
>>        import traceback
>>        traceback.print_exc()
>>        raw_input()
>>
>> # end
>>
>>
>>
>> testcom.py
>> ========
>>
>> import comtypes
>> from comtypes.client import CreateObject
>> import gc
>>
>> while True:
>>        obj = CreateObject("TestComServer.Testing")
>>        obj.Release()
>>        obj = None
>>        gc.collect()
>>
>> # end
>>
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
comtypes-users mailing list
comtypes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/comtypes-users

Reply via email to