Hi there
We have an app, built for 64bits with IL2CPP for iOS with Fabric (formerly called Crashlytics) and we are receiving some crashed on AppWillTerminate with all version of Unity (we started working on it on 4.6.3). It’s quite strange, because to it seems to happen once the app is killed from background by OS due to memory pressure
Do you know anything about this? It’s quite weird
Regards
Here is the raw of the crash
Thread : Crashed: com.apple.main-threadCFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK + 12
We’ve not seen a crash like this before, from what I can gather. Is this something reproducible, or does it occur intermittently?
Thanks Josh for the time. Yes, it is reproducible if in debug, you start opening others app until WatchDog tries to close yours.
This crash is from our crash tracker tool, crashlytics.
In method “TutorialEvent_OnDestroy” we only desubscribe from an event, but this couldn’t be the error, this line is executed everytime we change scene.
very strange
Thanks for the information. Can you submit a bug report with a project that causes this crash? That will give us the best chance to correct it.
Mwumwu
June 19, 2015, 1:52am
5
Is there an update for this issue? We are having the exact same problem.
Well have you tried the lasted version of Unity to see if the problem still exists?
@Mwumwu
We’ve not yet corrected this issue, as we don’t have a bug report for it yet with a reproducible case. Can you submit a bug report and include a project that causes this? If so, we would love to have a look so that we can correct it. Thanks.
Looking at my crashes in XCode from my live app, I’m seeing a VERY similar crash stack in my app as well. I’ve been unable to repro it locally so far. Like the OP, this looks to be triggered by desubscribing to an event, but in my case, I’m desubscribing in OnDisable (not OnDestroy like the OP).
My app was built with Unity 4.6.6p1
Callabrator88:
Looking at my crashes in XCode from my live app, I’m seeing a VERY similar crash stack in my app as well. I’ve been unable to repro it locally so far. Like the OP, this looks to be triggered by desubscribing to an event, but in my case, I’m desubscribing in OnDisable (not OnDestroy like the OP).
My app was built with Unity 4.6.6p1
@Callabrator88
Thanks for the information. If you are able to reproduce it locally, please let us know, and we will investigate it.
Just to let you know, our latest game update built on 4.6.6p4 still have this issue. But no STR on our side either.
I have soft launched a game a few days ago, with about 100 users right now. We got 9 crashes, apparently from the same device / user, all apparently starting after the game is killed because of memory pressure.
8 of the crashes have a very similar stack, of an exception triggered during GameObject destroy that calls our Log Handler which then tries to allocate memory (and then fail) while reporting the issue to our server.
Thread 0 name:CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK + 16 (CFRunLoop.c:1638)
And here’s the remaining one again at cleanup time (OnDestroy → save → Json Serialization → allocation → crash )
Thread 0 name:CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK + 16 (CFRunLoop.c:1638)
App is IL2CPP built 4.6.5f1 based. Device exhibiting issue is running IOS 8.3.
I have soft launched a game a few days ago, with about 100 users right now. We got 9 crashes, apparently from the same device / user, all apparently starting after the game is killed because of memory pressure.
8 of the crashes have a very similar stack, of an exception triggered during GameObject destroy that calls our Log Handler which then tries to allocate memory (and then fail) while reporting the issue to our server.
And here’s the remaining one again at cleanup time (OnDestroy → save → Json Serialization → allocation → crash )
App is IL2CPP built 4.6.5f1 based. Device exhibiting issue is running IOS 8.3.
@jerome-lacoste
Do you know if it is possible that the app is close to the maximum memory available, and might actually be crashing because it runs out of memory?
@JoshPeterson the affected device is an ipad Air (A1474). It has double the amount of RAM as my test device (ipad2) and I have never managed to crash the app on the ipad2 in normal use.
I will try further with swapping the app out etc.
In all cases, it looks like I should be able to take some preventive measures by reducing the amount of work that happens during this shutdown phase. The OnApplicationQuit() seems to be sent too late (Unity - Manual: Order of execution for event functions ). Is there a way for me to programatically check that Unity is shutting down ? Maybe Application.isPlaying is false ?
@JoshPeterson the affected device is an ipad Air (A1474). It has double the amount of RAM as my test device (ipad2) and I have never managed to crash the app on the ipad2 in normal use.
I will try further with swapping the app out etc.
In all cases, it looks like I should be able to take some preventive measures by reducing the amount of work that happens during this shutdown phase. The OnApplicationQuit() seems to be sent too late (Unity - Manual: Order of execution for event functions ). Is there a way for me to programatically check that Unity is shutting down ? Maybe Application.isPlaying is false ?
@jerome-lacoste
That probably indicates it is not actually running out of memory so there is likely a bug somewhere here that we will need to track down. If you are able to get to this something that is reproducible (even intermittently), we would love to have a bug report on it.
The OnApplicationQuit event is usually the place to check, but since it is too late, you might be able to use the AppDomain.DomainUnload event. I’m unsure if that event is actually before or after OnApplicationQuit though. It might be worth a try at least.
@jerome-lacoste
It looks like OnApplicationPause (Unity - Scripting API: MonoBehaviour.OnApplicationPause(bool) ) might be a possibility as well, if you have not already tried it.
The first thing I noticed was the stack
UnityCleanup()
triggers object Destroy ?
something goes wrong, Exception triggered
Log Handler kicks in (the one from the Perf module)
because of its implementation, it allocates objects before starting the coroutine
crash (probably because memory constrained so allocation fail ?!)
I have been trying to create a reproducible case in the past few hours. I managed to create some oddities but no crash. Without knowing more of what’s happening inside the hood, I cannot turn thee symptoms as bugs to report yet.
I have 2 issues:
I didnt’ manage to get the UnityCleanup() call to be triggered upon memory pressure. At least I don’t know where to place my breakpoints in order to see it happening. If I put a breakpoint on a OnDestroy() somewhere, then if the app if killed while in the background or foreground because of memory pressure, calls to OnDestroy() don’t seem to happen. So my point #2 is maybe incorrectly understood:
28 Numbers 0x0000000100b6a3a8 Scripting::LogException(ScriptingException*, int, std::string const&) + 156 (Scripting.cpp:699)
What does the above stack mean ? Does this mean that the Destroy() method of a GameObject threw an exception ? Or is the exception coming internally form Unity ?
Any tip on how to trigger a UnityCleanup() call ?
The first thing I noticed was the stack
UnityCleanup()
triggers object Destroy ?
something goes wrong, Exception triggered
Log Handler kicks in (the one from the Perf module)
because of its implementation, it allocates objects before starting the coroutine
crash (probably because memory constrained so allocation fail ?!)
I have been trying to create a reproducible case in the past few hours. I managed to create some oddities but no crash. Without knowing more of what’s happening inside the hood, I cannot turn thee symptoms as bugs to report yet.
I have 2 issues:
I didnt’ manage to get the UnityCleanup() call to be triggered upon memory pressure. At least I don’t know where to place my breakpoints in order to see it happening. If I put a breakpoint on a OnDestroy() somewhere, then if the app if killed while in the background or foreground because of memory pressure, calls to OnDestroy() don’t seem to happen. So my point #2 is maybe incorrectly understood:
What does the above stack mean ? Does this mean that the Destroy() method of a GameObject threw an exception ? Or is the exception coming internally form Unity ?
Any tip on how to trigger a UnityCleanup() call ?
@jerome-lacoste
I’ve been talking with members of our iOS team about this as well, and we have a few suggestions.
First, you can call UnityCleanup directly from managed code if you want to do so to test something. It is exposed in UnityInterface.h.
The section of the stack trace you mentioned does indeed indicate the Destroy is throwing a managed exception, then the LogException call ends up calling LogCallbackImplementation, which in turn attempts to submit something via WWW. I wonder if you can track down the actual exception in Destroy by sending this user a version which does not submit via WWW, but instead writes something to disk that can be retrieved later.
Also, is there some chance that the user is manually killing the app? Or iOS team suggested that might be the cause.
@JoshPeterson
I’ll investigate some more, although travelling all day tomorrow, then partially in holidays.
Some thoughts:
I will try calling UnityCleanup
I will try killing the app manually
I don’t know who the user is, nor can I send a special build right now. The LogCallbackImplementation is yours
I will probably try modifying the UnityAppController.mm so that I can track the applicationWillTerminate() callback. That way I shut down the LogCallbackImplementation when this Unity is shutting down.
@JoshPeterson
I’ll investigate some more, although travelling all day tomorrow, then partially in holidays.
Some thoughts:
I will try calling UnityCleanup
I will try killing the app manually
I don’t know who the user is, nor can I send a special build right now. The LogCallbackImplementation is yours
I will probably try modifying the UnityAppController.mm so that I can track the applicationWillTerminate() callback. That way I shut down the LogCallbackImplementation when this Unity is shutting down.
@jerome-lacoste
Ahh, thanks, obviously I don’t know everything going on in the Unity code :).
I think your approach sounds good, please let me know what you determine, thanks!
Iamdain
October 30, 2015, 3:20am
20
Seemingly same issue here. On 4.6.9f1, Xcode 7, IL2PCC, happening on wide range of iOS devices, iPhone / iPad, 32 / 64 bit and OS versions 8.4-9.1.
Will investigate further soon but here’s trace:
1 libsystem_kernel.dylib __pthread_kill + 8CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION + 28
(the Perf service one).