mirror of
https://github.com/OPCFoundation/UA-.NETStandard.git
synced 2026-10-18 14:43:08 +08:00
Marek Linka
4018bfec91
# Description As already discussed in #3173, there is a significant memory leak in the way complex types are handled in the original, reflection-based `ComplexTypeSystem`. Even though there is now a newer version of this code that does not use reflection, the reflection code is still available for consumers, meaning the leak can still impact people out there. With a minimal repro (attached), I managed to isolate the issue a bit further than the original report. The leak was not just kernel handles for events or semaphores but the whole dynamic assembly - with the `AssemblyBuilderAccess.Run` flag set, the GC could never free that assembly. Changing the flag to `RunAndCollect` resolves that problem, allowing the dynamic assembly to be collected once all references to it are lost. My repro code proves that the assembly gets collected and memory no longer accumulates with each `complexTypeSystem.LoadAsync`. ### Repro Simple single-file C# project, should be pointed to a checkout of this repo via a project reference to allow compilation. It runs a loop of opening and closing a session, each session then uses `ComplexTypeBuilderFactory` to build the dynamic assembly of complex types. Each session is then disconnected and disposed. Every 100 iterations, the repro forces full GC and reports several statistics: current GC-managed memory, current proces private memory, number of the generated dynamic assemblies (counted via name), and total number of open handles. [repro.zip](https://github.com/user-attachments/files/32555109/repro.zip) ### Repro output `AssemblyBuilderAccess.Run`: ``` [Start] Memory consumption: [GC] 3641352, [Private] 36499456, [DynamicAssemblies] 0, [Handles] 381 [Step 0] Memory consumption: [GC] 10459408, [Private] 50515968, [DynamicAssemblies] 1, [Handles] 401 [Step 100] Memory consumption: [GC] 10568320, [Private] 75034624, [DynamicAssemblies] 101, [Handles] 614 [Step 200] Memory consumption: [GC] 10539488, [Private] 93138944, [DynamicAssemblies] 201, [Handles] 814 [Step 300] Memory consumption: [GC] 10933536, [Private] 113786880, [DynamicAssemblies] 301, [Handles] 1015 [Step 400] Memory consumption: [GC] 11031496, [Private] 140181504, [DynamicAssemblies] 401, [Handles] 1215 [Step 500] Memory consumption: [GC] 11064296, [Private] 161914880, [DynamicAssemblies] 501, [Handles] 1415 [Step 600] Memory consumption: [GC] 11094168, [Private] 180477952, [DynamicAssemblies] 601, [Handles] 1608 [Step 700] Memory consumption: [GC] 11127368, [Private] 207298560, [DynamicAssemblies] 701, [Handles] 1811 [Step 800] Memory consumption: [GC] 11160168, [Private] 228204544, [DynamicAssemblies] 801, [Handles] 2008 ... ``` As you can see, each iteration leads to a new dynamic assembly being created and they are all being retained, even though the sessions they belong to have been disposed. This also means increase in kernel handles and the process' private memory (about 200 kB per session, not a trivial amount). `AssemblyBuilderAccess.RunAndCollect`: ``` [Start] Memory consumption: [GC] 3641400, [Private] 36446208, [DynamicAssemblies] 0, [Handles] 379 [Step 0] Memory consumption: [GC] 10630800, [Private] 50372608, [DynamicAssemblies] 1, [Handles] 401 [Step 100] Memory consumption: [GC] 10982808, [Private] 53596160, [DynamicAssemblies] 1, [Handles] 410 [Step 200] Memory consumption: [GC] 11048288, [Private] 46280704, [DynamicAssemblies] 1, [Handles] 413 [Step 300] Memory consumption: [GC] 10956664, [Private] 45817856, [DynamicAssemblies] 1, [Handles] 417 [Step 400] Memory consumption: [GC] 10915352, [Private] 47124480, [DynamicAssemblies] 1, [Handles] 410 [Step 500] Memory consumption: [GC] 10914776, [Private] 44843008, [DynamicAssemblies] 1, [Handles] 410 [Step 600] Memory consumption: [GC] 10890776, [Private] 44810240, [DynamicAssemblies] 1, [Handles] 408 [Step 700] Memory consumption: [GC] 10916144, [Private] 46235648, [DynamicAssemblies] 1, [Handles] 408 [Step 800] Memory consumption: [GC] 10901248, [Private] 45531136, [DynamicAssemblies] 1, [Handles] 411 ... ``` This time, we only ever retain a single dynamic assembly, the one being used for the currently open session, which is expected. The memory footprint stays flat, as does the number of open handles. ## Related Issues Fixes #3173 ## Checklist _Put an `x` in the boxes that apply. You can complete these step by step after opening the PR._ - [x] I have signed the [CLA](https://opcfoundation.org/license/cla/ContributorLicenseAgreementv1.0.pdf) and read the [CONTRIBUTING](https://github.com/OPCFoundation/UA-.NETStandard/blob/master/CONTRIBUTING.md) doc. - [x] I have added tests that prove my fix is effective or that my feature works and increased code coverage. - [ ] I have added all necessary documentation. - [ ] I have verified that my changes do not introduce (new) build or analyzer warnings. - [ ] I ran **all** tests locally using the **UA.slnx** solution against at least .net **framework** and .net **10**, and all passed. - [ ] I fixed **all** failing and flaky tests in the CI pipelines and **all** CodeQL warnings. - [ ] I have addressed **all** PR feedback received. --------- Co-authored-by: Marc Schier <marcschier@users.noreply.github.com>