Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Bug Crash when loading an addressable scene

Discussion in 'Addressables' started by ertugrulerdogan, Mar 30, 2022.

  1. ertugrulerdogan

    ertugrulerdogan

    Joined:
    Mar 26, 2015
    Posts:
    4
    Game crashes on iOS when loading a specific addressable scene.

    This issue emerged after upgrading project to 2020.3.12f1 -> 2021.2.17f1 and addressables to 1.16.15 -> 1.19.19.

    We try to eliminate any artifacts from previous versions which may cause unexpected bugs.
    Library folder and all addressable related assets deleted after upgrade. Then new addressable package imported and all addressable key created again.
    New addressable bundles created using default build script and uploaded to CDN with remote catalog.

    In the game log, file named 333227e62978c397cc45f0d99ba552b9 which can't be opened is an addressable bundle and only consists of a sprite atlas. Various sprites from that atlas are used in crashing addressable scene.

    I suspect this might be related to loading sprites from an addressable atlas.

    I submitted a bug report (case: 1415611) about this issue.
     

    Attached Files:

  2. ertugrulerdogan

    ertugrulerdogan

    Joined:
    Mar 26, 2015
    Posts:
    4
    We found the cause of this issue.

    It's a unique case which could cause random crashes after using Addressables.ClearDependencyCacheAsync() method.

    For creating this case 3 bundles are required.

    A remote, B default local group, C remote bundle.
    A uses B and B uses C.
    Basically A depends on B and C.

    Addressable play mode script must be set to 'use existing build' otherwise issue doesn’t happen in editor. (Also remote assets must be uploaded to CDN for using this mode)

    When ClearDependencyCacheAsync method is invoked for bundle A, a warning is logged with a message like (Couldn't release bundle something, bundle with xxx hash still in use). After that loading a new addressable could crash the app with memory allocation related reasons.

    It's challenging to detect or understand the cause of this issue on a project which uses thousands of addressable assets and tens of groups with different packing options and it starts to happen after upgrading the addressable package to the latest version. We didn't change any asset or code, only updated the editor version to the new LTS. This led to upgrade of addressable package and caused the crash. This issue may not be happening in older addressable versions. (For instance, it’s not happening in 1.16.15)

    Addressable doesn't log this exception on device even if the ADDRESSABLES_LOG_ALL symbol is defined. Only exception and warning shown in the editor when using 'use existing build' mode. It's hard to detect crashes caused by this issue in production.

    It's also challenging to detect the root cause of this issue. In our case, bundle A uses an asset in bundle B. Bundle B (default local group) has pack together option selected. Some material in bundle B uses a texture in bundle C. Completely unrelated assets dependencies caused this issue.

    However, this shouldn't happen in the first place. B is a local bundle and C is a remote bundle. Local bundles shouldn't depend on remote bundles. Yes theoretically it could, moving some local assets dependencies to remote could reduce build size but in our case it's unintentional.

    @davidla_unity @TreyK-47 It will be nice if addressables or asset bundles internally suppress this exception and don't crash the app. I think this issue could be the reason for various unexplained crashes.

    My suggestions for preventing and detecting this issue;
    • A visual dependency drawer tool can be developed. It's not easy to trace asset bundle dependencies. (We used dependency viewer, addressable analyzer, asset bundle browser and event viewer for solving this issue but still struggled to trace some dependencies)
    • Also a new analyzer rule can be added to detect local assets that depend on remote assets or these assets can be logged as warning after everytime new addressables built.
    • A new group option like 'local with only local dependencies' can be added. If any asset in this group violates this rule, addressable build could fail.

    I hope It will be helpful for anyone facing similar issues.
     
    DavidZobrist likes this.
  3. Jribs

    Jribs

    Joined:
    Jun 10, 2014
    Posts:
    154
    @ertugrulerdogan I am running into this problem as well.

    What ended up being the solution to your problem? What did you do to fix it? Any tips on tracking down the problem bundles?

    I have found in the past that I was able to delete the object and re add it as an addressable and that would fix my problem.

    But with the current object that I am having trouble with, it is a prefab that has a ton of dependencies with other bundles. I don't know exactly which one is the problem bundle.
     
  4. ertugrulerdogan

    ertugrulerdogan

    Joined:
    Mar 26, 2015
    Posts:
    4
    @Jribs Event viewer is useful for finding out dependencies of the loaded addressable asset. Look for implicitly referenced bundles and check if they are in memory when clearDependecyAsync method invoked. Move these dependencies into a new group or change bundle mode to pack separately. Both solution worked for us.

    As a workaround, don't use ClearDependecyAsync method until the issue gets fixed.
     
  5. unity_shane

    unity_shane

    Unity Technologies

    Joined:
    Jun 3, 2021
    Posts:
    106
    @ertugrulerdogan , Hi there, thanks for pointing out this issue and creating a bug report for it - we have our eyes on this and will take into consideration your suggestions as we tackle fixing the bug in an upcoming version. In particular I think the idea of an Analyze rule that could detect and display this kind of dependency sounds particularly useful. We will explore these options moving forward. Thanks!
     
    DavidZobrist likes this.