I don' t know how big the leak is. But I am creating and disposing of 
many DB windows. However, it is only one window, at the moment. I have 
created ones with 20,000 rows by 10 columns wide with some long strings 
in the cells.  Sometimes it is taking an additional 20MB when opening a 
DB as reported by top in the RSIZE column.  They always seem to dispose 
without any problems.  I have setup QuickKeys to create and close a DB 
window hundreds of times of this size.

I have seen my app blow up to 100mb before I disposed of a DB correctly.

~ steve



On Jan 15, 2005, at 11:47 PM, Robert Purves wrote:

>
> I wrote:
>
>> callbacks.v1.itemCompareCallback = fn 
>> NewDataBrowserItemCompareUPP([proc "ItemCompareProc" + 
>> _FBprocToProcPtrOffset])
>>
>> Note that this statement causes a memory leak, because there is no 
>> way either to reuse a previously created UPP, or to dispose of a 
>> no-longer-required UPP.  Every DataBrowser example in FB that I have 
>> seen perpetuates this bug.
>
> Oops, that's putting the case for the prosecution too strongly. A 
> defendant could plausibly argue that DataBrowser demos tend to create 
> exactly one DataBrowser in one window, which persists for the life of 
> the demo application. There is then no question of a memory leak from 
> NewDataBrowserXXXXXXUPP. The leak occurs when someone hastily adapts 
> the simple demo to an application that creates and disposes of many 
> DataBrowsers during its running life.
>
> Robert P.
>
> --
>