[Big Sur] open() vs SA_RESTART #48663
Labels
Milestone
Comments
dotnet-issue-labeler
bot
added
area-PAL-coreclr
untriaged
|
Maybe related to #47584 ? |
|
Here is the workaround going into git https://lore.kernel.org/git/[email protected]/ |
|
Nice. I wonder if we should at least file a radar with Apple? |
3 tasks
lambdageek
added a commit
to lambdageek/mono
that referenced
this issue
Apr 29, 2021
Related to mono#21040 and dotnet/runtime#48663 On MacOS Big Sur open() is much more likely to throw EINTR - and moreover if the thread receives a signal while doing an open() even if the signal handler is marked with SA_RESTART, the open call appears not to restart and to fail anyway. So wrap all the calls to open() in retry loops.
lambdageek
added a commit
to lambdageek/mono
that referenced
this issue
Apr 29, 2021
Related to mono#21040 and dotnet/runtime#48663 On MacOS Big Sur open() is much more likely to throw EINTR - and moreover if the thread receives a signal while doing an open() even if the signal handler is marked with SA_RESTART, the open call appears not to restart and to fail anyway. So wrap all the calls to open() in retry loops.
lambdageek
added a commit
to mono/mono
that referenced
this issue
Apr 30, 2021
Related to #21040 and dotnet/runtime#48663 On MacOS Big Sur open() is much more likely to throw EINTR - and moreover if the thread receives a signal while doing an open() even if the signal handler is marked with SA_RESTART, the open call appears not to restart and to fail anyway. So wrap all the calls to open() in retry loops.
lambdageek
added a commit
to mono/mono
that referenced
this issue
Apr 30, 2021
Related to #21040 and dotnet/runtime#48663 On MacOS Big Sur open() is much more likely to throw EINTR - and moreover if the thread receives a signal while doing an open() even if the signal handler is marked with SA_RESTART, the open call appears not to restart and to fail anyway. So wrap all the calls to open() in retry loops.
|
Hi @lambdageek, is this a mono specific tracking issue? |
|
@mangod9 No. It's a potential issue for CoreCLR, Mono and the System.Native libraries interop code. All calls to |
|
I think it would not hurt to wrap all calls to open in a loop checking for EINTR. I'll make a PR for the non-mono parts. |
ghost
added
the
in-pr
ghost
removed
the
in-pr
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
It appears that on MacOS Big Sur,
opencan sometimes returnEINTRif it is interrupted by a signal even if the signal has a handler installed withSA_RESTART.SA_RESTARTflags. (although this is not the default - we prefer to use Mach suspend/resume operations)SA_RESTARTWe should make sure that all our calls to
openhandleEINTR.To be clear, I haven't seen this cause a problem for .NET that can be clearly attributed to this issue. Until we catch it in a repro, this is just a placeholder issue - unless we want to be proactive about mitigating.
(This is affecting other software too.
git, for example. It has affected some runtime engineers -git clone --progress https://github.com/dotnet/runtimewill sometimes fail withinterrupted system callerrors and leave the working tree in an unusable state. The workaround is to callgit clone --quiet(note that--progressis the default))The issue seems to be exacerbated by some antivirus software, even if "real time protection" is turned off.
The text was updated successfully, but these errors were encountered: