TldrOlli
Process API: Memory Leaks in Windows (?)
Mh, opentel doesn't like the metric (same for max).. I took a look here and other places..
My best guess would be that my otelcol-contrib is not up-to-date enough (installed yesterday :/)
Edit: Tried multiple versions, current log is wrong.. one sec
Edit2: Fixed
Config:
28 replies
Process API: Memory Leaks in Windows (?)
I will prepare that now and run it once I see the memory consumption go up in the windows service (above version)
Maybe (not too optimistic) the above change already fixes my leak..
But still my question: If the Process itself would be incorrectly handled (not disposed), wouldn't I see that in the managed memory?
28 replies
Process API: Memory Leaks in Windows (?)
I found an older state here and I'm fully aware that the using/dispose is missing in that state.
I did add it and let it run for a while (with the disposal), but had no luck.
However, maybe it's worth a shot retrying just plain Process with all the other noise (thousands of CTS recreations) gone
28 replies
Process API: Memory Leaks in Windows (?)
Yep.. Well, I did.. CliWrap's Process is not disposable.
As far as I can tell from going through the libraries source code the Process is disposed as expected.
In any case, wouldn't this, without being correctly disposed, show up as increasing managed memory (see dashboard above)
Edit: Trying to find the last version that still used Process for reference
Edit2: Squash merge ftw :/
28 replies
Process API: Memory Leaks in Windows (?)
Sorry for my bad communication there :^)
wait, do you mean memory increases only when run as a service or even as a standalone app?I only run it as a service, I never measured it (over a day or so) when running from the console/via IDE I meant to say with that: "It is running as a windows service" (and not that there is a difference in windows service vs usual CLI execution)
does memory increase even when not running any periodic check?No, it does not. It stays perfectly flat/constant, no memory issues
have you tried running just a check in a new empty project to see if it misbehaves?Can you clarify here? I don't know what you mean, sorry. Edit: Do you mean just running the Process.Start calls (as simple as possible) in an infinite loop?
28 replies
IoC and messy factory methods
As of now you should be only having a reference to IServiceCollection in your library, to register the services (AddSingleton/Scoped/Transient).
When you are building the ServiceCollection yourself (in the same library) you lock in on the DI provider.
That is not really a bad thing, usually the Microsoft IoC Container is sufficient.
Other IoC Frameworks (like AutoFac) work by providing an adapter from IServiceCollection to their way of registering services.
That means having the hard reference to the ServiceCollection is not really required in your library, because you are working on IServiceCollection.
However, if I am not mistaken, it seems that these extension methods anyway come from said
Microsoft.Extensions.DependencyInjection.Abstractions package.. so you would not even add an additional nuget reference to your library if you are not splitting. In my memory ServiceCollection (the class) and the extension methods (on IServiceCollection) were in seperated NuGet packages.
Hope that makes sense. :)I25 replies
IoC and messy factory methods
ServiceCollection is published as part of the NuGet package Microsoft.Extensions.DependencyInjection.Abstractions, you probably do not want to have that reference directly in your core/library, so I think your best bet would be to create a seperate CSPROJ (if possible) that gives you an instance (of SomeClass) utilizing the nuget package. That project can then be consumed from the app that has no IoC container.25 replies
Process API: Memory Leaks in Windows (?)
Additional Points to Note (that I could not add above because of a character limit, lol):
- The only way to free up the memory is a complete reboot of the PC
- The screenshot is a little bit older, so there are more commands in the dashboard showing up than mentioned above, but the behaviour is the same
- I did already some dotmemory analysis and even in longer executions the managed memory seems fine (after some tweaking, especially resetting CancellationTokenSources)
Edit: To establish a different baseline I deployed the same code as a linux service (kali) with just a ping command. It has been running only for 2 hours, but there I see no increase in processing time or increasing memory consumption
28 replies