I’ve got a pretty large maxscript/dotnet tool (the outliner selection tool), which is working quite well, and stable. However, I believe there is a pretty serious amount of memory leakage going on:
Following a garbage collection crash that occured after the tool had run, I decided to look into the memory usage before and after the tool had run. To my surprise, the outcome looked like this:
(
gc light:true
local heapStart = heapfree;
macros.run "outliner" "toggleOutliner"
gc light:true
format "% used
" (heapStart - heapfree);
macros.run "outliner" "toggleOutliner"
gc light:true
format "% uncollected
" (heapStart - heapfree)
)
--first execution
348264L used
119444L uncollected
--second execution
346612L used
118600L uncollected
--and so on
This continues until the heap is full, and is increased in size automatically.
The amount of memory not returned to the system is pretty consistent too: ~ 118500L
Now, what am I doing when closing the tool?
-Remove all event handlers, both in the .NET dispose code as well as in maxscript.
-Remove all general event callbacks.
-Set all rollouts and struct instances to undefined.
-No files are left opened.
Things that I’ve tried, but didn’t help significantly:
-(dotnetClass “System.GC”).Collect()
-full garbage collection instead of light:true
I know that it’s hard to say something specific about the project itself without any code, but it’s a little unpractical to post everything here… But any pointers in which direction I should look for potential leaks would be very much appreciated!
Is your script loading bitmaps with dotNet? I recently noticed that they will stay in memory, unless you manually delete them on unload.
I load Images (from embedded resources) into the imagelist of a (customized) .net treeview. I handle this in C# entirely by the way, so there are no .NET Image objects in maxscript.
I had assumed that these would be released when the control.Dispose() function was run…?
If they are disposed, it should be fine…but I’m a total n00b with dotNet etc.
here is my bitmap memory leak discussion thread:
http://forums.cgsociety.org/showthread.php?f=98&t=860080
I added some code in the treeview’s Dispose function to dispose the images explicitly, but it made no difference…
Thanks for your suggestion though.
edit: I thought it was a dynamically compiled assembly first, but I was a bit too quick with drawing conclusions
Ok, I’ve managed to narrow the problem down to the one dotnetMXSValue that I use in the whole tool. It was not being collected by the maxscript garbage collector. I did actually read the dotnetmxsvalue topic in the help, but somehow didn’t think of the fact that I was using it myself…
So now I clean it up like this:
--at some point in the code the value is created:
fileWatch.MXSObject = dotnetMXSValue kbd_actions
--and it is cleaned when closing the tool:
fileWatch.MXSObject = undefined;
(dotnetClass "System.GC").Collect();
Now the test results look much, much nicer:
329696L used
180L uncollected
OK
329412L used
88L uncollected
OK
329656L used
156L uncollected