Quick Links: Download Gideros Studio | Gideros Documentation | Gideros Development Center | Gideros community chat | DONATE
Reproducible crash under iOS — Gideros Forum

Reproducible crash under iOS

bowerandybowerandy Guru
edited February 2013 in Bugs and issues
Hi @atilim, I have a reproducible crash when testing my app in the player running on a real iOS device (iPad). A screendump of the stack trace is attached.

I say it is reproducible, which it is, but it occurs mid-way through a sequence of automated tests. It's about a couple of minutes into the tests so I can't really give you a short test case to reproduce it where you are. Is there anything that you can glean from the stack trace that might allow me to narrow down the problem and give you more info.

I think the issue is something to do with using a Timer to remove an object from the stage after a scene manager transition has completed. The Timer was initiated by the outgoing scene and the completion function holds back references to objects that are/were in that scene.

best regards

Comments

  • atilimatilim Maintainer
    Hi @bowerandy - This bug can be related to the previous Timer bug. From the stack trace, I can guess where the crashing occurs. Are you using coroutines in your tests?

  • @atilim, yes I am but I'm not using the wait() function you posted before. Instead I start an ENTER_FRAME listener and use this to monitor the current time elapsed. When it passes the wait value I resume the coroutine.

    This is working fine and I use it in several places. The test runner uses it and the app uses it for chaining tweens together. So far it has been very reliable.

    The current problem may be related but I can prevent it by commenting out a particular section of code that is nothing to do with coroutines.

    Basically, I have a new class called BhSceneLayer, which is a Sprite container that I can animate in parallel to the standard SceneManager scenes. This is so I can have several layers moving in different directions (not just the direction imposed by the Scene Manager).

    When the BhSceneLayer detects that a scene change is starting, it removes itself from its current parent and places itself in the stage. Then it start to monitor ENTER_FRAME events so it can animate in much the same way as the SceneManager does. It starts a Timer for the duration of the animation so that it can later put itself back into its original parent when the animation is complete.

    At this point I'm assuming that the original parent will be removed from the stage by the SceneManager and everything will get tidied up.

    If I comment out the bits where the BhSceneLayer is moved to the stage and back again, then the problem goes away. Needless to say, the process works 99% of the time but occasionally (as reproducibly) it fails in the same place.

    best regards

  • atilimatilim Maintainer
    edited February 2013
    @bowerandy I understand now. what happens if you collectgarbage() frequently with a code like:
    stage:addEventListener(Event.ENTER_FRAME, function() collectgarbage() end)
    ?

    So that, does crashing occur immediately or vanish?
  • @atilim, the crash still occurs with the constant garbage collection. It happens at the same time but the XCode stack trace is different. See below.

    best regards
    Screen Shot 2013-02-25 at 20.48.13.png
    1387 x 1066 - 313K
  • bowerandybowerandy Guru
    edited February 2013
    @atlim, the problem is nothing to do with Timers. I have moved the code that puts the object back in its original parent into the ENTER_FRAME handler that does the animation so that I can dispense with the timer. The crash still occurs.

    However, if I use the following as part of the ENTER_FRAME handler:
    	if t>=1 then
                    -- The transition has completed so tidy up
    		local event=Event.new("transitionEnd")
    		event.layer=self
    		self:dispatchEvent(event)
    		self:removeEventListener(Event.ENTER_FRAME, self.onEnterFrame, self)
     
    		if self.oldParent then
    			if not(self.isHiding) then
    				self.oldParent:addChild(self)
    			else
    				self:removeFromParent()
    			end
    			self.oldParent=nil
    		end
    	end
    Notice the test on self.isHiding. This returns true if the panel is hiding itself (i.e. it is in an exit transition). In this case it avoids replacing the panel into a possibly dead oldParent and, instead, just removes itself from the stage. Now the crash has gone!!

    So the problem is most likely to do with adding a Sprite back into another Sprite that has been removed from the stage and is only kept alive by that self.oldParent link.

    This is not quite a fix for me yet as I can't really use the .isHiding check. I will do some more experimenting to see if I can bypass the issue with what I now know.

    best regards
  • atilimatilim Maintainer
    edited February 2013
    @bowerandy I think I've fixed a bug related to garbage collection of coroutines. For example, when you register an event like:
    object:addEventListener("event", func, data)
    object holds a reference to func and data so that they won't be collected while object is alive. Now object also holds a reference to the thread (coroutine) where addEventListener is called. Therefore that thread won't be collected also.

    That fixed some weird behavior when events and coroutines together.

    I'll send you a development version so that can you check if crashing is solved or not?

    thank you.
  • bowerandybowerandy Guru
    edited February 2013
    @atilim, I have managed to isolate the difference in the test case that crashes. It is the only one where the arrival of a particular scene immediately triggers it's departure using changeScene(). This occurs as part of a coroutine switch inside an ENTER_FRAME handler in the test runner.

    I can stop the crash occurring by adding a 100ms delay to the test. Manually, trying to force the problem doesn't seem to cause it so I'm thinking is is some weird race condition with frame handlers and coroutines.

    I'm relatively happy (even though it's taken me a whole day to come to this conclusion) that I can live with the state of the system as it is, so you needn't pull your hair out over it.

    It might still be worth sending me the development version so I can check to see if your fix addresses the original problem (and hopefully, the coroutine timer problem I mentioned in the other thread too).

    thanks for your help

    best regards
Sign In or Register to comment.