-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
[release/7.0] Fix reserving executable memory as per allocation type in ClrVirtualAllocWithinRange() #83958
[release/7.0] Fix reserving executable memory as per allocation type in ClrVirtualAllocWithinRange() #83958
Conversation
…llocWithinRange() Fixes #83818
In the failed leg, only one test has failed and that was with a known issue: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
approved. we will take for consideration in 7.0.x
I'm retargeting this PR to the new Repo maintainers will now be allowed to merge their own servicing PR as long as it meets the requirements:
The new process is described here: runtime/docs/project/library-servicing.md. The infra team will be actively monitoring servicing PRs to ensure all requirements are met and to help with any issues. Let me know if you have any questions. |
Reminder: April 10th is the last day to merge backport PRs to ensure they get included in the May Release. PR owners are now in charge of merging their own PRs. |
@jkotas can you please approve this? |
@carlossanlop I can see that an extra commit 6a533c1 was added to this PR by dotnet-maestro. It updates emsdk version. I don't know why that happened - could it be some bad merge when you have retargetted this PR? I can see that wasm / tvos tests are failing, so I wonder if it is because of that. |
Not sure why that commit was added, but it shouldn't be there. Can you please remove it, @janvorli? The dependency flows are happening in separate automated PRs. Edit: Fixed it with GitHub suggestions. |
@carlossanlop Any chance we can merge this isn now that it is green? |
Backport of #83819 to release/7.0
/cc @janvorli @k15tfu
Customer Impact
A customers sometimes get a
System.OutOfMemoryException
exception in .NET 7 app on macOS ARM64 in arbitrary places. The issue is caused by a bug in theClrVirtualAllocWithinRange
specific to macOS. It happens when the application uses up all the executable memory preallocated at app start time and theExecutableAllocator
tries to allocate more using theClrVirtualAllocWithinRange
. That function doesn't set the specialMEM_RESERVE_EXECUTABLE
flag that causes the PAL to mmap the memory range with theMAP_JIT
flag that enables the special Apple M1 processor support for regions that can be switched between read-execute and read-write modes per thread.Testing
CI testing, local targeted testing
Risk
Low, the change is very small and only influences the problematic case and doesn't change any other behavior.