The weird iOS8 + Unity3D hiccup

With which version of Unity?

 

4.6.2 at the moment. Someone here mentioned they had the same problem in Unity 5 beta as well.

 

Might this have something to do with Box2D then? Also would explain why Crossy Road doesn't have this problem.

 

I noticed this hickup problem too since the first time i ran my game on the iPad 3 ( iOS 8.1). Funny enough that it does'nt appear on the old iPod 3rd Gen with iOS5.1.1 ( of course game runs generally more sluggish there ). I will investigate today wether it's indeed this watchdog intervention in my case
Find it pretty awkward that there should'nt be a workarround for this - or is there ?

 

Do you have any new info? You can't just sit and wait for apple to fix this right?

 

I for one don't understand what Apple are expected to fix here? It's common for new iOS generations/limitations to effect previously working apps and the apps should perform the necessary changes to comply. Just like we are forced to submit 64bit supported apps now.
If I were developing my game without a 3rd party platform and it suddenly started getting these error reports I would investigate why I have so many thread wakeups and work to reduce them, not file a bug to Apple.

150 thread wakeups per second (average over a long period) seems like a reasonable requirement but maybe I am missing something. Why would a game running at 60 FPS need much more than 60 wakeups? With Unity i get cases of over 300.

Maybe someone can explain where/when these thread breaks are coming from in Unity so we can understand what's going on.

 

Today I got message from Apple that it might be fixed in iOS 8.3 beta 1.
Could you please test it on your projects and let us know?
Thanks

 

iOS 8.3 beta 1 fixed it for me.

 

I can confirm that the iOS 8.3 beta 1 fixed the issue for us as well. Unfortunately we'll have to wait a few months more before the new iOS version is live, since 8.2 is still in beta as well.

There must really be a solution to get around this before that?

 

Maybe Apple can send a solution to Unity Devs?

 

Thank you for all the confirmations!

P.S. we have asked Apple for workarounds, but haven't received any yet.

 

Try removing support for any controller you are supporting in your game. They do a constant request check and hence visible spikes can be seen in the profiler.

PS: Guys, I am not able to access my actual account, some problem from unity's forum software. Hence I created a new account to answer here.

 

Can you send an e-mail to support@unity3d.com

 

Me? About?

 

not you @marcus.qiiwi , @NextGeneration about his account issue.

 

I found a sort of workaround for this issue (for the hiccup, not the exception report). It seems like:
- The exception report is generated only once per process (even if your app goes to background and returns later). So once it's generated it will not be generated anymore until your app is relaunched from scratch.
- The exception is for 150 wakeups per second over 300 seconds, but if the process reaches 150x300 wakeups earlier then the exception is generated.

So, the workaround is basically to force the exception report to be generated as soon as the app starts, in which case the hiccup would most likely not affect any gameplay as it would happen during the splash/loading/main-menu screen.

