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
- Text Object position shifts when selecting multiple Text Objects and expanding the Extra Settings in the Inspector
- Keywords on Material Variants aren't automatically saved when changed on original Material through Shader Graph
- Light Probes get baked when calling LightProbes.Tetrahedralize
- Shadows flicker and cause visual artifacts when modifying a GameObject's bounds using Swizzle (Y Mask) and Sine Time nodes
- [WebGL] Frame rate drops by 5-20 fps when moving cursor or touch input in the Player
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.