.NET 8 crash with "Fatal error. Failed to create RW mapping for RX memory"

[loop-evgeny]

Description

We have many instances of our ASP.NET Core application for different customers, each running as a systemd service. One specific instance has crashed twice with "Fatal error. Failed to create RW mapping for RX memory".

The last time was on 2023-Nov-30, so this doesn't happen often. It may be because this instance of the application is particularly large, using ~300 GB RAM while loading a lot of data (once per day) and ~50 GB at other times.

Reproduction Steps

Not reproducible. Happened 2 times so far.

Expected behavior

No crash

Actual behavior

Crash with the systemd journal containing:

Fatal error. Failed to create RW mapping for RX memory
   at DynamicClass.InvokeStub_ItemCollection`1..ctor(System.Object, System.Span`1<System.Object>)
   at System.Reflection.MethodBaseInvoker.InvokeWithOneArg(System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)
   at System.RuntimeType.CreateInstanceImpl(System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)
... (our code here - can provide full stack privately if needed) ...
   at Microsoft.AspNetCore.Builder.UseMiddlewareExtensions+ReflectionMiddlewareBinder+<>c__DisplayClass6_0.<CreateMiddleware>b__0(Microsoft.AspNetCore.Http.HttpContext)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol+<ProcessRequests>d__238`1[[System.__Canon, System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].MoveNext()
   at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(System.Threading.Thread, System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e],[Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol+<ProcessRequests>d__238`1[[System.__Canon, System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]], Microsoft.AspNetCore.Server.Kestrel.Core, Version=8.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60]].MoveNext(System.Threading.Thread)
   at System.Threading.ThreadPoolWorkQueue.Dispatch()
   at System.Threading.PortableThreadPool+WorkerThread.WorkerThreadStart()
Main process exited, code=killed, status=6/ABRT

(I don't have the stack trace from the first crash, unfortunately.)

Regression?

No response

Known Workarounds

No response

Configuration

.NET 8.0.0 x64, self-contained application
Ubuntu 22.04.3 this (second) time, Ubuntu 18.04.6 the first time
Running as a systemd service
The machine has 1TB RAM, but only ~36% of it was used at the time of the crash.

Other information

The only reference I can find to this error is in #80580
The last comment there includes code to reproduce it by creating many dynamic assemblies, but that code runs successfully for me on the same machine (as well as other machines), both on .NET 8 and .NET 6. We do create some dynamic assemblies via CSharpCompilation.Emit() but I don't think we create thousands of them (but even if we did I would not expect .NET to crash like that).

[loop-evgeny]

I know this isn't much info to go on. I've installed systemd-coredump on the server now to try to get a crash dump next time, though I don't know if it will cope with a 300 GB dump!

[loop-evgeny]

@janvorli

[janvorli]

@loop-evgeny this error occurs when mmap fails to create a read-write mapping for an existing read-execute, which means an out of memory or out of maximum allowed number of memory mappings. Since you mentioned that you were not running in a container (like a docker) and that your machine still had a plenty of available memory, my guess is that the problem is likely exceeding of the allowed memory mappings limit. The limit can be raised using the vm.max_map_count setting. You can check your current one by cat /proc/sys/vm/max_map_count.

[loop-evgeny]

@janvorli I see, thanks for the explanation. Correct, we're not running in a container.

This is a rather cryptic error message, so would be nice to include in the message what you wrote here, like "Failed to create RW mapping for RX memory. This may be caused by running out of memory or out of memory mappings - check the vm.max_map_count setting on Linux or (whatever) on Windows". But it seems like we're only the second ones to run into it.

We haven't changed max_map_count, so it's at the default value of 65530. But is there a downside to increasing this? Why is there even a limit?

[loop-evgeny]

I checked the /proc/PID/maps file for the process and it currently has 19408 lines, which is much higher than other instances of our application, even large ones. That's under normal usage, so I think your hunch is right and during the daily data loading it may well go over 65530, but I'll add monitoring to check that.

[janvorli]

But is there a downside to increasing this?

There is no downside. The setting has no effect on applications that use less mappings and enables proper execution of applications that use more.

[loop-evgeny]

I've been monitoring the count of maps for that process for a week now and while it hasn't gone over 65K yet, it is steadily increasing. RAM usage goes up during the daily data loading (smaller than usual last week), then down again, but the number of memory map areas does not go down signficantly. It started around 19K a week ago and is now at 32K. Can there be a "leak" in that somehow - without an obvious memory leak?

[loop-evgeny]

We finally had a few days where memory usage went > 300 GB and the number of maps went over 80K. It then went down together with RAM usage, to ~34K. So it seems like there is no "leak" and increasing vm.max_map_count fixed this for us.

It would be good if the error message explained what the likely problem is, though. There is no way the average developer troubleshooting a crash will know that "Failed to create RW mapping for RX memory" means "Either you're out of memory or you need to increase vm.max_map_count".

[janvorli]

It would be good if the error message explained what the likely problem is, though. There is no way the average developer troubleshooting a crash will know that "Failed to create RW mapping for RX memory" means "Either you're out of memory or you need to increase vm.max_map_count".

@loop-evgeny thank you for the suggestion, that makes sense. When I have added that error message, I didn't realize that the max map count can be also causing the issue. I'll update the message along the lines of what you've suggested.