Skip to content
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.

Sign up for GitHub

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

Enable mono runtime to handle SIGTERM like CoreCLR #82806 #82813

Closed
wants to merge 6 commits into from
Closed

Enable mono runtime to handle SIGTERM like CoreCLR #82806 #82813

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
c07259e
Provide fix for #81093 - "Mono does not emit ProcessExit event on SIG…
nealef Mar 1, 2023
9ac0c3b
* src/libraries/System.Runtime/tests/System/ExitCodeTests.Unix.cs
nealef Mar 13, 2023
98eeadf
* src/mono/mono/mini/mini-runtime.c
nealef Mar 14, 2023
38b5e87
* src/mono/mono/mini/mini-runtime.c
nealef Mar 14, 2023
3adb5d6
* src/mono/mono/metadata/gc.c
nealef Mar 14, 2023
bd9326b
* src/mono/mono/metadata/gc.c
nealef Mar 15, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 0 additions & 1 deletion src/libraries/System.Runtime/tests/System/ExitCodeTests.Unix.cs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,6 @@ public class ExitCodeTests
private static extern int kill(int pid, int sig);

[ConditionalTheory(typeof(RemoteExecutor), nameof(RemoteExecutor.IsSupported))]
[ActiveIssue("https://github.com/dotnet/runtime/issues/31656", TestRuntimes.Mono)]
[InlineData(null)]
[InlineData(0)]
[InlineData(42)]
Expand Down
10 changes: 10 additions & 0 deletions src/mono/mono/metadata/gc.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,6 +24,7 @@
#include <mono/metadata/class-internals.h>
#include <mono/metadata/metadata-internals.h>
#include <mono/metadata/threads-types.h>
#include <mono/metadata/runtime.h>
#include <mono/sgen/sgen-conf.h>
#include <mono/sgen/sgen-gc.h>
#include <mono/utils/mono-logger-internals.h>
Expand Down Expand Up @@ -63,6 +64,8 @@ static gboolean gc_disabled;

static gboolean finalizing_root_domain;

extern gboolean mono_term_signaled;

gboolean mono_log_finalizers;
gboolean mono_do_not_finalize;
static volatile gboolean suspend_finalizers;
Expand Down Expand Up @@ -879,6 +882,7 @@ finalizer_thread (gpointer unused)
mono_hazard_pointer_install_free_queue_size_callback (hazard_free_queue_is_too_big);

while (!finished) {

/* Wait to be notified that there's at least one
* finaliser to run
*/
Expand All @@ -892,6 +896,12 @@ finalizer_thread (gpointer unused)
}
wait = TRUE;

/* Just in case we've received a SIGTERM */
if (mono_term_signaled) {
Copy link
Member

@lateralusX lateralusX Apr 11, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is updated from a different thread without any locking, maybe we would need a read memory barrier to make sure we see updated value, especially when wait == FALSE,. There might be one hidden in the mono_coop_sem_timedwait, looks like at least sem_trywait seems to issue memory barriers, and other implementations probably do as well (like WaitForSingleObjectEx), so maybe not needed in the end, but we depend on implementation details. I guess we can leave it as is for now, just wanted to make a comment/note around potential but adding a read barrier in that code path shouldn't be too dramatic.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that at one point, this PR had mono_term_signaled as volatile.

Maybe that (or something else) is needed to ensure these lines don't reorder, causing the wrong exit code to be picked up.

This is how the exit code is set:

mono_environment_exitcode_set(128+SIGTERM);	/* Set default exit code */
mono_term_signaled = TRUE;

Copy link
Member

@lateralusX lateralusX Apr 17, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can always do acquire/release semantics on mono_term_signaled and we would make sure this is not reordered by compiler or CPU. Just using volatile on mono_term_signaled will only prevent compiler to reorder load/store but CPU is still free to do load/store reorder.

mono_runtime_try_shutdown();
exit(mono_environment_exitcode_get());
}

mono_thread_info_set_flags (MONO_THREAD_INFO_FLAGS_NONE);

