Chuck Remes wrote:
> On Jan 16, 2010, at 5:25 AM, Masaki Suketa wrote:
>
>   
>> On Sat, Jan 16, 2010 at 01:59:55AM +0900, Chuck Remes wrote:
>>     
>>>> How about calling GC.start before requesting the next batch?
>>>> # If you had used GC.start already, ignore this suggestion.
>>>>         
>>> Calling GC.start does not fix the problem. The program continues to leak 
>>> memory and run out.
>>>
>>>       
>> Thank you for testing calling GC.start.
>> Hmmm..., I don't have any idea to fix this issue.
>>
>> BTW,
>>
>>     
>>>> On Jan 12, 6:19 pm, Chuck Remes <cremes.devl... / mac.com> wrote:
>>>>
>>>>         
>>>>> I have tried adding my_object.ole_free calls everywhere, but that has
>>>>> not helped at all. I've looked through the archives (back to 2004)  
>>>>> and
>>>>> saw that this was a common issue years ago. I had hoped it would be
>>>>> fixed by now.
>>>>>           
>> I had fixed some Win32OLE memory leaks on 2007. 
>> So, I think this issue is not same issue in 2004.
>>
>> And I have been trying to create simple script which leaks memory
>> like this issue, but I have not succeeded yet.
>>
>> I'll investigate this issue more, but I think it is not easy to
>> fix this issue because I have not created the sample script yet.
>>     
>
> I have new information on this WIN32OLE memory leak.
>
> ruby 1.9.1 p378 (from rubyinstaller.org)
>
> I believe I have narrowed the problem down to its core, but I need some help to prove it.
>
> In my program I attach to a COM object and register for several events. One of the events delivers a large chunk of data (anywhere from a few K to several megabytes). I process this data (write it to a database) and then wait for the next event.
>
> I believe that the data delivered through to the event is *never* garbage collected. I proved to myself that it is not my code leaking memory by commenting out my event handler. I am still receiving those events and watching as my memory footprint grows until the ruby executable finally dies at around 1.5 GB. BTW, it exits with an exit code of 239 but my exit handler (#at_exit block) is never executed in this out of memory situation.
>
> Also, I have run the program with GC.stress = true and it still leaks until it dies. For some reason the garbage collector either doesn't know about this memory or thinks that there is still a valid reference to it somewhere.
>
> I could absolutely prove this leaking theory if I had a small windows program that just issued COM events and passed some data with the event. We would see that the data is never freed.
>
> cr
>   
COM has a fairly elaborate protocol for memory management 
responsibilities across interfaces. Its been quite a while since I have 
had anything to do with it, but I am pretty sure that the receiver and 
generator of COM data needs to explicitly free via the appropriate COM 
procedure.

-- Bill