Howdy, Stranger!


Xcode Runtime eventually crashes

edited January 2014 in Bugs Posts: 53

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


  • Posts: 1,255

    Are you sure there are no print() statements?

  • Posts: 2,820

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

  • Posts: 53

    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
  • Posts: 53

    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
  • Posts: 53

    (Oh, no native functions, btw)

  • Posts: 2,820

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

  • Posts: 53

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

  • Jmv38Jmv38 Mod
    Posts: 3,295

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

  • Posts: 2,820

    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.)

  • Posts: 398

    @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'. ;-)

  • Posts: 1,255

    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 .

  • Posts: 53

    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

  • Posts: 2,820

    @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:
    Hope that helps! Sorry I can't really help. Also, good luck on the competition.

  • Jmv38Jmv38 Mod
    edited January 2014 Posts: 3,295

    @Mark you say:


    Can you comment a bit more on what is happening?

  • Posts: 1,976

    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

  • Posts: 116

    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.

  • Posts: 152

    @Neztec Might be worth taking a look at in terms of garbage collection pointers...


  • Posts: 53

    @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).

  • Posts: 1,595

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

  • Posts: 1,976

    @Luatee Isn't close designed only for Codea, to exit back to the editor when in FULLSCREEN_NO_BUTTONS? I don't think there even is a way for an app to close itself, not even in Objective-C.

  • Posts: 1,255

    @SkyTheCoder is right. There's no exit from an app short of user action to leave (home btn, or through notice selection, etc)

    Question for other Codea/XCode users: is there a way to get failures in the Lua code to fail outside the runtime? It's a rare event, but it's confusing to the users when the app fails and dumps them to the error message inside the runtime.

  • Posts: 2,820

    @SkyTheCoder - You are actually (probably) incorrect. As of about at least 2 years ago, there was a way to manually close the app, but that might've been deprecated. I'll have to look into it, though.
    @Mark - That's on my todo list for StackIt: Pretty much notify the user there was an error instead and restart the app, then report it to me over the web. If anything you might try inserting code into the event in the runtime controller file called "didChangeViewMode" and see if the Codea frame is paused. If so, then there was probably an error. Sadly, I haven't looked into it yet.

Sign In or Register to comment.