-
Notifications
You must be signed in to change notification settings - Fork 4.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Marshal.GetFunctionPointerForDelegate leaks memory #353
Comments
Introduced by f9a161c |
I see the thunks getting reused after a while. Yes, we use some extra fixed amount of memory to get better diagnostics after f9a161c, but it is not a memory leak. I agree that we have a memory leak, but the problem are leaking GC handles. There is nothing that calls |
Yes, looks like the thunks are good. We create up to 64 and then reuse them, as @jkotas noted. However, everytime My commit stops the leak, although I'm not sure if it is the correct approach. |
@mateoatr Thanks for looking into this.
We want to destroy the GC handle for thunks that are not in use. Otherwise, the GC handles would be keeping user objects alive for no good reason that would be a different type of leak. I think that the fix should be to move the code from |
What version of .net core has fix for this? |
This fix will ship in .NET 5. It was not back-ported to older versions. |
Is this bug in .NET Framework 4.6.2? I'm about to deploy a long-running program that does a lot of GetFunctionPointerForDelegate, should I expect problems? |
This bug was in .NET Core only. |
Is there a work around for this at all? Or any chance of getting this patched in .Net Core 3.X? We encountered this in a new project we're working on with .Net Core 3.1. |
@cnx-jd Thanks for asking about this again. Given the recurrent requests and the trivial change, we have decided to consider this for .NET Core 3.x servicing. The discussion for servicing and decision can be followed at dotnet/coreclr#28074. |
Copied from a VSFeedback item.
A customer noticed that repeated calls to a p/invoke that took a delegate appeared to be leaking memory. The underlying cause is the new way that we allocate umentrythunks and how GetFunctionPointerForDelegate caches them. Previously, the same thunk was returned and used when run in a tight loop (see code below). Now a new thunk is used every time, which results in memory seemingly increasing.
The text was updated successfully, but these errors were encountered: