Search Issue Tracker
By Design
Votes
0
Found in
2019.4
2020.3
2020.3.20f1
2021.2
2022.1
Issue ID
1378218
Regression
No
Managed memory created for allocations in a scripting thread sticks around until the thread is closed
Reproduction steps:
1. Open the attached "Project_1378218_2019.zip" project
2. Open Memory Profiler (Window > Analysis > Memory Profiler)
3. In Build Settings enable "Development Build" and "Autoconnect Profiler"
4. Build and Run
5. Capture a snapshot in the Memory Profiler before the threads allocate memory (allocation will occur 10 seconds after the Player is run)
6. Capture a snapshot after the threads allocate memory ("thread x is done" logs appear in the Console)
7. Capture a snapshot after the threads are closed (occurs 20 seconds after the allocation, "thread x returned" logs appear in the Console)
8. Open the "Compare Snapshots" tab
9. Select the 5th and 6th step snapshots, and compare their "Managed Memory"
Expected result: "Managed Memory" is roughly the same in both snapshots
Actual result: "Empty Active Heap Space" and "Empty Fragmented Heap Space" memory is increased in the 6th step snapshot. The garbage collector does not return all unused (read empty) memory even though GC.Collect is simultaneously called in the main thread
Reproducible with: 2019.4.33f1, 2020.3.25f1, 2021.2.7f1, 2022.1.0b2
Note:
- In 2021.2.7f1 and 2022.1.0b2 Players, logs from threads don't appear in the Console (case 1388935) but the memory issue is reproducible
- Partially reproducible in Play mode (only "Empty Fragmented Heap Space" slightly increases after allocation and decreases after closing the threads)
- Reproduced with Mono and IL2CPP
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 (2022.2.X):
Unfortunately it may not be possible for the garbage collector to free the memory in this example. The Unity GC will keep memory alive if it finds references to that memory in any of a number of different places, including the stack and local registers. The JIT or AOT generated machine code can very easily keep memory alive by leaving references around to it in simple cases like this.
Note in the example the issue is everything happening in a single stack frame, and leaving the frame is what should avoid any references rather than a thread exiting.