Launching dotnet using mono on macOS will hang if dotnet launches processes #55645
Comments
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
dotnet-issue-labeler
bot
added
the
untriaged
|
Also CC @stephentoub and @steveisok |
What does this mean? And, is this mono built from the dotnet/runtime repo? and
Yes, this violates an assumption that is in the code (
That would be interesting to find out. Can I run these steps on Linux? |
The test case does this: csharp -e 'System.Diagnostics.Process.Start ("dotnet", "test tests.csproj").WaitForExit ();'which is short for something like this: echo 'class Program { static void Main () { System.Diagnostics.Process.Start ("dotnet", "test tests.csproj").WaitForExit ();"); } }' > test.cs
csc test.cs
mono test.exe
It's from the mono/mono repo (this hash in particular: mono/mono@51d876a041e)
Yes, struct sigaction {
union __sigaction_u __sigaction_u; /* signal handler */
sigset_t sa_mask; /* signal mask to apply */
int sa_flags; /* see signal options below */
};
union __sigaction_u {
void (*__sa_handler)(int);
void (*__sa_sigaction)(int, siginfo_t *,
void *);
};
#define sa_handler __sigaction_u.__sa_handler
#define sa_sigaction __sigaction_u.__sa_sigaction
I don't see why not, there's nothing macOS-specific in the test case. |
|
This is how "classic" mono sets up the SIGCHLD handler: Maybe we need to uninstall it in the child after fork before execve (here)? I'm surprised the handler is null but the flags aren't. This is from Apple's
If I read this literally, this means flags other than restart/interrupt aren't inherited by the child and aren't reinstated by Should be able to reproduce the issue by writing a launcher C app that sets a SIGCHLD handler with |
I don't think it's something that mono should change, because if it's something mono does, then somebody else might do it too. IMHO it's something dotnet will just have to cope with. |
|
Unless we're not all in agreement that the potential fix should come from dotnet, @tmds @stephentoub, can I assign the issue to one of you? If we aren't sure, I would like to try to sort it out asap. |
|
Here's some experiment in pure C: build with output on macOS (Big Sur 11.4): So yea, looks like For completeness here's the output from Ubuntu 20.04: |
|
You can assign it to me. |
ghost
added
the
in-pr
steveisok
added
area-System.Runtime.InteropServices
and removed
untriaged
ghost
removed
the
in-pr
ghost
locked as resolved and limited conversation to collaborators
Description
Repro:
Here's a test case: signalbug-521a1b6.zip
make monoto repro: this will executecsharpwhich will executedotnet test(this will hang)make dotnetto rundotnet testdirectly (which works just fine)I did some debugging, and the difference is that the signal handler for SIGCHLD is different when dotnet is launched from a mono process.
Soon after launch, this is what I get when checking the signal handler for SIGCHLD:
The sigaction struct is 16 bytes, where the first 8 bytes are sa_handler, the next 4 bytes are sa_mask, and the final 4 bytes are sa_flags.
This means that:
sa_handler: 0x0 (SIG_DFL)
sa_mask: 0
sa_flags = 0x42 (SA_SIGINFO | SA_RESTART)
man sigactionsays this aboutSA_SIGINFO: "This bit should not be set when assigning SIG_DFL or SIG_IGN.", so the behavior I'm seeing does not follow the spec. That said, if I attach to the mono process, the SIGCHLD handler is very different:so I have no idea why the initial SIGCHLD handler is different in dotnet when dotnet is launched from mono.
The end result is that this will crash:
runtime/src/libraries/Native/Unix/System.Native/pal_signal.c
Lines 214 to 215 in a25bece
and things will go badly from there:
The text was updated successfully, but these errors were encountered: