Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[mono] Native memory leak on the first invoke of every open-instance delegate to a virtual method

Open Beginner friendly
  • Is something wrong?
#136,284 0 comments 6 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
72/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp
Domain
backend

Research direction

Start in src/mono/mono/metadata/marshal.c and read mono_marshal_get_delegate_invoke_internal, focusing on the two wrapper-cache hit returns after target_method_sig is duplicated. Check how that allocation is owned and freed on each path, then run the relevant Mono runtime tests. Done when repeated open-instance delegates to virtual methods no longer grow native memory and existing tests pass.

Written by the indexing model from the issue text.

Description

area-VM-meta-mono untriaged
Description

[Mono] Native leak in mono_marshal_get_delegate_invoke_internal: target_method_sig is never freed on a wrapper cache hit

Repository: dotnet/runtime. Area label: area-VM-meta-mono. OS: Android (Mono runtime).

Description

On Mono, every new open-instance delegate over a virtual method (including a property that implements an interface) leaks a duplicated MonoMethodSignature on its first invoke. Code that creates such delegates repeatedly leaks native memory without bound, and it shows up nowhere in the managed heap.

In src/mono/mono/metadata/marshal.c, mono_marshal_get_delegate_invoke_internal (tag v10.0.12, unchanged on main):

if (subtype == WRAPPER_SUBTYPE_DELEGATE_INVOKE_VIRTUAL) {
    /*
     * We don't want to use target_method's signature because it can be freed early
     */
    target_method_sig = mono_metadata_signature_dup_delegate_invoke_to_target (invoke_sig);   // g_malloc (image == NULL)

    closed_over_null = sig->param_count == target_method_sig->param_count;
}

/*
 * Check cache
 */
if (ctx) {
    ...
    res = check_generic_delegate_wrapper_cache (cache, orig_method, method, ctx);
    if (res)
        return res;                 // target_method_sig leaked
    ...
} else if (callvirt) {
    ...
    res = (MonoMethod *)g_hash_table_lookup (cache, invoke_sig);
    mono_marshal_unlock ();
    if (res)
        return res;                 // target_method_sig leaked
    ...
}

mono_metadata_signature_dup_delegate_invoke_to_target calls mono_metadata_signature_dup_full (NULL, sig), which allocates with g_malloc. Nothing frees target_method_sig on the cache-hit returns (or anywhere else in the function). Since mono_delegate_trampoline disables caching for callvirt delegates, every new delegate instance of this kind reaches this code once, and after the first one the wrapper is always cached.

The copy was introduced between 7.0 and 8.0: v7.0.20 has no call to mono_metadata_signature_dup_delegate_invoke_to_target, v8.0.18, v9.0.7 and v10.0.12 do.

Reproduction Steps

On a .NET for Android app (Mono), e.g. net10.0-android, Release, on a device:

public interface IFoo { int Value { get; set; } }
public class Foo : IFoo { public int Value { get; set; } } // implements IFoo, so set_Value is virtual
public class Bar { public int Value { get; set; } } // control: non-virtual

static double LeakPerDelegate<T>() where T : new()
{
    var setter = typeof(T).GetProperty("Value")!.GetSetMethod()!;
    var target = new T();
    for (var i = 0; i < 1_000; i++) // warm up: wrapper is now cached
        ((Action<T, int>)Delegate.CreateDelegate(typeof(Action<T, int>), null, setter))(target, i);

    GC.Collect(); GC.WaitForPendingFinalizers(); GC.Collect();
    var before = Android.OS.Debug.NativeHeapAllocatedSize;
    for (var i = 0; i < 100_000; i++)
        ((Action<T, int>)Delegate.CreateDelegate(typeof(Action<T, int>), null, setter))(target, i);
    GC.Collect(); GC.WaitForPendingFinalizers(); GC.Collect();
    return (Android.OS.Debug.NativeHeapAllocatedSize - before) / 100_000.0;
}
Expected behavior

Native heap does not grow per delegate once the invoke wrapper is cached (as for Bar).

Actual behavior

Measured on a Samsung SM-X306B, Android 16, .NET for Android workload 36.1.69, Mono runtime pack Microsoft.NETCore.App.Runtime.Mono.android-arm64 10.0.12 (libmonosgen-2.0.so build id 54924a38a8872da3a0bb85f533898e89895508b7):

Target Native heap growth per delegate
Foo (virtual setter) 80 bytes
Bar (non-virtual setter) 0 bytes

A Perfetto heapprofd profile of the real app attributes the unreleased memory to:

monoeg_malloc
mono_metadata_signature_dup_internal
mono_metadata_signature_dup_full
mono_metadata_signature_dup_delegate_invoke_to_target
mono_marshal_get_delegate_invoke_internal
mono_delegate_trampoline
<generated code>
Regression?

Yes: not present in .NET 6/7 Mono, present from .NET 8.

Known Workarounds

Avoid creating open-instance delegates over virtual methods repeatedly (cache them), or make the target methods non-virtual.

Configuration

.NET 10.0.12 Mono runtime, Android arm64. Not specific to Android as far as the code goes. Any Mono target should be affected.

Other information

Real-world impact: sqlite-net-pcl (1.10.196-beta and master) creates one such delegate per mapped column on every query (FastColumnSetter.CreateTypedSetterDelegate → Delegate.CreateDelegate(typeof(Action<ObjectType, ColumnMemberType>), null, setter)), so any app whose entities implement interfaces leaks ~64 bytes per column per query. In our app that is ~100 KB per user action.

Suggested fix: free the copy on the early returns, or only make it on the cache-miss path, e.g.

if (res) {
    g_free (target_method_sig);
    return res;
}

for both the ctx and callvirt branches (target_method_sig is NULL for the other subtypes, and g_free (NULL) is a no-op).

Dominant language
C#
Stars
18.4k
Forks
5.8k
Avg merge
2d 16h
Merged PRs (30d)
631

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dotnet/runtime

All issues in dotnet/runtime

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.