I have recently gone through the journey of converting my project to load assets via the Addressables system.
For some reason, most of the time when I load my dungeonAsset, Unity will freeze.
I then have to kill Unity and reload my project and it is a massive mission.
[SerializeField] public AssetReference dungeonAsset;
public IEnumerator CreateRoutine(int dungeonID, int dungeonSize) {
new GameObject("===========Dungeon===========");
AsyncOperationHandle<GameObject> handle
= Addressables.LoadAssetAsync<GameObject>(dungeonAsset);
Debug.Log("It breaks here half the time");
yield return handle;
if (handle.Status == AsyncOperationStatus.Succeeded) {
GameObject dungeon = handle.Result;
I am considering upgrading my project to 2018.4 LTS version
I upgraded my project to the latest LTS version, and am still experiencing the problem.
I supsect there might be some kind of deadlock happening
In the meanwhile, I have replace the above code with the following, which works every time.
I have the same problem, it happens after the second time the game is launched and the remote assets should be cached. Then if multiple assets get loaded at the same time the editor or the phone just freezes with 0% cpu usage. Did you find any solution?
I found the issue yes. It has nothing to do with addressables.
The asset I was trying to load had a chance of creating a memory leak - i.e. one of my procedural generation methods got called infinitely and that is what caused the editor to freeze.
We have the same problem, it is not with every group and seems to be completely random. We even tried with a new group and empty game objects as assets, still freezes after the second time loading.
What I found out so far:
If the asset needs to be downloaded, it always works.
The first time you open Unity it always works (remote or cached)
If you add some kind of delay in front of the Addressables load function (even one frame is enough) it always works.
We tried 2 full days to find a fix, but nothing was able to prevent these crashes, so we did the only thing that worked: add the stupid delay. Probably will encounter this again if another team member uses these functions in an odd place where we have to implement the delay again.