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

lateralusX · 2023-04-11T15:00:22Z

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.

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;

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.

lateralusX · 2023-03-15T09:20:46Z

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.

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?

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

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
privatestaticInterop.BOOLHandlerRoutine(intdwCtrlType)
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.

lateralusX · 2023-04-11T15:00:22Z

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.

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;

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.

lateralusX · 2023-03-15T09:20:46Z

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.

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?

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

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
privatestaticInterop.BOOLHandlerRoutine(intdwCtrlType)
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.

lateralusX · 2023-04-11T15:00:22Z

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.

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;

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.

lateralusX · 2023-03-15T09:20:46Z

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.

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?

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

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
privatestaticInterop.BOOLHandlerRoutine(intdwCtrlType)
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.

lateralusX · 2023-04-11T15:00:22Z

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.

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;

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.

lateralusX · 2023-03-15T09:20:46Z

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.

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?

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

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
privatestaticInterop.BOOLHandlerRoutine(intdwCtrlType)
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.

lateralusX · 2023-04-11T15:00:22Z

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.

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;

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.

lateralusX · 2023-03-15T09:20:46Z

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.

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?

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

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
privatestaticInterop.BOOLHandlerRoutine(intdwCtrlType)
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.

lateralusX · 2023-04-11T15:00:22Z

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.

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;

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.

lateralusX · 2023-03-15T09:20:46Z

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.

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?

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

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
privatestaticInterop.BOOLHandlerRoutine(intdwCtrlType)
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.

lateralusX · 2023-04-11T15:00:22Z

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.

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;

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.

lateralusX · 2023-03-15T09:20:46Z

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.

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?

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

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
privatestaticInterop.BOOLHandlerRoutine(intdwCtrlType)
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.

lateralusX · 2023-04-11T15:00:22Z

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.

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;

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.

lateralusX · 2023-03-15T09:20:46Z

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.

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?

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

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
privatestaticInterop.BOOLHandlerRoutine(intdwCtrlType)
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.

-Original file 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 @@

-Original file 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 DownExpand 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 DownExpand 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) {
+ 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 @@

-Original file 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 @@

-Original file 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 DownExpand 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 */
+	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 @@

-Original file line number
+Diff line change
@@ Expand Up @@
 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 @@

Uh oh!

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

Uh oh!

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

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

lateralusXApr 11, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lateralusXApr 17, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

lateralusXMar 15, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lateralusXApr 11, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

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

Uh oh!

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

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

lateralusXApr 11, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lateralusXApr 17, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

lateralusXMar 15, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lateralusXApr 11, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

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

Uh oh!

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

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

lateralusXApr 11, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lateralusXApr 17, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

lateralusXApr 11, 2023•
edited
Loading

lateralusXApr 17, 2023•
edited
Loading

lateralusXMar 15, 2023•
edited
Loading

lateralusXApr 11, 2023•
edited
Loading

lateralusXApr 11, 2023•
edited
Loading

lateralusXApr 17, 2023•
edited
Loading

lateralusXMar 15, 2023•
edited
Loading

lateralusXApr 11, 2023•
edited
Loading

lateralusXApr 11, 2023•
edited
Loading

lateralusXApr 17, 2023•
edited
Loading

lateralusXMar 15, 2023•
edited
Loading

lateralusXApr 11, 2023•
edited
Loading

lateralusXApr 11, 2023•
edited
Loading

lateralusXApr 17, 2023•
edited
Loading

lateralusXMar 15, 2023•
edited
Loading