Re: possible memory leak in quantlib addin

Posted by Ferdinando M. Ametrano-3 on
URL: http://quantlib.414.s1.nabble.com/possible-memory-leak-in-quantlib-addin-tp782p783.html

Hi Philip

you wrote:
> If I recalc the sheet a few times I see that handles change for example
> european_option#3706 becomes european_option#3707
> which is all fine. However I noticed that I then type european_option#3706
> into a cell, I would expect that the handle would be no longer valid and so
> I would expect not to be able to use it again. But to my surprise the handle
> still worked.

the ObjectID's #xxxx suffix is not really part of the object ID name,
it's just an informative counter to help detect how many times an
object is created in a workbook; it's there mainly to help avoid
useless constructions.
To prove it see the attached spreadsheet Book0.xls where a TestQuote
can be created multiple times using the F9 key:  the same (randomized
and changing) value is returned by accessing the quote with whatever
#xxxx suffix.

> This to me looked like a possible memory leak. I.e. old handles are not
> being deleted.

they are deleted. Objects are created as shared_ptr, so as long as
nobody is pointing to them they are destructed.

> To test it, I wrote the following VBA:
> Option Explicit
>
> Sub calc_forever()
>     ' This can be used to check for the presence of memory leaks.
>     ' The sheet is recalculated multiple times, if there is a memory leak,
>     ' then the process size will grow.
> [...]
>    While True
>        Application.CalculateFull
>   Wend
> [...]
> In my experience, when handles in excel are properly implemented, sheets can
> be left recalculating thousands of times over hours or days and the process
> size won't grow.

you can check that using with Book1.xls the memory usage is stable.

So you're now probably wondering what the attached Book2.xls if for.
Well your email ringed a familiar bell, as I've got suspicious about
the memory usage of my QuantLib Excel sessions.
So I tried something more than what you reported and noticed that as
soon as RelinkableHandle come into play there is really a leak, as you
can see using Book2.xls
The leak is the RelinkableHandle construction, and in fact can be
avoided using Application.Calculate instead of
Application.CalculateFull

I hope Eric will step in here :-)

ciao -- Nando

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users