NSTimer in RoboPlatform.willTerminate never fires

14 views
Skip to first unread message

Guillermo Rodriguez Garcia

unread,
Mar 18, 2019, 2:54:53 PM3/18/19
to PlayN
Hi all,

I was debugging a memory leak in my application and came across this code in RoboPlatform:

  void willTerminate () {
    // shutdown the GL and AL systems after our configured delay
    new NSTimer(config.timeForTermination, new VoidBlock1<NSTimer>() {
      public void invoke (NSTimer timer) {
        // shutdown the GL view completely
        EAGLContext.setCurrentContext(null);
        // stop and release the AL resources (if audio was ever initialized)
        if (audio != null) audio.terminate();
      }
    }, null, false);
    // let the app know that we're terminating
    dispatchEvent(lifecycle, Lifecycle.EXIT);
  }

Looks like that NSTimer will never fire. That constructor ends up calling the native timerWithTimeInterval:target:selector:userInfo:repeats: method. According to the API docs (https://developer.apple.com/documentation/foundation/nstimer/1408356-timerwithtimeinterval?language=objc), this creates the timer, but does not start it (it states that the timer must be added to a run loop).

Perhaps the idea here was to use the NSTimer constructor which takes an additional boolean ("scheduled") ? When scheduled == true, this will end up calling scheduledTimerWithTimeInterval:target:selector:userInfo:repeats: instead, which is just like timerWithTimeInterval.. but also "schedules it on the current run loop in the default mode."

Not 100% sure whether this was the intention but I can confirm that with the current code, the timer does not fire.

Guillermo

Guillermo Rodriguez Garcia

unread,
Mar 18, 2019, 3:02:42 PM3/18/19
to PlayN
While we're at this, I have a question about this: Why is a delay needed before clearing the EAGLContext?

If I am correct, this (RoboPlatform.willTerminate) is only called from RoboViewController.doDispose(). Which in turn is only called when the RoboViewController instance is disposed.
Thus there's no GL view anymore, so why is the delay needed?

Also: RoboViewControlller.viewDidDisappear already calls EAGLContext.setCurrentContext(null). So perhaps doing that again in RoboPlatform.willTerminate is redundant?

Guillermo

Michael Bayne

unread,
Mar 18, 2019, 5:57:37 PM3/18/19
to pl...@googlegroups.com
The code in question dates back from the original port from libGDX's RoboVM support, so it was perhaps needed back then and then things evolved substantially since then and now it's no longer needed. As you say, the GL context has already been cleared and RoboAudio doesn't actually do anything in terminate(), so that's probably not needed.

The RoboPlatform.willTerminate call is still needed because that dispatches the EXIT event on the Platform lifecycle, but the code to schedule a timer can go. I'll remove it.

--

---
You received this message because you are subscribed to the Google Groups "PlayN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playn+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--

Guillermo Rodriguez Garcia

unread,
Mar 19, 2019, 4:19:12 AM3/19/19
to PlayN
On Monday, March 18, 2019 at 10:57:37 PM UTC+1, Michael Bayne wrote:
The code in question dates back from the original port from libGDX's RoboVM support, so it was perhaps needed back then and then things evolved substantially since then and now it's no longer needed. As you say, the GL context has already been cleared and RoboAudio doesn't actually do anything in terminate(), so that's probably not needed.

The RoboPlatform.willTerminate call is still needed because that dispatches the EXIT event on the Platform lifecycle, but the code to schedule a timer can go. I'll remove it.

Even better :-)

Guillermo

Guillermo Rodriguez Garcia

unread,
Mar 19, 2019, 1:25:18 PM3/19/19
to PlayN
Hi Michael,

I took the liberty of submitting another PR that completely removes the timer. Now that the timer actually does something, it may interfere with the app as it clears the GL context (again) after an arbitrary delay once the PlayN view is no longer active.

BR,

Guillermo
Reply all
Reply to author
Forward
0 new messages