Search Issue Tracker
By Design
Votes
1
Found in
2018.1.0a1
2019.2.19f1
2019.3
2020.2
Issue ID
1217907
Regression
Yes
Memory is not deallocated immediately after Texture2D object was deleted
Reproduction steps:
1. Open the attached case "case_1217907"
2. Click on the "Test" > "Texture Memory Test" in the menu bar
3. Open Windows Task Manager
4. Observe Unity Editor's Memory consumption in the Task Manager
Expected result: memory usage does increase drastically
Actual result: memory usage increases by a lot which sometimes leads to a fatal error: system out of memory
Reproducible with: 2018.1.0a1, 2018.4.18f1, 2019.3.5f1, 2020.1.0b1, 2020.2.0a2
Not reproducible with: 2017.4.37f1
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- [iOS] The safe area value changes when reopening the app in Landscape orientation
- Light flickering when using Forward+ on Mobile
- Crash on mono_g_hash_table_find_slot when entering Play Mode
- [iOS] Crash when pressing "Done" on the keyboard layout
- Sprite Atlas remains loaded in memory after scene change or unloading assets
Resolution Note (2020.2.X):
After loading a texture the data is uploaded to the GPU asynchronously. The Resources.UnloadAsset call will delete the Texture2D object but the actual texture data is kept around until the async texture upload completes. In this specific case the memory increases to an amount larger than the available memory which results in a crash. Setting the virtual memory page file in your OS larger will prevent the crash. Unfortunately we cannot handle the out of memory better at the moment. The texture operations will need to be spread over multiple frames to keep the memory usage lower. We will update the documentation to specify more clearly that the memory allocated for certain resources can be kept around longer if it is referenced by the render thread (which is the case for uploading resources).