[Closed] DotNet Memory Leak

as far as i’m aware, dispose only cleans up any unmanged resources associated with the object/control. the rest of the object wont be cleaned up until the next garbage collection.

Is the memory freed after you run a System.GC.Collect() ?

I should have mentioned that I tried that as well. I don’t remember seeing issues like this and I have created huge dotNet tools.

how often are you creating and disposing listviews that its becoming a problem?

Well I’m not, but reopen the tool and mem goes up, over a day I don’t know how often some one will open the UI.

What happens if you run maxscript’s garbage collection after the .NET dispose?

try(controlPanelList.dispose())catch()
gc light:true

I’ve had similar experiences with apparent memory leaks when using .NET objects, and if I remember correctly, it was gone when using maxscript’s gc…

I didn’t even think to try. I’ll give it a shot and see what happens.

I’ve been looking at some of my ‘old’ code, and I usually do it in this order:
[ul]
[li]Dispose the object through its Dispose() method
[/li][li]Nullify the object (theVar = undefined)
[/li][li]System.GC.Collect()
[/li][li]gc light:true
[/li][/ul]
Now I know that I’ve been messing about with this issue too, but I can’t remember the exact outcome or reasons for it. So I think this was either the actual solution to it, or a sort of “it can’t hurt to do it” type of action… hehe.

Generally speaking, calling GC.Collect() does not always ensure the immediate release of memory from disposed objects, it only flags them as pending for their finalizer to execute.

If you want to ensure memory release in a synchronous manner, use this:

(dotnetClass "System.GC").Collect()
(dotnetClass "System.GC").WaitForPendingFinalizers()
(dotnetClass "System.GC").Collect()

Having said that, I came to the same result you did even with this code, though I haven’t tried specifing the generation to collect like you did.

Nice work. I just opened and closed the UI about 10 times and didn’t have any memory leak. Such a simple answer to the problem I don’t know why I didn’t think about it. Casting the lifetime back to #mxs works great. The trick with the maxGeneration I didn’t even know about.

Thanks for posting this.