iTGB 1.2 - Exit Error 101 - Memory Leak?!

#1 I'm having the same problem here for one of my games.

It worked fine on 1.1

#2 I'll flag this as a possible bug then. In the meantime, I'll be considering a massive port to C++ and some major leak hunting... this is the only thing stopping my current game from being released. :(

#3 I ran mine in the leak tool with the simulator and it looks like there is something that happens 3 times and then the memory spikes up about 20MB. It says something like...

Memory::pageAlloc()

#4 After much tweaking of my code and disabling the memory manager, I now get 3 full games and a crash in the 4th... I'm looking at the memory instrument and the overall bytes continue to go up and up. Net bytes goes up as well, but much slower. Shouldn't these things be frozen if I just load up the front splash and don't start the game?

#5 depends on what your scripts do as they are exec all upfront if you didn't restructure the script hierarchy

#6 How should I organize them? I have all my exec in the same spot in my StartGame function.

#7 I turned off everything but loading the main screen (1 bitmap, 3 buttons, nothing else) and while the number of bytes is lower, "overall" is still going up at the same rate. "Net" goes up, but is much more flat. Which do I use as the benchmark?

#8 Okay, educated myself here:

Quote:
* Net Bytes - the number of bytes of this type currently allocated but not yet released.
* Overall Bytes - the total number of bytes of this type that have been allocated, including those that have
been released.

-source

So.... looks like I have a leak somewhere in the game script. Blah.

UPDATE: And you know what's odd is that it crashes in 2.x games if you play all human, versus 3.y games if it's all computer players. That's counter-intuitive given there's more script, more schedules, more sprite creation / deletion, etc when an AI is running.... Very close to calling this one a bug in iTGB.

#9 Okay, even loading a blank level appears to cause the net bytes to keep going up and up.

If you comment out "metrics( fps )" out in levelManagement.cs, the net bytes stop going up on a blank level load in the Mac build. But if you load it up onto the iPhone, the problem still persists.

So what happens in a normal game? Well, play one match and the net bytes go up during play... as should happen. Once the match is over the Mac the net bytes stop going up, which makes sense since nothing is going on, but on the iPhone they still go up. Furthermore, I've noticed that iTGB never seems to release bytes, even after all objects are deleted and the match is over. Plus, iTGB isn't reusing the already allocated memory. It just requests more with each match.

I put in many, many safeguards to delete all objects, cancel all schedules, prevent duplicate objects, etc... I think this has to be a 1.2 bug.

#10 I just started full-on device testing of my first game and I noticed it's cutting out and exiting to the Home screen after playing a while. I disabled the memory manager just to see if I can get a better framerate (will discuss that in another thread), perhaps that's the issue, or are we really looking at a real bug here? And, if so, is there any timeframe on the next release? Sorry if I sound anxious, but I've been on a roll all week and like most, I don't want any major speedbumps in the road.

#11 Building iTGB_Optimize instead of iTGB seems to stop the slow leak I observed with a blank level for the iPhone. Right now I'm still looking into the fast leak that I'm experiencing.... that one appears to be that memory is never freed after an object is deleted.

#12 Turns out mine was exiting from having a high boot time. I found a solution that works for me until I can figure out how to lower my boot time.

Right click on the target in xcode and go to "Get Info". Then change the preprocessor macro typo.

TORQUE_DISABLE_MEMORY_MANAGE -> TORQUE_DISABLE_MEMORY_MANAGER

Should have an R on the end.

#13

Quote:
Right click on the target in xcode and go to "Get Info". Then change the preprocessor macro typo.

TORQUE_DISABLE_MEMORY_MANAGE -> TORQUE_DISABLE_MEMORY_MANAGER

This is a typo for iTGB target, but not iTGB_Optimize... probably explains the small leak issue. The "big" leak I'm seeing may very well just be something buried in my script.... I've been porting Shogi to 1.2 as a test and have yet yo see the leak...argh!

#14 Alright, I think the best way to handle this is to reduce the targets down to 2. Right now we have:

1. iTGB
2. iTGB Optimize
3. iTGB Script
4. iTGB Script Optimize

I think I will eliminate 1 and 3 for builds 1.2.x and above, just to simply the issues that stem from trying multiple targets with varied results.

#15 Logged for v1.2.1

#16 Sounds good. Currently am just porting to C++. Not what I wanted to do, but not a big issue. :)

#17 Somebody has solved this?

It is in fact a bug?

Thanks

Mike

#18 Would love to know the answer for it too.
My game that was working great on 1.1 is crashing constantly on 1.2

#19 after fighting the 20 min crash for 3 days I decided to go back to 1.1
Just played the game over 2 hours and finished it. lovely.
I also tried running the iPhoneTest game (bouncing balls) under 1.2 to see if a very simple game would crash too. I launched the game , pressed gravity and let it run for 25 min until it crashed.
I hope 1.2.1 will fix it. in the meantime I'm sticking to 1.1

#20 Interesting. I wonder what it is that I did in my C++ rewrite that avoids triggering that leak.