-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Microsoft.CodeAnalysis.CSharp.Scripting causes Too many open files when ran multiple times #42134
Comments
cc @tmat |
Experiencing the same issue on Ubuntu 18.04 LTS |
Hello, |
@ReginaldBull I am pretty sure this issue is related to @tmat mentioned in those issues that assembly unloading is not supported at the moment which I believe might be causing the opened files. If your implementation resuses the same code a lot, You can reduce the affects quite a bit by building the script then executing it multiple times. https://github.com/dotnet/roslyn/wiki/Scripting-API-Samples#multi I was able to get drastically better results by doing this but your mileage will vary by how much reuse of the same code you use. |
I've tried manually loading and unloading the compilation via CSharpCompilation and AssemblyLoadContext.Unload, it does behave better, but still eventually hangs or dies with "Too many open files". |
Update: I found my mistake with AssemblyLoadContext. If you want to get around these leaks you can follow roughly what I was doing in this test project here: https://github.com/dave-yotta/roslyn-assemblyunload |
Version Used:
3.4.0
Steps to Reproduce:
CentOS Linux release 7.6.1810 (Core)
var objectResult = await CSharpScript.EvaluateAsync("return 1");
in a controller.Expected Behavior:
For the scripting API to close files after it is done with them.
Actual Behavior:
/dev/zero is opened until the server reaches it's max limit of open files and the following error occurs and asp.net core locks up not able to accept any more requests.
Everything with namespace
UptimeRMX
is my project.Upon inspection of the files opened, I see most of the files are opened to
/dev/zero
and the number increases every time the above command is ran.I am reporting on how many open files there are to /dev/zero with the following command:
You can get the problem to happen very quickly if you execute it in a loop
The text was updated successfully, but these errors were encountered: