Blazor WebAssembly suffers memory leaks from compiled lambda expressions

[DouglasKSmith]

Description

We have a Blazor WebAssembly app whose memory keeps increasing until it hits the 2 GB limit, then silently crashes. We've narrowed down the main cause of the leak to compiled lambda expressions.

Reproduction Steps

The following code may be used to reproduce the memory leak. It can be wired up as the event handler of a button on a page. When left running in the active tab (in the foreground), it leaks around 46 MB of memory a minute, causing the 2 GB limit to be reached (and the app to crash) in 47 minutes.

private async Task RunMemoryLeakTestAsync()
{
    long total = 0;

    for (long i = 0; i < 2_000_000_000; i++)
    {
        Expression<Func<long, long>> expression = x => x + x;
        var func = expression.Compile();
        total += func(i);

        if (i % 1_000 == 0)
            await Task.Delay(millisecondsDelay: 100);  // keep app responsive and give GC time to run
    }
}

Expected behavior

The online consensus appears to be that compiled lambda expressions shouldn't cause memory leaks in .NET. (That answer was directed at .NET proper, not Blazor WebAssembly.)

Actual behavior

Compiled lambda expressions cause a memory leak in Blazor WebAssembly. The app would consequently silently crash once the 2 GB limit is reached.

Regression?

Compiled lambda expressions don't cause memory leaks in .NET proper.

Known Workarounds

The only workaround we have is to avoid using compiled lambda expressions in Blazor WebAssembly.

Configuration

Blazor WebAssembly, compiled on .NET 6.0 using Release configuration.
Run in Google Chrome 110.0.5481.104 (64-bit) without debugging, on Windows 10.

Other information

May be related to #62054. However, we've given our issue a quick test on .NET 7.0, and it still occurred.

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

We have a Blazor WebAssembly app whose memory keeps increasing until it hits the 2GB limit, then silently crashes. We've narrowed down the main cause of the leak to compiled expressions.

Reproduction Steps

The following code causes 1GB to be leaked in about 30 minutes. It can be pasted as the event handler of a button on page.

private async Task RunMemoryLeakTestAsync()
{
    var total = 0;

    for (int i = 0; i < 100_000_000; i++)
    {
        Expression<Func<int, int>> expression = x => x * 2;
        var func = expression.Compile();
        total += func(i);

        if (i % 1_000 == 0)
            await Task.Delay(millisecondsDelay: 100);  // keep app responsive and give GC time to run
    }
}

Expected behavior

The online consensus appears to be that compiled expressions shouldn't cause memory leaks in .NET. (That answer was directed at .NET proper, not Blazor WebAssembly.)

Actual behavior

Compiled lambda expressions cause a memory leak in Blazor WebAssembly. The app would consequently silently crash once the 2GB limit is reached.

Regression?

Compiled lambda expressions don't cause memory leaks in .NET proper.

Known Workarounds

The only workaround we have is to avoid using compiled expressions in Blazor WebAssembly.

Configuration

Blazor WebAssembly, compiled on .NET 6.0, running in Google Chrome on Windows 10.

Other information

No response

Author:	DouglasKSmith
Assignees:	-
Labels:	arch-wasm, area-System.Linq.Expressions, untriaged
Milestone:	-

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

Issue Details

---

Description

We have a Blazor WebAssembly app whose memory keeps increasing until it hits the 2 GB limit, then silently crashes. We've narrowed down the main cause of the leak to compiled expressions.

Reproduction Steps

The following code causes 1 GB to be leaked in about 30 minutes when built using Debug configuration, or 150 MB in 1½ hours using Release configuration. The method can be wired up as the event handler of a button on a page.

private async Task RunMemoryLeakTestAsync()
{
    var total = 0;

    for (int i = 0; i < 100_000_000; i++)
    {
        Expression<Func<int, int>> expression = x => x * 2;
        var func = expression.Compile();
        total += func(i);

        if (i % 3_000 == 0)
            await Task.Delay(millisecondsDelay: 10);  // keep app responsive and give GC time to run
    }
}

Expected behavior

The online consensus appears to be that compiled expressions shouldn't cause memory leaks in .NET. (That answer was directed at .NET proper, not Blazor WebAssembly.)

Actual behavior

Compiled lambda expressions cause a memory leak in Blazor WebAssembly. The app would consequently silently crash once the 2 GB limit is reached.

Regression?

Compiled lambda expressions don't cause memory leaks in .NET proper.

Known Workarounds

The only workaround we have is to avoid using compiled expressions in Blazor WebAssembly.

Configuration

Blazor WebAssembly, compiled on .NET 6.0, running in Google Chrome on Windows 10.

Other information

No response

Author:	DouglasKSmith
Assignees:	-
Labels:	arch-wasm, area-System.Linq.Expressions, untriaged, area-GC-mono
Milestone:	-

[jtorjo]

I am really interested in this, but I don't really think it causes any leaks:

private int RunGC() {
    var watch = Stopwatch.StartNew();
    GC.Collect();
    GC.WaitForPendingFinalizers();
    GC.Collect();
    return (int)watch.ElapsedMilliseconds;
}
private async void Page_Loaded(object sender, RoutedEventArgs e) {
    await Task.Delay(10000);
    long total = 0;
    var count = 500_000_000;

    RunGC();
    double gcMemoryMB = 0;
    gcMemoryMB = (double)GC.GetTotalMemory(false) / (1024d * 1024d);
    Console.WriteLine($"START mb={gcMemoryMB}");

    for (long i = 0; i < count; i++)
    {
        Expression<Func<long, long>> expression = x => x + x;
        var func = expression.Compile();
        total += func(i);
        if (total > 1_000_000_000)
            total = 0;

        if (i % 100_000 == 0) {
            var gcTime = RunGC();
            gcMemoryMB = (double)GC.GetTotalMemory(false) / (1024d * 1024d);
            Console.WriteLine($"i={i} mb={gcMemoryMB} time={gcTime}");
            await Task.Delay(millisecondsDelay: 100);  // keep app responsive and give GC time to run
        }
    }
    gcMemoryMB = (double)GC.GetTotalMemory(false) / (1024d * 1024d);
    Console.WriteLine($"END before gc mb={gcMemoryMB}");

    RunGC();
    gcMemoryMB = (double)GC.GetTotalMemory(false) / (1024d * 1024d);
    Console.WriteLine($"END mb={gcMemoryMB}");
    RunGC();
    RunGC();
    gcMemoryMB = (double)GC.GetTotalMemory(false) / (1024d * 1024d);
    Console.WriteLine($"END 2 mb={gcMemoryMB}");
}

I've run this test in .net7 + webassembly -- manually calling the GC.Collect() will show you stuff is properly collected.
I' haven't tested .net6, but I'm almost certain it'll behave the same way.

[lewing]

We've made some fixes here for RC1 and believe it is resolved. Please reopen if you are still seeing problems