[Bug] Memory leak after release assets

I was looking for the cause of the memory leak and memory profiler shows, what all textures stay linked with CachedProviderUpdater and not release after changing scene (or UnloadUnusedAssets).

Tested on versions 2018.3.b12 and 2018.3.b5, Android and standalone builds
Addressables: 0.4.8-preview

Experiments shows what object link wont removed from m_lru list in CachedProvider instance, but if clear it manually, resources will release.

In attached project object instantiated by Addressables.Instantiate. Then handled SpriteAtlas request, loading atlas by Addressables.LoadAsset<SpriteAtlas>. On release btn pressed, object and loaded atlas are released too. But after reloading scene, resources still in memory.

 

Release textures memory after release prefab instance still not happening in unity 2018.3.0f2, Addressables 0.5.2.

Textures unloaded only if load prefab or scriptable object by Resource.Load from Resources folder. Resources.UnloadUnusedAssets unloaded all resources, even sprite atlases what loaded by Addressables.LoadAsset<SpriteAtlas> (no need call ReleaseAsset manually).

So now we cant store prefabs in asset groups, only in Resources folder.
On screen refs to texture, which remained after scene reloading.

 

*edit* disregard this, see next post

I was encountering this too where chunks of an environment (meshes,textures,materials) had a single reference to the CachedProvider and would never be released from memory.

I think it is the settings on the CachedProvider, if you look at the build scripts for PackedMode and VirtualMode ( com.unity.addressables@0.5.3-preview\Editor\Build\DataBuilders\BuildScriptPackedMode.cs )

you'll see that both have 2 new CachedProvider.Settings around line 140:

new CachedProvider.Settings { maxLruAge = 1, maxLruCount = 10, InternalProviderData = bapData }

I changed maxLruCount to 0 which makes assets release immediately as the comment in CachedProvider.cs says:

/// The maximum number of items to hold in the LRU. If set to 0, the LRU is not used and items will be released as soon as the reference count drops to 0.

The interesting one is maxLruAge, the comment says:
/// The time, in seconds, to hold on to items in the cache. This value scales inversely to how full the LRU is. The last item will take this long to be removed. If set to 0, items are not automatically removed.

So it makes me wonder how the time scaling works, I let the build sit for a while and things didn't get released.

Either way, in my case I expected things to release immediately when ref count is 0, so setting maxLruCount to 0 solved that for me. But I do like the idea of maxLruAge, so I might try tracking down how that works.

 

yea, actually the bug is right here in UpdateLru, just a typo in how elapsed time is used:

Code (CSharp):

1. float time = Time.unscaledTime;
2. while (m_Lru.Last != null && (m_Lru.Last.Value.lastAccessTime - time) > maxLruAge && m_Lru.Last.Value.IsDone)

lastAccessTime - time will always be negative, so this while loop used for releasing the resources never executes. Changing it to (time - m_Lru.Last.Value.lastAccessTime) fixes the issue.

 

@PaulBurslem any new ETA for the next release?

 

more than a week, less than a month

the next release will be 1.0 so we want to make sure to tackle all the API-changing bugs at once. (read: there will be API breakage next release, but ideally not for a long long time after that)

 

Any update on this ETA for the release of Addressables 1.0?