The drawback is that the crash report is generated every single time your app starts, but at least for me it's always generated anyway a few minutes into playing so it's not that much of a difference.
Also, the report is more severe, it says for example 'Observed 22557/sec over 300 secs', compared to the typical few hundred per second (Though the report is wrong, it observed that over a few seconds and not over 300, so I hope it wouldn't cause any rejections).

This is the function which generates the wakeups (I used 200x300 instead of 150x300 just in case it may miss some)

Code (CSharp):

1. -(void) ExcResourceGenerate
2. {
3.     struct timespec tim, tim2;
4.  
5.     NSLog(@"ExcResource Generate Start");
6.  
7.     tim.tv_sec = 0;
8.     tim.tv_nsec = 1000;
9.  
10.     for(int i=0;i<(200*300);i++)
11.     {
12.         nanosleep(&tim,&tim2);
13.     }
14.  
15.     NSLog(@"ExcResource Generate End");
16.  
17. }

I put it in UnityAppController.mm and triggered it like this from 'didFinishLaunchingWithOptions' (At the end, but maybe beginning is better):

Code (CSharp):

1. [self performSelectorInBackground:@selector(ExcResourceGenerate) withObject:nil];

On iphone 6+ it finishes pretty quickly, sometimes even during the unity splash screen. Probably it should only be called if it's IOS8 and less than 8.3 that way you don't need to update the app when 8.3 comes out.

 

Now that 8.3 is officially out. Can anyone confirm that it is indeed fixed for anytone that had this issue?

 

Fixed for me in 8.3

 

Still seeing this in 8.3. Seems to happen during a lot of File I/O. It also seems to cause a crash on low memory devices like iPad2, where when the crash reporter spawns, even though the app is only using 170MB of memory on the device, iOS kills the app due to out of memory.

 

I'm seeing it on 8.3 also. iPhone 5s

 

According to Apple reports will still be generated, but they should not interfere with your app and should not cause hiccups.

 

That makes sense as I didn't notice a hiccup but it was on a different device so I wasn't sure.

 

Hi guys, any news about this? I still have this huge problem using the latest 4.6.7p1. My App reports an average of 80 crashes per day...We need to fix this.

 

It's not a crash, but an exception report. You can ignore them.

 

We have recently encountered this problem in our game (Unity 4.6.7f1 deploying to an iPad Air 2 running iOS 8.4).

We get the "EXC_RESOURCE, WAKEUPS" crash dumps (with the message about "(Limit 150/sec) Observed 269/sec over 300 secs"), which cause noticeable stutter (hiccups), followed by a hang or crash.

Normally, we will encounter a stutter or two, followed by a complete hang in the application. Although when the hang occurs, the music continues to play and both the Xcode and Unity profilers show everything continuing as normal. Very occasionally, we get a "hard crash" which throws the iPad back to the Apple logo screen.

If it were just a stutter, we could probably live with that, however we are experiencing crashes which appear to be caused by this issue.

Do we have any information as to what part of Unity is causing these crashes (i.e. what can we do to remove or at least mitigate this problem until a proper solution is found?).

EDIT : We've upgraded to Unity 5.1.2f1 and the issue still persists.

 

Last night I performed a soak test (>8 hours) and the game ran without problems for that entire time. However, as soon as I started to interact with it (i.e. panning our camera around the scene) within minutes the stalls and then freeze occurred.

Could this issue be related to input polling? Or perhaps something to do with culling or swapping objects in/out as I pan around my scene? (our game is a 3d isometric strategy/builder type game, by the way).

Googling the issue, I can see that this is definitely NOT isolated to just Unity apps - it is very much an iOS8 problem.

However it would be helpful if we could understand the problem from a Unity point of view and attempt to work around it until Apple produce a proper fix.

 

A strange one, but after much trial-and-error we have found that removing all but one of our dynamic lights (the remaining one being the main directional light) seems to prevent the crash. Adding even two dynamic lights back in causes the crash to reappear.

I think this is just masking the underlying issue, though. And obviously, we'd like to have some dynamic lights in our game.

Can anyone from Unity explain what exactly is going on underneath that is causing this problem?

 

At the moment we are not aware about similar issues. Please submit a bugreport with a repro scene.
Thanks!

 

I get the same error on two iOS 8 devices. iOS 9 runs fine.

Get it on my third scene load, while it loads, the app just closes, with this:
Exception Type: EXC_RESOURCE

Exception Subtype: WAKEUPS
Exception Message: (Limit 150/sec) Observed 522/sec over 300 secs
Triggered by Thread: 0

We where just about to release...when Xcode autoupdated (I have disabled auto updating on OSX now (facepalm!)...then update to Unity5.2 were needed....(insert a lot of other stupid fixes to make the game build and deploy to device)....bum hell broke loose

 

I have now read through this entire thread and can see people are experiencing this on various Xcode versions and various Unity versions etc.

The funny thing is that we didn't see this problem until Xcode 7.0.1 (iOS 9) and Unity3d 5.2 got on my machine. The iPhone 4s we are testing on haven't been updated in a long time so no changes there. But still we got this...

Still no ones have a clue?


It doesn't really help anything, but I have trial/error my way down to figure out what causes this.
Before I get there. We don't se shutter, we see a app the closes on iOS 8 every time. No random. Same place every time. It is when a certain scene is loaded.

So I started pulling out game objects one by one. The game wasn't playable at all, but I just wanted to see what I needed to remove to make the scene load.

It turned out that it was to public GameObject fields on a mono behavior....!!!

These two both hold a ref for its own prefab and it wasn't even the use of these fields that made it crash. It was just the declaration of them and then having a value assigned from dragging the prefabs on it in the editor.

I'm pluzzes now!

 

@Leumania, this is not an Unity issue, it's an iOS issue. The issue didn't happen on iOS 6 and earlier.
Since iOS 7 Apple enforced strict app limits, including how much RAM an app can use, hence many apps started crashing more often, especially on devices with 512 MB RAM like iPhone 4S.

 

Thanks @Revolter

It's not that I don't believe you, but I think many more devs would have raised and experienced this problem, if it happened on all "older" devices.

After posting last time, I tried some more stuff.

Some were sugesting that this was "fixed" on ios 8.3+. So I updated the iPhone 4s and the iPad 2, as the game failed/closed the exact same place on both of them.

After upgrading to iOS 9.0, it worked on the iPad 2 and had same problem on iPhone 4s.
And it is not like the iPad 2 got more RAM or power, just by upgrading the iOS

And if it were a RAM issue I guess it would help to remove gameobjects from the scene that causes the problems. But it didn't. I stripped it down to one gameobject, and by trial and error, I found out that uncommenting public Gameobject SomethingPrefab; it worked.

The fields didn't even needed to have a dragged in value from the editor. Just by them being there, made the game crash.

So it is really odd.

 

A little more update.

I found out yesterday, that when the game "closes" on the iPad2, it gets fixed by restarting/rebooting the ipad.
Then it works again.

Very wierd :S

 

Ok, I got my problem fixed.

In my case, it was resolved by setting as many Sprites/Textures to "Compressed" as possible - by possible I mean without any major impact on the graphics quality.

I'm doing a 2D game in NGUI, and have therefore had almost all my sprites/textures/atlases set to Truecolor to make the game look nice and sharp - and it does.

Apparently, this is just more than an iPad 2 or iPhone 4s can handle. I guess it's to "hard" for it to load, so it try to do some magic and switches thread etc...which in the end makes iOS close the app, due to the "Too many wakeup calls" error.

My game now runs fine on all the devices we have tested on - with minimal impact on the graphics.

Nice to have it fixed, irritating the error wasn't more clear to I could have fixed it sooner.