Skip to content

Conversation

github-actions[bot]
Copy link
Contributor

@github-actions github-actions bot commented Sep 5, 2025

Backport of #119316 to release/10.0

/cc @janvorli

Customer Impact

  • Customer reported

When a customer sets maximum file size limit on Linux using the ulimit -f XXXX command to a value smaller than 2TB (4GB on 32 bit OS), .NET process fails to start and crashes with SIGXFSZ signal due to the executable allocator in .NET setting maximum size of shared memory for double mapping to 2TB (4GB on 32 bit OS). See issue #117819.

Regression

Testing

Local testing app running under a debugger with ulimit -f set to low values

Risk

Low, the change causes the maximum size of executable code to be limited by the:

  • ulimit file size limit - the app would crash if we tried to reserve more space
  • physical memory limit - we cannot allocate more than the total physical memory for executable code anyways
  • ulimit virtual memory limit - when virtual memory limit is set by the user, the GC limits itself to 1/2 of the limit and leaves the remaining 1/2 of the space for the rest of the process. This change limits the max executable allocator size to 1/4 of the VM limit so that it leaves enough space for other usages.

The double mapping currently sets the maximum size of the double mapped memory to 2TB.
However, that causes the runtime to fail to start if there is a rlimit for max file
size set to a smaller value.

This change fixed the problem by clipping the max double mapped memory size by that
rlimit and also uses much more conservative size even without the file size limit set.
It is now set to the total amount of physical memory by default and also clipped by
the virtual memory rlimit.

Close #117819
Even on 32 bit targets, more than 4GB memory may be available.
@janvorli janvorli self-assigned this Sep 5, 2025
@jeffschwMSFT jeffschwMSFT added this to the 10.0.0 milestone Sep 5, 2025
Copy link
Member

@jeffschwMSFT jeffschwMSFT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

approved. please fill out the template. when ready we can merge

@jeffschwMSFT jeffschwMSFT added the Servicing-approved Approved for servicing release label Sep 5, 2025
@jeffschwMSFT jeffschwMSFT merged commit a10c6d1 into release/10.0 Sep 8, 2025
100 of 101 checks passed
@jkotas jkotas deleted the backport/pr-119316-to-release/10.0 branch September 8, 2025 17:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-PAL-coreclr Servicing-approved Approved for servicing release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants