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.

FYI, WIN32OLE#ole_free does not GC WIN32OLE object.
WIN32OLE#ole_free release COM wrapped by WIN32OLE object.
GC.start does GC WIN32OLE objects. (And when WIN32OLE object GCed, 
the COM wrapped by the WIN32OLE object is released automatically.)

  Regards,
  Masaki Suketa