Prev: New AES gem available -- fast-aes
Next: ANN: Sequel 3.13.0 Released
From: Chuck Remes on 1 Jul 2010 11:24

On Mar 24, 2010, at 3:12 PM, Chuck Remes wrote:

> On Mar 24, 2010, at 3:09 PM, Chuck Remes wrote:
>
>> I have continued to chase this problem down. I think I may have a lead, but I need someone familiar with the win32ole.c code to confirm or deny my suspicions.
>>
>> I have pastied the invoke method here: http://gist.github.com/342716
>>
>>
>> Take a look around line 118 of the pastie. This code is making copies OR references to each parameter before invoking the event sink callback.
>>
>> After the block is invoked, I think at least one of the code paths does NOT call VariantClear() on the passed parameters (see line 215). Won't that lead to a memory leak for these parameters?
>>
>> Could this be the leak that has been plaguing me?
>
> I should have noted that the code snippet comes from ruby 1.9.1 p-376.

I have discovered the root cause of this problem. The good news is that it isn't a problem with the Ruby WIN32OLE implementation.

I don't know if all COM servers work this way, but the specific application I am using memory-maps all WIN32OLE_EVENT data parameters. The space consumed by this memory-mapped data is registered in the ruby process and not against the COM server.

Since COM objects do memory management via reference counting, I had to specifically release the data given to my event callbacks. I didn't know this was a required step (the COM server API docs are silent on this issue) so I was slowly leaking these references every time my event callbacks were fired. I have now corrected my misuse of this COM server's API and all is well.

cr


 | 
Pages: 1
Prev: New AES gem available -- fast-aes
Next: ANN: Sequel 3.13.0 Released