We fixed this crash , just avoid to call Resources.load while the async scene load operation is executing.
check all Resources.load and make sure they are safety
@shongbee2 it may be a bit difficult to ensure that the Resources.Load call is not used during the scene loading.
@superpig do you know if converting our Resources calls into local AssetBundle load calls should also fix this ?
I believe AssetBundle loads would not have the same problem, yeah.
IEnumerator Start()
{
MySceneManager.IsLoading = true;
AsyncOperation op = UnityEngine.SceneManagement.SceneManager.LoadSceneAsync(sceneName, UnityEngine.SceneManagement.LoadSceneMode.Single);
while (op.isDone == false)
{
yield return null;
}
MySceneManager.IsLoading = false;
}
public T MyLoad<T>(string resPath) where T : Object
{
if(MySceneManager.IsLoading)
{
Debug.LogError("the scene is loading, will crash. " + resPath);
}
return Resources.Load<T>(resPath);
}
call MyLoad function can check loading…,
@liortal
The problem also happens when I invoke WWW.LoadFromCacheOrDownload to load assetbundle from cache. Is it concerned with some automatic Unload Resource processes?
We have the same problem: SIGSEGV when scene is loaded:
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
r0 00000000 r1 00000400 r2 000003ff r3 cc576410
r4 00000000 r5 00000015 r6 00000400 r7 00000015
r8 0000056c r9 f3b48010 sl d712f6c4 fp 00000a6a
ip dbc7e0c0 sp d712f680 lr df0884f4 pc df0884f4 cpsr 80070010
d0 3636663238623038 d1 6330613634363533
d2 3438373430383237 d3 6564613461386537
d4 0065353533396436 d5 0000000000000000
d6 0000000000000000 d7 3566310000000000
d8 0000000000000000 d9 0000000000000000
d10 0000000000000000 d11 0000000000000000
d12 0000000000000000 d13 0000000000000000
d14 0000000000000000 d15 0000000000000000
d16 0000000000000000 d17 0000000000000000
d18 0000001400000056 d19 00000000ffff0100
d20 0000000000000000 d21 0000000000000000
d22 00000000ffffffff d23 6c0789666c078966
d24 4014000000000000 d25 0000000000000000
d26 3f80000000000000 d27 4024000000000000
d28 3ff0000000000000 d29 4014000000000000
d30 3ff0000000000000 d31 4024000000000000
scr 2000001b
backtrace:
#00 pc 007264f4 /data/app/com.######.######-1/lib/arm/libunity.so (_ZN17PersistentManager23PostLoadStreamNameSpaceER15StreamNameSpacei+324)
#01 pc 00725f78 /data/app/com.######.######-1/lib/arm/libunity.so (_ZN17PersistentManager26GetStreamNameSpaceInternalEi+988)
#02 pc 0072006c /data/app/com.######.######-1/lib/arm/libunity.so (_ZN17PersistentManager27GetLoadErrorMessageFromPathERKSs+56)
#03 pc 004f0558 /data/app/com.######.######-1/lib/arm/libunity.so (_ZN18LoadSceneOperation7PerformEv+516)
#04 pc 004f30a0 /data/app/com.######.######-1/lib/arm/libunity.so (_ZN14PreloadManager22ProcessSingleOperationEv+156)
#05 pc 004f2d44 /data/app/com.######.######-1/lib/arm/libunity.so (_ZN14PreloadManager3RunEv+36)
#06 pc 004f2d04 /data/app/com.######.######-1/lib/arm/libunity.so (_ZN14PreloadManager3RunEPv+40)
#07 pc 00588ab0 /data/app/com.######.######-1/lib/arm/libunity.so (_ZN6Thread16RunThreadWrapperEPv+84)
#08 pc 0004025b /system/lib/libc.so (_ZL15__pthread_startPv+30)
#09 pc 0001a095 /system/lib/libc.so (__start_thread+6)
The problem is we do not use async loading of the scene, however we do use Resources.Load a lot.
The crash happens randomly: it could be on the 6th scene being loaded, or the 2nd one.
It happens on near high-end device with 3GB of RAM, so it’s not the culprit.
UPD. We’re using v.5.5.1f1
Any help? Thanks in advance.
@dotsquid we are loading some scenes async, as well as using Resources.Load.
After the suggestion here, i converted all the Resources.Load calls (that occur while loading a scene) to use other mechanisms. So far, we haven’t received any crashes (in QA) after this fix.
@liortal
Thanks for reply.
Share your knowledge, master
What mechanism are you using now instead of Resources.Load?
It seems we found the reason of the crash in our game.
The crash happened when the AudioClips were loaded. We tried to find out which exactly types of audios caused the problem (load type, compression format, duration, sample rate etc), but we have too much audios to check all the combinations.
Now I understand that it wasn’t a good idea, but before now we’ve been loading our audios with Resources.Load just after SceneManager.LoadScene. Now we are using SceneManager.sceneLoaded event to load these resources. No single crash yet!
I hope this information will help Unity team improve the engine, as I believe that, despite it’s for sure not a good idea to load resources this way, it’s not a reason for engine to crash ![]()
what’s your mechanisms? Can you share it?
Yes, i created a wrapper class around Resources (ResourcesEx). This class simply adds logging around calls to Resources.Load calls.
Then, i loaded up our game, and observed which resources are being loaded during async scene loading operations.
After that, i convert each of these Resource.Load calls to use other stuff (ScriptableObjects, hook them via the inspector, etc).
I can dig up the ResourcesEx class i created and attach it here, in case if helps anyone.
Thanks for the reply.
Fortunately, we’ve managed to find out the root of the problem.
@dotsquid I’m experiencing the same problem. Do you mind telling us who was the culprit in your case?
Thanks!
mark
hi TagScott, Did you solve this problem?