Crash on iPhone X (too many wakeups)

My app is ready, but I get these crashes on new iPhones. This only happens with release build. I hope someone can help me out.

Crash log says: “Wakeups: 45001 wakeups over the last 57 seconds (792 wakeups per second average), exceeding limit of 150 wakeups per second over 300 seconds”

You can see the full crashlog here:

Before the crash console says:
error 09:15:15.736992 +0200 backboardd ImageQueueCollectable client message err=0x10000003
error 09:15:15.743294 +0200 SpringBoard HW kbd: Failed to set (null) as keyboard focus
error 09:15:15.754003 +0200 SpringBoard Unable to get short BSD proc info for 938: No such process
error 09:15:15.771541 +0200 symptomsd Can’t get most elevated app state from dictionary {
BKSApplicationStateExtensionKey = 0;
SBApplicationStateDisplayIDKey = “com.headai.oodi”;
SBApplicationStateKey = 0;
SBApplicationStateProcessIDKey = 938;
SBApplicationStateRunningReasonsKey = (
SBApplicationStateRunningReasonAssertionIdentifierKey = Resume;
SBApplicationStateRunningReasonAssertionReasonKey = 10000;

I’m testing with iPhone X iOS 12.1, I got all the latest codes for Fuse and Uno.

Don’t know what to do :frowning:

What happens when you run a plain vanilla app?

Have you tried to isolate the offending piece of code by stripping your app and reassembling it section by section?

If you’ve used Storage, it could be this bug I found: A workaround is to check if a file exists beforehand.

Thanks for the suggestions. I’ve been trying to narrow this down for two weeks now. It feels random and therefor really hard to catch.

This is what XCode looks like when my release build dies:


It can happen in different scenarios, but death always looks the same.

So its something in your JavaScript that’s breaking, which could be a module breaking.

Like I said, try removing section by section until your app works. I started with removing batches of UX pages, until I found which one was breaking, then I removed JS lines of code in batches too, until I found the offending line.

Process of elimination never fails haha.

Not sure what causes this, but a thing you could try is to add a Uno.Threading.Thread.Sleep(1) here:

If that helps, that’s a clue that something in JS is triggering an infinite callback loop (e.g. setTimeout(…,0) recursively forever). iOS probably doesn’t like that in the long run

Thanks guys for the debugging tips. I finally managed to turn it into stable. I cannot point out one thing that I did wrong. I guess there was several. But here are some:

I’ve been using the following routine to share global Observables with different components.

  1. I have a Foobar.js file that contains some Observable = Observable();
  2. I can change this by
    var Foobar = require(“js/Foobar.js”); = “something”;
  3. and read the value inside a component where needed:
    var Observable = require(“FuseJS/Observable”);
    module.exports.Foobar= require(“js/Foobar.js”);
    <Text Value="{}"

It felt like this wasn’t very stable way of doing things so I’m injecting all variables from outside of components.

I also found some cases in my code where I was using Observable that was created outside of my component and it for some reason was working just fine. (until it wasn’t in Release build I guess)

These might be cases that are ok and I’m just being paranoid here.

One clear case though was the following:
I’m making all the server calls through my ServerHandler.js and there I was trying to check if user has Internet connection by:

  if(timeout != null)
      timeout = null;
  fetch(url, {
          method: 'HEAD'
      }).then(function(response) {
              module.exports.NoInternetConnection.value = false;
        }).catch(function(err) {
              module.exports.NoInternetConnection.value = true;
              timeout = setTimeout(function() {
                  module.exports.SendToServer(data, callback, error);
              }, 3000);

This turned out to be a source of error in iOS release build.

I also set the Deployment Target to 10.0 because it felt good at some point.

I feel like I didn’t learn much from this debugging, but I’m glad it works now.

P.S. If you ever need to debug iOS Release Builds go to Edit Scheme… and switch Build Configuration from Debug to Release and start adding a lot of console.log() lines all over your project. The actual error messages didn’t tell anything useful (at least in my case.)

1 Like