/* The Finalizer thread doesn't initialize during creation because base managed
Expand Down
2 changes: 2 additions & 0 deletions src/mono/mono/mini/mini-posix.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -390,6 +390,8 @@ mono_runtime_posix_install_handlers (void)
sigaddset (&signal_set, SIGFPE);
add_signal_handler (SIGQUIT, sigquit_signal_handler, SA_RESTART);
sigaddset (&signal_set, SIGQUIT);
add_signal_handler (SIGTERM, mono_sigterm_signal_handler, SA_RESTART);
sigaddset (&signal_set, SIGTERM);
add_signal_handler (SIGILL, mono_crashing_signal_handler, 0);
sigaddset (&signal_set, SIGILL);
add_signal_handler (SIGBUS, mono_sigsegv_signal_handler, 0);
Expand Down
12 changes: 12 additions & 0 deletions src/mono/mono/mini/mini-runtime.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -118,6 +118,7 @@ const char *mono_build_date;
gboolean mono_do_signal_chaining;
gboolean mono_do_crash_chaining;
int mini_verbose = 0;
gboolean mono_term_signaled = FALSE;

/*
* This flag controls whenever the runtime uses LLVM for JIT compilation, and whenever
Expand Down Expand Up @@ -3628,6 +3629,17 @@ MONO_SIG_HANDLER_FUNC (, mono_crashing_signal_handler)
}
}

MONO_SIG_HANDLER_FUNC (, mono_sigterm_signal_handler)
{
mono_environment_exitcode_set(128+SIGTERM); /* Set default exit code */
nealef marked this conversation as resolved.
Show resolved Hide resolved

mono_term_signaled = TRUE;

mono_gc_finalize_notify ();

mono_chain_signal (MONO_SIG_HANDLER_PARAMS);
}

#if defined(MONO_ARCH_USE_SIGACTION) || defined(HOST_WIN32)

#define HAVE_SIG_INFO
Expand Down
1 change: 1 addition & 0 deletions src/mono/mono/mini/mini-runtime.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -671,6 +671,7 @@ void MONO_SIG_HANDLER_SIGNATURE (mono_sigfpe_signal_handler) ;
void MONO_SIG_HANDLER_SIGNATURE (mono_crashing_signal_handler) ;
void MONO_SIG_HANDLER_SIGNATURE (mono_sigsegv_signal_handler);
void MONO_SIG_HANDLER_SIGNATURE (mono_sigint_signal_handler) ;
void MONO_SIG_HANDLER_SIGNATURE (mono_sigterm_signal_handler) ;
gboolean MONO_SIG_HANDLER_SIGNATURE (mono_chain_signal);

#if defined (HOST_WASM)
Expand Down
1 change: 1 addition & 0 deletions src/mono/mono/mini/mini-windows.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -189,6 +189,7 @@ mono_runtime_install_handlers (void)
win32_seh_set_handler(SIGFPE, mono_sigfpe_signal_handler);
win32_seh_set_handler(SIGILL, mono_crashing_signal_handler);
win32_seh_set_handler(SIGSEGV, mono_sigsegv_signal_handler);
win32_seh_set_handler(SIGTERM, mono_sigterm_signal_handler);
Copy link
Member

@lateralusX lateralusX Mar 15, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is going to work on Windows we also need to handle that signal in win32_seh_set_handler as well as react to the exception that will be generated and passed to seh_vectored_exception_handler.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding the case SIGTERM and the corresponding term_handler variable in exceptions_[x86|amd64] appears straightforward but how are they then used? I see there is exception handling for EXCEPTION_ILLEGAL_INSTRUCTION etc. where the handler is picked up and called, but how and where would this particular signal be fielded?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lateralusX @lambdageek Looking for further guidance on the outstanding Windows' issue.

Copy link
Member

@lateralusX lateralusX Apr 11, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On windows there is no direct mapping with "SIGTERM", the closest we have is the probably SetConsoleCtrlHandler and mapping different scenarios like done by:

runtime/src/libraries/System.Private.CoreLib/src/System/Runtime/InteropServices/PosixSignalRegistration.Windows.cs

Line 70 in 2327a36

private static Interop.BOOL HandlerRoutine(int dwCtrlType)

This is how its handled by CoreCLR:

runtime/src/coreclr/vm/ceemain.cpp

Line 605 in ffffc4b

::SetConsoleCtrlHandler(DbgCtrlCHandler, TRUE/*add*/);

So for Mono Windows handling of "SIGTERM" it probably need to setup a console ctrl handler and then react on the event as part of that handler and can't be handled through existing vectorized exception handling logic.

if (mini_debug_options.handle_sigint)
win32_seh_set_handler(SIGINT, mono_sigint_signal_handler);
#endif
Expand Down