Search Issue Tracker
Won't Fix
Votes
1
Found in
2019.4
2020.3
2021.2
2021.2.8f1
2022.1
2022.2
Issue ID
1408974
Regression
No
Memory leak when instantiating and destroying GameObjects with a collider
Reproduction steps:
1. Open the user's attached project "ColliderMemLeak.zip"
2. Open "SampleScene"
3. Enter Play mode
4. Click "Start" in the Game view
5. Observe memory usage in the Profiler window
Expected result: Memory is released
Actual result: Memory is never released, the Editor becomes slow and unresponsive after a while
Reproducible with: 2019.4.36f1, 2020.3.31f1, 2021.2.15f1, 2022.1.0b11, 2022.2.0a7
Note:
1. Tested with Mesh and Box colliders
2. "Total Used Memory" under the Memory module decreases slightly after clicking "Stop" but "Physics Used Memory" under the Physics module does not
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
- Articulation Body with 'Revolute' Joint Type has erratic behavior when Upper Limit is set to above 360
- WebGL Player fails to render Scene when Terrain with Detail Mesh is added and WebGPU Graphics API is used
- Inconsistent errors are logged when different types are passed into the Query "Q<>" method in UIToolkit and the ancestor VisualElement is null
- Crash on GetMaterialPropertyByIndex when opening a specific Scene
- Discrepancies in the styling are present when using a TSS file instead of a USS file in custom EditorWindow
Resolution Note:
The issue here is that element IDs for PhysX objects are never flushed and dynamic arrays that are indexed by them grow to infinity over time as the objects are spammed. Unused IDs are flushed in the PxScene::simulate() call of PhysX but since there are 0 active physics objects in the scene, the call is always skipped. Removing the 0 object check would be a performance regression.
Adding at least a single physics object to the scene circumvents the issue.