I am trying to script a simpleMod plugin that deforms an object based off of values stored in arrays in the plugins parameters. The script works but eventually freezes after a while. I have been able to determine that the freeze is being caused by maxscript running out of memory. Increasing the heap size causes the pluigin to run longer but eventually it freezes up. It seems that when the script accesses the array it stores the values in memory and those values remain memory as new values are read in from the array at each point generated in the map handler. As values are generated in the map handler the memory builds up very quickly. I think that when maxscript runs out of memory it tries to run automatic gc() and at this point max freezes. Occasionally I get an error stating that an unknown error occured during garbage collection or that maxscript has run out of memory, but most of the time max just freezes up. Is there anyway to prevent max from storing the old values without running gc(). I have tried running gc() at certain points in the map handler but this just freezes max as well. Any suggestions would be great, thanks.
-bnvm
This is kind of a shot in the dark, but does your script use the meshop.getEdgesReverseEdge command anywhere? I’ve since removed this command from my script, but it was causing both manual and automatic gc() calls to occasionally crash with an “Unknown System Exception” message (this message never varied). I worked around this bug for about 10 months before I realized what was causing the gc() crashes. Its been about a year since removing the meshop.getEdgesReverseEdge command, and no crashes anymore.
BTW, I would not assume that the ‘Out of Maxscript Memory’ errors and freezes are related to the actual gc() crashes at all. From the way you described them, these sound like MaxScript simply running out of memory…half the time you get the message, the other half max just freezes. (You are correct about the automatic gc() calls being initiated by MaxScript. In my experience, they seem to be triggered when heapFree gets down to about 100kb-250kb.) When MaxScript starts to run out of memory that gc() can actually reclaim, it will start doing automatic gc() calls more and more frequently until an out-of-memory error occurs. (My script uses massive arrays of data stored in MaxScript memory as persistent global variables, so if I don’t increase the heapSize when gc() can’t free up more memory, MaxScript will eventually crash just like you described.) In my experience, this behavior had nothing to do with the gc() crashes.
Thanks for the tips. The script doesn’t do any mesh ops at all. In fact it simply calculates the offset by pluging in values from the arrays into a fuction. Thats all. It does excute a string since I haven’t found way to store an array that has arrays within into one of the plugins parameters other than a string tab. But with testing I found that it crashed even if I only accessed values within the array and do nothing with them. The higher the base mesh the quicker the script crashes. I suppose its possible that script isn’t freezing rather cg() is being called constantly slowing max down to a crawl. But I am stupped so far.
-bnvm
>>bnvm wrote:
>>I suppose its possible that script isn’t freezing rather cg()
>>is being called constantly slowing max down to a crawl.
I was unclear in my post, and I was not suggesting this was happening. The “more and more frequent” automatic gc() calls are really just a brief occurance right before MaxScript runs out of memory and completely crashes. AFAIK, they couldn’t be the cause of a noticeable or prolonged slowdown.
Sorry I couldn’t help. Might be a memory leak or something else more fundamental maybe…Is it possible for you to post any of the code?
Sure here’s a link to a post I did earlier with the code.