aws-lambda-dotnet
aws-lambda-dotnet copied to clipboard
Libc call mlock failed with result -1 12
Description
Hi. Attempting to use a SecureMemory implementation on .NET core 2.1 on AWS Lambda, that uses libc+mlock under the covers. Periodically this fails with an error from libc/mlock "Libc call mlock failed with result -1 12"
Reproduction Steps
Run application for a bit. Sometimes it fails immediately. The Lambda reports MemoryUsedInMB at 132 of 1024.
App uses https://github.com/godaddy/asherah
Logs
See https://github.com/godaddy/asherah/issues/260
errno 12 is "12 ENOMEM Cannot allocate memory. The new process image required more memory than was allowed by the hardware or by system-imposed memory management constraints. A lack of swap space is normally temporary; however, a lack of core is not. Soft limits may be increased to their corresponding hard limits."
Environment
.NET core 2.1 on AWS Lambda
This is a :bug: bug-report
Same happens on .NET core 3.1
Hi @lyricnz,
Thank you for reporting this. Could you provide the code from the lambda you are attempting to run that fails with the stated error? (if you are not able to share exactly, a general mockup of your code should be fine) At first glance this seems like a problem with the encryption library rather than the lambda, but I can attempt to reproduce if you provide some more information.
😸 😷
The library that we are using was linked above - https://github.com/godaddy/asherah (and the linked defect includes a stack trace through their code) The code that triggers this ultimately calls libc mlock:
[DllImport("libc", EntryPoint = "mlock", SetLastError = true)]
private static extern int _mlock(IntPtr start, size_t len);
public int mlock(IntPtr start, size_t len)
{
return _mlock(start, len);
}
Which fails with a -1 / errno=12
We have noticed this issue has not recieved attention in 1 year. We will close this issue for now. If you think this is in error, please feel free to comment and reopen the issue.
This is still an issue for us. The bottom-line is that AWS-lambda has very limited mlock-able memory (64KB in 4KB pages), which creates problems for applications that attempt to protect memory for paging.
@lyricnz Could you please confirm if this is still an issue with latest version of .NET runtime?
Sorry - the project that we were using switched to using a sub-allocator to get away from this mlock() limitation, so is no longer impacted by the problem. Hence I don't have a way to check if the issue still happens. Has the amount of lockable memory changed?
Closing this issue due to lack of traction. Feel free to open a new issue in case scenario is reproducible in latest .NET Lambda runtime.
Comments on closed issues are hard for our team to see. If you need more assistance, please either tag a team member or open a new issue that references this one. If you wish to keep having a conversation with other community members under this issue feel free to do so.