Search Issue Tracker
Won't Fix
Votes
0
Found in
2017.4
2020.1.0b3
2020.2
Issue ID
1232793
Regression
No
[Critical] Player crashes when Disposing ComputeBuffer from Finalizer
Steps to reproduce:
1. Open attached project "ComputeBufferDispose.zip"
2. Build and Run it
3. Observe the crash
Expected results: Unity does not crash when Disposing ComputeBuffer from Finalizer
Actual results: Unity crashes when Disposing ComputeBuffer from Finalizer
Reproducible with: 2017.4.39f1, 2018.4.21f1, 2019.3.9f1, 2020.1.0b5,
Note: All platforms are affected. Android and IOS mobile devices do not reproduce in 2018.4 and below
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
- Render Pipeline Converter selected asset counter reports one fewer item when using manual selection
- [Android] [Adreno] [WebGL] A light cookie is not rendered with shader compile error when WebGL build is launched on a device with Adreno GPU
- Rigibody sliding over a flat surface that is made of several GameObjects detects false collisions when Collision Detection is set to "Continuous" or "Continuous Dynamic"
- UI Toolkit Label height is incorrectly calculated when using max-width with percentage value
- Visual Effect Material causes Scene view to update continuously when both Scene and Game views are open, despite "Always Refresh" being disabled
Resolution Note (2020.2.X):
After some discussion, we've determined this is a won't fix for now.
The reasoning is that the code in question was always fundamentally flawed. You cannot invoke the ComputeBuffer's Dispose on any thread that isn't the main thread. Currently, in the editor this will manifest in one of two ways, it'll either print a warning saying that it's leaking memory, or it'll throw an exception. This seems to be dependent on the order the GC visits the parent class vs. the nested one.
In the player this crashes because the exception checking is disabled. This has been the case for the windows player/editor for a long time. It's possible that mac/android have changed how their threading works in the player which has changed the behavior, but this was always Invalid code.
To fix this proper would require a fairly larger refactor to not release resources immediately if on a separate thread, but to queue them so they could be handled on the main thread.