Home / Topic / 3.24c Problem

3.24c Problem

Viewing 15 posts - 1 through 15 (of 24 total)
  • pkay@twitch.com

    Alex – I’m not sure if this is a Kwik problem, a Corona problem or an iOS problem. Since the latest upgrade my builds work fine in the emulator but crash on the iPad – the page transition between 8 and 9 causes a crash on the iPad. Is there any way you can take a look at either the entire app or the relevant pages and point me in the right direction? I’m thisclose to launching the app…



    I would suggest you to connect your iPad to Xcode by cable and run the Organizer option (then select the console option). Clean up the Organizer view and run your app in the iPad. All errors will show up there.

    I have sent already another similar situation to Corona Labs (they are evaluating it now) as, it seems, there are some issues with disposing memory. As soon as they reply me, I will update the code (if necessary) and release a new build.


    Hi Alex!
    This sounds like the same issue I am having. I sent a note in the roadmap forum with some feedback I received from Corona in regards to disposing of the audio. I am wondering if it is also an image disposal issue as well.

    FYI – I did some comparison of my TexMem in the terminal from the app built in Kwik2 vs. Kwik3.
    In the Kwik2 build my TexMem fluctuated and never exceeded 20. In the Kwik3 build it starts at 31 and just continues to go up from there. It never goes back down after a scene change. By page 6 the TexMem shows 375 in the terminal which I assume is why it is crashing on my older iPad2 device. Let me know if there is any other data I can give you to help resolve!
    Thanks so much!


    I have tested every version of 3.2.4 from 4a thru 4c and they all have the texture memory disposal problem. Alex worked to correct this as recently as June and it was corrected, but I guess it didn’t stick. 3.2.4 does not have the problem, but is unusable, for me at least, because it crashes on exporting images (a problem none of the other later versions have).


    Here is the console logfile from start til crash


    Are you all navigating with the auto swipe or using a button with GoTo Page interaction?


    GoTo page. I disbled autoswipe.


    GoTo via buttons and the menu navigation.


    I sent you all an email with instructions on how to re-test it. Please take a look and let me know the results. If they work, I will create a new public build tomorrow.


    As I responded, I tested this and found that the memory is now disposing properly when I advance the pages via the goto button, but not when I use another goto button and/or menu navigation to go back to previous pages (ie from page 4 to 3 or page 6 to 2).


    I had the same results as well Alex. The update you sent fixed the disposal issue for the GoTo Next(auto) but not the Previous(auto) or when I chose to Go to a specific page.
    Thanks for working so hard on getting it fixed!


    I am still waiting from Corona’s help on how to handle the issue with memory disposal. Unfortunately no news at this moment. Can you please let me know, meanwhile, if you see crashes on your device going backwards or via navigation menu?


    I am using buttons to move forward and one button at the end to return to the beginning. Everything is working as expected.


    Hi Alex! Only one crash on the device. (yeah!) and it looks like it is more with the Nav menu and only after quite a bit of use. The back button seems to be okay.


    Hi, i found this same problem with texture memory and I think I found a solution:
    In the go to scene logic I commented the removeScene call because I found out it was running twice, once in the go to scene and once entering the new scene.
    Like this:

    local myClosure_switch76 = function()
    local options = { effect = “fade” }
    — if nil~= composer.getScene(“page_2”) then composer.removeScene(“page_2”, true) end
    if self.type == “press” then
    — composer.removeScene( “page_1”, true )
    self:removeEventListener( “tap”, onLayer_6Event )
    — composer.removeScene( “page_1”, true )
    composer.gotoScene( “page_2”, options )
    composer.timerStash.newTimer_276 = timer.performWithDelay(0, myClosure_switch76, 1)

    With this changes the memory stopped going up on each new page.
    Also I don’t know why the composer.removeScene is both in the “if” and in the “else”, it looks completely superfluous.

Viewing 15 posts - 1 through 15 (of 24 total)

You must be logged in to reply to this topic.

Privacy Preference Center

Strictly Necessary

these coolies are for WP-SpamShield, gdpr-wp, woocommerce, paypal

PHPSESSID, SJECT16, JCS_INENREF, JCS_INENTIM, gdpr, woocommerce_cart_hash, woocommerce_items_in_cart, woocommerce_recently_viewed, wordpress_, wordpress_logged_in_, wordpress_sec_, wordpress_test_cookie, wp_woocommerce_session_, AKDC, akavpau_ppsd


WordPress cookie created when auto-saving a post in the editor.

wp-saving-post, wp-settings-, wp-settings-time-


google analytic