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

Mono

-

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

  1. 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.

Add comment

Log in to post comment

All about bugs

View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.