5.3.1p1 crash on Andriod when loadlevel or loadlevelAysnc

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 :slight_smile: 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 :wink:

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!

1 Like

mark

hi TagScott, Did you solve this problem?