[fdo-internals] SDF 3.0 Memory Leak

[Carl Jokl]

I suppose the SDF 3.0 provider is looking like a bit of a red herring then if
the memory leak is more widespread. Out of curiosity I tried performing some
activities using the demo app which I am using based on the Sheboygan
example but which is calling the framework I am implementing. I used windows
task manager just to monitor the memory footprint of the ASP.Net worker
process. It too seemed to show that over time more memory would be consumed
and not be released. The rate at which more memory was consumed is naturally
slower than the benchmark because data is not been churned over at anything
like the same rate. Still the signs were exhibited showing the same
potential memory leak. 

It might help to know a bit more about the mechanism or intended mechanism
by which the managed wrappers are supposed to dispose of underlying native
resources.

If I observed correctly it looked to me like the native code is using a
reference counting mechanism presumably to dispose of an object when the
number of references pointing to it reaches 0.

Both Java and .Net have a finalize() / Finalize() method on classes to be
called when an object instance is about to be garbage collected. Do the
managed wrappers make use of these methods to inform the native code that
the wrapper is no longer referencing it?

The issue of disposal becomes complex if several managed object instances
might be refering to the same underlying unmanaged object. In that case the
same reference counting mechanism could still come into play. Every time a
managed wrapper is garbage collected the reference counter would be deducted
until the object is deleted when the reference count reaches zero.

-- 
View this message in context: http://www.nabble.com/RE%3A-SDF-3.0-Memory-Leak-tp18531236p18563652.html
Sent from the FDO Internals mailing list archive at Nabble.com.