iPad app keeps crashing

Previous topic - Next topic

AlienMenace

So, this is lovely. After spending pretty much every spare moment I have had this past month, my iPad game is finally around 95% complete. So I load it up in xcode to test it, install it on both of my iPads and it runs great... except for some random crashing that is. Every time I play it, it will crash.. eventually.  It is rock solid in Windows, runs with no problems at all. It uses the same game routines all throughout but for whatever reason, it just chokes.. sometimes after playing for 2 minutes, sometimes after 10 minutes. There is no pattern to it that I can see. I load all my graphics, sound, etc at the beginning. I'm using types for enemies, explosions, bullets, etc. I am also using an mp4 background music track, wav files for sound effects, and png files for graphics. I have been through the code several times and just don't see any issues with how the code is working. Are there any known issues that I should be aware of?

Thanks.  :rant:
Apps published: 3

MrTAToad

Are you using Shoebox files ?

AlienMenace

#2
Nope, loading all as stand-alone files.  The only thing I did find was when it I ran it with leaks instrument there were a couple of small audio leaks.
Apps published: 3

Ian Price

Sounds like there's a memory leak somewhere. Maybe if you left the pc version running long enough you'd encounter the same issue?
I came. I saw. I played.

AlienMenace

I've played the game hundreds of times on the PC, sometimes up to half an hour and have not had the program crash yet. The iPad version will crash every time, usually within the first couple of minutes but it has taken up to 15 minutes or so a few times.
Apps published: 3

MrTAToad

It would be time to start putting in some debug statements, disable sound & music etc etc to find the source of the problem

AlienMenace

I disabled the background music but that didn't seem to help. The error that xcode is reporting is EXC_BAD_ACCESS. The only objects being released should be the types after a delete command but that should terminate the loop when called. I have even added another field called .status to the type that I set to 1 then delete the type at the end of the loop just to be sure but that hasn't helped either. Even so, this loop is called many times and fails at random.
Apps published: 3

MrTAToad

Is it a Jailbroken phone or a proper one ?

Ian Price

QuoteIs it a Jailbroken phone or a proper one ?
It's an iPad.

Can you try loading in only the graphics you need at the time you need them?
I came. I saw. I played.

MrTAToad

QuoteIt's an iPad.
Ah yes!

It might be also worth commenting out areas of code (ie dont call title routine etc)

Slydog

Like MrTAToad mentioned, put log statements in your code (STDOUT for iPad?).
Perhaps place one at the start (and end?) of each function, and find out what function is the last one that ran before the crash.

Maybe to see if it's a memory issue, try hard booting each crash, then rerun it to see if it crashes at about the same time.
Play the same level and/or load the same resources etc.
This wont be conclusive or anything, just looking for a pattern.
My current project (WIP) :: TwistedMaze <<  [Updated: 2015-11-25]

AlienMenace

#11
No, it's not jailbroken. It's a progressive linear arcade game so loading images and sounds later is not really an option. I did take a screenie of what xcode has to say and if I m reading this correctly then it seems it may be an issue in the collision routine... ?





[attachment deleted by admin]
Apps published: 3

AlienMenace

I wonder it is related to the FOREACH with TYPE issue from this thread: http://www.glbasic.com/forum/index.php?topic=5967.0

My collision routine uses a few of these.
Apps published: 3

ampos

My game used to crash if I used ANIMCOLL with a NON-ANIM sprite vs ANIMATED sprite.
check my web and/or my blog :D
http://diniplay.blogspot.com (devblog)
http://www.ampostata.org
http://ampostata.blogspot.com
I own PC-Win, MacBook 13", iPhone 3G/3GS/4G and iPAC-WinCE

MrTAToad

I haven't known FOREACH to cause run-time problems.  Ampos's suggestion is possible though and would be a bug.

What version of GLB are you using?

Debugging your code with some sort of output should be your main priority, as is trying to reduce the program to the minimum - memory problems are the worst to fix as crashes will appear at different places every time code is changed.