System.SByte[] increasing number of instances in memory, causing memory leak.

[ilyoniss]

System.SByte[] increasing number of instances in memory, causing memory leak.

.NET Core 3.1.8 Project created from Workers Process template (empty base project). When performing long running, causing memory leaking.
Memory profiler detected the number of instances are growing and could not utilized by GC.
Increasing number of primitive type growing faster than can be utilized by GC.

System.SByte[] increasing number of instances in memory, causing memory leak.

Code Sample: is the any base code from template > dotnet create workers

Provide details on the problem you are experiencing including the .NET Core version, operating system version and anything else that is relevant.

Please provide a code sample for your issue if it is relevant, either inline, link to a gist (or similar) or add it as a zipped attachment.

For some issues, you will get a quicker and better response if you file it at a more specific .NET repo. For example, if the problem is with ASP.NET Core, you are encouraged to use the aspnet/home repo.

[ghost]

Tagging subscribers to this area: @eerhardt, @maryamariyan
See info in area-owners.md if you want to be subscribed.

[scalablecory]

Can you please check to see if this leak occurs when using .NET 5?

[eerhardt]

@ilyoniss - thank you for the issue report. I am unable to reproduce a memory leak using the default "Worker Service" template. Can you share more information about how you are seeing a memory leak?

Yes, objects are allocated while the service is running (this comes from logging that happens every second). However, not enough memory is allocated in order to trigger a GC in the first few minutes of it running. So that memory is not getting reclaimed until memory is needed to be reclaimed.

[stephentoub]

As an aside, since sbyte[] isn't a particular common kind of array to allocate, I'd guess these are coming from the JIT, with it allocating them to report inlining decisions to the runtime. As of dotnet/coreclr#22285, these are sbyte[]s.

[ilyoniss]

Hi Colleagues.
I was doing some development and I used a provided c ++ third party library (C# wrapper), and what I noticed is that during execution memory starts to grow.

I found a .NET memory monitoring tool and when I did snapshots, I noticed that Sbyte[] number of instances are growing. Yes I expected to GC to 'take care of it' and dispose. Since I have a third party linked library, I considered it as unmanaged resources and I used IDisposable interface to manage resources, no luck. Then I created just vanilla, base project from template and I noticed such behavior.

I also noticed that some .net was 3.0.0 preview, and I did upgrade up to 3.1.8.What I observed is that when you leave in the long run, the number of instances are growing faster than GC can dispose.

To reproduce, I did >dotnet create Workers.then >dotnet run.
 I used : https://memprofiler.com/Trial 7 days Professional.
Then take a snapshot and keep monitoring.

I feel that this will be hard to reproduce in terms of "out of memory exception", as perhaps you need significant time to wait.but it will be possible to evaluate dynamics.

I am not sure to be honest what is that..  but with conjunction with the code, memory if growing and Sbyte[] something impact on general performance.

I tried to analyze also stack trace, but could not make an interpretation, found that a lot of references points to the .net core namespaces.

[ilyoniss]

Can you please check to see if this leak occurs when using .NET 5?

Yes, I will thanks.

[ilyoniss]

sorry accidently closed.

[eerhardt]

@ilyoniss - I'm unable to reproduce a memory leak with the default worker template. Looking at your screen shots above (and trying to guess at what you are seeing), I don't think the GC has run at all. If you look at this screen shot:

you'll see that between your two snap shots, there's only 1.6 KB of "new" bytes being allocated in System.Private.CoreLib and 1.4 KB of "new" bytes in MemTest between the two snapshots. This is definitely not enough to force a GC to occur. (Note that the GC only runs when it thinks it needs to reclaim memory. You can run a .NET application for a long time, and if the application didn't allocate enough memory the GC won't ever run.)

I'm going to close this issue as there is nothing to be done here. But feel free to re-open it if you have more information on what is leaking memory.

[ilyoniss]

Hi Eerchardt, assuming Richard,

Well, I saw that new .net core 5.0 is coming may be I can rebuild in newer framework.

I shipped application to the customer so they are testing now.

I did also sort of long running testing and application is not crashing due to 'out of memory exception' and yes it is grown up to 1,5 GB out of 8.0 GB of RAM and then few times in the testing week, memory dropped may be 3 times to 50 MB only and then started growing again and there are was three cycles.

So , yes I have feeling that GC takes care of it.. but for sure that sByte type is growing faster than disposing.
and I do not know what it is... it is like some kind or primitive type. I just do not understand that is that.

I did long run test, one week.

Regards, Ilya.