Xcode Runtime eventually crashes

Hey all,

Hoping someone can help me with this issue. I’m submitting my game to the Pax East Indie Showcase today and it’s ready except for one critical issue. When I export the game to the Xcode Runtime and make a release it runs okay but slowly bogs down (over like 3 to 5 minutes) and then crashes. Feels like a memory leak or something… but in Codea my game has no problem at all.

Makes me think the Runtime has an issue - am I right to think that? Anything I can do to improve the performance / fix the issue?

I was told recently the Codea Runtime has some issues with iOS 7 still, is that the issue? The only other thing I can think of in my app is the use of one mesh.

Any help is greatly appreciated.

  • Mike

Are you sure there are no print() statements?

Can you send us the crash? Do you have any native Obj-C functions?

Mark - good idea, but I only print out once at the beginning (though it is a bit large - I’ll try getting rid of it).

Zoyt - how can I capture the crash from the device? (the game runs way too slowly on the simulator - never waited long enough to see it happen there). I’ll see if that happens on the simulator too.

  • Mike

New info: I’ve been watching the memory report and it gobbles up 2 MB of memory every second constantly. I walked around the application and it only happens on pages that use the physics engine (even if there are no objects) - any ideas?

  • Mike

(Oh, no native functions, btw)

Wow. That’s odd. When I have extra time tonight, I might be able to think of reasons.

Ooop, I was slightly off - 0.2 MB per second… still, it runs out of memory pretty fast.

@Neztec do you know about collectgarbage() function? Try to use is regularly and check if it changes something.

I was going to say, 20 MB is a bit crazy. It’s kind of hard to find an issue with your eyes blindfolded, so there’s not much I can do, sadly. Not to mention there’s not much you can do if it’s a Codea runtime issue. Can you tell me what technologies you’re using (meshes, shaders, etc.)

@Neztec have you tried using the Memory diagnostic tools in Instruments within Xcode? Build and deploy it to the target device (instead of the Simulator) and track its progress in Instruments. it might give you some extra clues while its running ‘live’. :wink:

The other thing I would look for right away is creation of any substatial objects within the draw() routine, particularly tables. Creating tables or complex objects inside of draw stands a good chance of outrunning the garbage collector’s ability to squash them unless you take active measures.

I’d also say check for recursive method calls in objects, but that usually eats the memory so quickly it leaves little doubt about the cause.

Oh, and one more: what are you doing about saving data? If you’re updating local data frequently with current status that can also turn into a problem .

Zoyt - no shades, one mesh that only appears when a user makes an active move (probably not involved in this issue). I use clipping a decent amount of the time. Lots and lots of images. Some tinting occasionally. Uh, I draw ellipses some of the time (which I know is expensive). Thanks.

Andy - I haven’t tried that yet, but I will next! Thanks.

Mark - Oh my, yes I do lots of creation in the draw method. In other words I don’t do much in the setup method. But usually it’s I build a level, etc, and then I’m done with creation for a long while until. In the memory consumption I’m seeing the app is just sitting idle - almost no creation happening at all. Still, I’m tempted to throw down some manual garbage collection now - when is the best time to do so? Post drawing?

Thanks everyone!

  • Mike

@Neztec - I was having some crashes in StackIt too, until I found a place online where they suggested a better garbage collection method in C, so I wrote a Codea add-on. Find it as the garbage collection one here: http://twolivesleft.com/Codea/Talk/discussion/4221/objective-c-libraries%3A-testflight-gamecenter-location-twitter-facebook-camera-roll-sharing-more#Item_9
Hope that helps! Sorry I can’t really help. Also, good luck on the competition.

@Mark you say:

Creating tables or complex objects inside of draw stands a good chance of outrunning the garbage collector’s ability to squash them unless you take active measures.

Can you comment a bit more on what is happening?

How can you use the physics engine if there are no objects?

Also, the iOS simulator is much slower than on real iOS. The default project runs at about 30 FPS rather than 60 FPS.

@Zoyt Side note: He said 2 MB, not 20 MB

I would guess its not destroying tables properly too and most likely inside the draw function.

During testing I was having a crash after a few levels and I relized my table would have times added but never removed.

I started using a technique like this to resolve it:

        bs = {} -- temp table

        mybullets = 0
        for a,b in pairs(bullets) do
            if b.age < b.lifespan then
                mybullets = mybullets + 1
        bullets = bs -- replace bullets table
        bs = {} -- make sure you destroy it.

To an advanced Lua program I am sure this is just the way you do it…

but really I would need to look at your code to help. as would anyone. we are all guessing what it could be… and without looking we don’t really know.

I would guess its not the engine but an oversight in programming.

@Neztec Might be worth taking a look at http://twolivesleft.com/Codea/Talk/discussion/comment/36303 in terms of garbage collection pointers…


@SkyTheCoder - the physics “engine” is always running, it’s just a matter of whether you have objects in it or not. Well I guess you could physics.pause() - but I’m not doing that… I wonder if that would help?

@brookesi - That is a useful discussion - thanks.

I’ve been trying to isolate the exact drain. When I comment out my drawing code the memory drain slows to a crawl, which is interesting. One block that was hurting it a lot was when I created a bunch of local variables to set things up neatly in a draw method - surprisingly that was hurting it more than helping. When I refactored them away there was less memory drain (though some still).

This is a it off topic but relates to Xcode. Why does the close() function not close an exported app?