iT2D 1.5 Preview 1 - Memory Leak when PUAP_SCRIPT_CHANGE is not defined - LOGGED (ITGB-205)
by Tim Newell · in iTorque 2D · 07/14/2011 (12:37 pm) · 6 replies
Build:1.5 Preview 1
Platform: Windows, Mac, Device and Simulator
Target: Device or Standalone
Issue: Turning off PUAP_SCRIPT_CHANGE causes memory leaks when the dictionary in popFrame of consoleInternal.cc is deleted because the dictionary does not delete its hashtable when it is deleted. If you setup the deconstructor of the dictionary to delete the hashtable it will crash.
Step to Reproduce:
1) Do not define PUAP_SCRIPT_CHANGE
2) set up a script function to be called a lot (like sceneUpdate script function)
3) Open something to watch memory like task manager on windows and watch the memory climb when nothing is going on
Suggested Fix: I ended up fixing this locally by converting the old hashtable structure from TGB back into iTGB's Dictionary class. There is something about the new hashtable class that causes crashes when trying to delete it. I did not have time to find out why the new code fails but maybe this will help you track it down.
Platform: Windows, Mac, Device and Simulator
Target: Device or Standalone
Issue: Turning off PUAP_SCRIPT_CHANGE causes memory leaks when the dictionary in popFrame of consoleInternal.cc is deleted because the dictionary does not delete its hashtable when it is deleted. If you setup the deconstructor of the dictionary to delete the hashtable it will crash.
Step to Reproduce:
1) Do not define PUAP_SCRIPT_CHANGE
2) set up a script function to be called a lot (like sceneUpdate script function)
3) Open something to watch memory like task manager on windows and watch the memory climb when nothing is going on
Suggested Fix: I ended up fixing this locally by converting the old hashtable structure from TGB back into iTGB's Dictionary class. There is something about the new hashtable class that causes crashes when trying to delete it. I did not have time to find out why the new code fails but maybe this will help you track it down.
#2
Would any kind soul put a patch up so I don't have to think any harder. My brain hurts already. :P
03/22/2013 (11:11 am)
Heh. I think I just found this the hard way. Specifically, TGB 1.5 (final) leaks. I have indeed turned off PUAP_SCRIPT_CHANGE because my scripts would cause bizarre TorqueScript corruptions with it on. And now I do see lots of hashtable and dictionary calls related to the leak (in Mac Instruments).Would any kind soul put a patch up so I don't have to think any harder. My brain hurts already. :P
#3
Yet, I *still* am getting a big leak.
I'm not sure how you rooted this out in the first place!? My knowledge of XCode ends with seeing the leak (in Instruments) but I don't know how to get a stack trace of leaks.
Would you be willing to share your patch? Or advice on rooting out leaks with stack traces?
Thanks.
03/22/2013 (4:17 pm)
@Tim. You were right. I found the leak and patched it. Moving over TGB code looked like a much bigger exercise.Yet, I *still* am getting a big leak.
I'm not sure how you rooted this out in the first place!? My knowledge of XCode ends with seeing the leak (in Instruments) but I don't know how to get a stack trace of leaks.
Would you be willing to share your patch? Or advice on rooting out leaks with stack traces?
Thanks.
#4
03/22/2013 (4:28 pm)
To be honest I cannot remember how I found this because it was so long ago. One simple way to find where a memory leak is happening is to disable stuff until your leak stops. Another is to use the built in memory debugging in torque. It will keep track of news and deletes and report leaks on exit I believe.
#5
BTW, I'm 90% sure I got all the memory leaks now. Once I've tested it a few times I'll post a patch for anyone who wants it.
The reason it was crashing when deleting the hashtable was because sometimes Dictionaries share hash tables. This remnant of the legacy code was conveniently ignored in the new code. :P
The second leak I had was this: before deleting a hashtable, you have to also go through the hashtable and delete its content. The reason is that the Dictionary allocates Entry objects and then stores pointers to them in the hash table. This is the only reference to these objects. In the end, though, the Dictionary never deletes them. Nice. This should have been a problem even with PUAP_SCRIPT_CHANGE on I would think.
03/22/2013 (9:19 pm)
Thanks Tim. I keep worrying I'm missing some easy switch that I flip and get a list of clickable memory leaks.BTW, I'm 90% sure I got all the memory leaks now. Once I've tested it a few times I'll post a patch for anyone who wants it.
The reason it was crashing when deleting the hashtable was because sometimes Dictionaries share hash tables. This remnant of the legacy code was conveniently ignored in the new code. :P
The second leak I had was this: before deleting a hashtable, you have to also go through the hashtable and delete its content. The reason is that the Dictionary allocates Entry objects and then stores pointers to them in the hash table. This is the only reference to these objects. In the end, though, the Dictionary never deletes them. Nice. This should have been a problem even with PUAP_SCRIPT_CHANGE on I would think.
#6
03/24/2013 (11:00 am)
Put a bug fix patch here: http://www.garagegames.com/community/forums/viewthread/133570
Associate redmasqu3rad3
GarageGames