[CoreCLR][Signal] Bump shutdown notif and crashdump before prev handler #123735

mdh1418 · 2026-01-28T23:12:22Z

The previously registered signal action/handler aren't guaranteed to return, so we lose out on notifying shutdown and creating a dump in those cases. Specifically, PROCCreateCrashDumpIfEnabled would be the last chance to provide the managed context for the thread that crashed.

e.g. On Android CoreCLR, it seems that, by default, signal handlers are already registered by Android's runtime (/apex/com.android.runtime/bin/linker64 + /system/lib64/libandroid_runtime.so). Whenever an unhandled synchronous fault occurs, the previously registered handler will not return back to invoke_previous_action and aborts the thread itself, so PROCCreateCrashDumpIfEnabled will not be hit.

Sigsegv behavior Android CoreCLR vs other platforms

Android CoreCLR

When intentionally writing to NULL (sigsegv) on Android CoreCLR, the previously registered signal handler goes down this path

runtime/src/coreclr/pal/src/exception/signal.cpp

Line 454 in 40e8c73

action->sa_sigaction(code, siginfo, context);

, and the thread aborts before hitting PROCNotifyProcessShutdown and PROCCreateCrashDumpIfEnabled.

MacOS/Linux/NativeAOT(linux)

On MacOS, Linux, NativeAOT (Only checked linux at time of writing), the same intentional SIGSEGV will hit

runtime/src/coreclr/pal/src/exception/signal.cpp

Lines 431 to 448 in 40e8c73

    
           if (signalRestarts) 
        
           { 
        
               // Shutdown and create the core dump before we restore the signal to the default handler. 
        
               PROCNotifyProcessShutdown(IsRunningOnAlternateStack(context)); 
        
               PROCCreateCrashDumpIfEnabled(code, siginfo, context, true); 
        
               // Restore the original and restart h/w exception. 
        
               restore_signal(code, action); 
        
               return; 
        
           } 
        
           else 
        
           { 
        
               // We can't invoke the original handler because returning from the 
        
               // handler doesn't restart the exception. 
        
               PROCAbort(code, siginfo, context); 
        
           }

instead because there is no previously registered signal handler. In those cases, PROCCreateCrashDumpIfEnabled is hit and managed callstacks are captured in the dump.

History investigation

From a github history dive, I didn't spot anything in particular requiring the previous signal handler to be invoked before PROCNotifyProcessShutdown + PROCCreateCrashDumpIfEnabled.

PROCNotifyProcessShutdown was first introduced in 1433c3f. It doesn't seem to state a particular reason for invoking it after the previous signal handler.

PROCCreateCrashDumpIfEnabled was added to signal.cpp in 7f9bd2c because the PROCNotifyProcessShutdown didn't create a crash dump. It doesn't state any particular reason for being invoked after the previously registered signal handler, and was probably just placed next to PROCNotifyProcessShutdown.

invoke_previous_action was introduced in a740f65 and was refactoring while maintaining the order.

Android CoreCLR behavior after swapping order

Locally, I have POC changes to emit managed callstacks in Android's PROCCreateCrashDumpIfEnabled.

01-28 17:26:40.951  2416  2440 F DOTNET  : Native crash detected; attempting managed stack trace.
01-28 17:26:40.951  2416  2440 F DOTNET  : {"stack":[
01-28 17:26:40.951  2416  2440 F DOTNET  : {"ip":"0x0","module":"0x0","offset":"0x0","name":"Program.MemSet(Void*, Int32, UIntPtr)"},
01-28 17:26:40.951  2416  2440 F DOTNET  : {"ip":"0x78d981145973","module":"0x0","offset":"0x0","name":"Program.MemSet(Void*, Int32, UIntPtr)"},
01-28 17:26:40.951  2416  2440 F DOTNET  : {"ip":"0x78d981145973","module":"0x0","offset":"0x73","name":"Program.ForceNativeSegv()"},
01-28 17:26:40.951  2416  2440 F DOTNET  : {"ip":"0x78d981141b60","module":"0x0","offset":"0x70","name":"Program.Main(System.String[])"}
01-28 17:26:40.951  2416  2440 F DOTNET  : ]}
01-28 17:26:40.952  2416  2440 F DOTNET  : Crash dump hook completed.
--------- beginning of crash
01-28 17:26:40.952  2416  2440 F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 2440 (.dot.MonoRunner), pid 2416 (ulator.JIT.Test)
.....
01-28 17:26:46.882  2921  2921 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
01-28 17:26:46.882  2921  2921 F DEBUG   : Build fingerprint: 'google/sdk_gphone64_x86_64/emu64xa:16/BE2A.250530.026.D1/13818094:user/release-keys'
01-28 17:26:46.882  2921  2921 F DEBUG   : Revision: '0'
01-28 17:26:46.882  2921  2921 F DEBUG   : ABI: 'x86_64'
01-28 17:26:46.882  2921  2921 F DEBUG   : Timestamp: 2026-01-28 17:26:41.492831700-0500
01-28 17:26:46.882  2921  2921 F DEBUG   : Process uptime: 20s
01-28 17:26:46.883  2921  2921 F DEBUG   : Cmdline: net.dot.Android.Device_Emulator.JIT.Test
01-28 17:26:46.883  2921  2921 F DEBUG   : pid: 2416, tid: 2440, name: .dot.MonoRunner  >>> net.dot.Android.Device_Emulator.JIT.Test <<<
01-28 17:26:46.883  2921  2921 F DEBUG   : uid: 10219
01-28 17:26:46.883  2921  2921 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0000000000000000
01-28 17:26:46.883  2921  2921 F DEBUG   : Cause: null pointer dereference
01-28 17:26:46.883  2921  2921 F DEBUG   : Abort message: 'CoreCLR: previous handler for '
01-28 17:26:46.883  2921  2921 F DEBUG   :     rax 0000000000000000  rbx 000078da87ffade0  rcx 0000000000000000  rdx 0000000000000001
01-28 17:26:46.884  1237  1297 I s.nexuslauncher: AssetManager2(0x78dd08cd9178) locale list changing from [] to [en-US]
01-28 17:26:46.903  2447  2594 I BugleNotifications: Creating notification input ids [CONTEXT im_entry_input="" im_notification_input="" im_settings_store_input="" im_final_input="" ]
01-28 17:26:46.905  2921  2921 F DEBUG   :     r8  00007ffcde5a8080  r9  34d9bb0e67871eb0  r10 000078ddb4111870  r11 0000000000000293
01-28 17:26:46.906  2921  2921 F DEBUG   :     r12 0000000000000001  r13 000078da87ffafa0  r14 0000000000000000  r15 000078da87ffaf18
01-28 17:26:46.906  2921  2921 F DEBUG   :     rdi 0000000000000000  rsi 0000000000000000
01-28 17:26:46.906  2921  2921 F DEBUG   :     rbp 000078da87ffac40  rsp 000078da87ffabc8  rip 000078ddb41118a2
01-28 17:26:46.906  2921  2921 F DEBUG   : 2 total frames
01-28 17:26:46.906  2921  2921 F DEBUG   : backtrace:
01-28 17:26:46.906  2921  2921 F DEBUG   :       #00 pc 000000000008f8a2  /apex/com.android.runtime/lib64/bionic/libc.so (memset_avx2+50) (BuildId: fcb82240218d1473de1e3d2137c0be35)
01-28 17:26:46.906  2921  2921 F DEBUG   :       #01 pc 0000000000049972  /memfd:doublemapper (deleted) (offset 0x111000)

Now theres a window to log managed callstacks before the original signal handler aborts and triggers a tombstone.

Android Mono behavior

Mono provides two embeddings APIs to configure signal and crash chaining

runtime/src/mono/mono/mini/driver.c

Lines 2864 to 2894 in 61d3943

    
           /** 
        
            * mono_set_signal_chaining: 
        
            * 
        
            * Enable/disable signal chaining. This should be called before \c mono_jit_init. 
        
            * If signal chaining is enabled, the runtime saves the original signal handlers before 
        
            * installing its own handlers, and calls the original ones in the following cases: 
        
            * - a \c SIGSEGV / \c SIGABRT signal received while executing native (i.e. not JITted) code. 
        
            * - \c SIGPROF 
        
            * - \c SIGFPE 
        
            * - \c SIGQUIT 
        
            * - \c SIGUSR2 
        
            * Signal chaining only works on POSIX platforms. 
        
            */ 
        
           void 
        
           mono_set_signal_chaining (gboolean chain_signals) 
        
           { 
        
           	mono_do_signal_chaining = chain_signals; 
        
           } 
        
           /** 
        
            * mono_set_crash_chaining: 
        
            * 
        
            * Enable/disable crash chaining due to signals. When a fatal signal is delivered and 
        
            * Mono doesn't know how to handle it, it will invoke the crash handler. If chrash chaining 
        
            * is enabled, it will first print its crash information and then try to chain with the native handler. 
        
            */ 
        
           void 
        
           mono_set_crash_chaining (gboolean chain_crashes) 
        
           { 
        
           	mono_do_crash_chaining = chain_crashes; 
        
           }

that determine whether synchronous faults would chain

runtime/src/mono/mono/mini/mini-runtime.c

Lines 3892 to 3903 in 61d3943

    
           if (!ji) { 
        
           	if (!mono_do_crash_chaining && mono_chain_signal (MONO_SIG_HANDLER_PARAMS)) 
        
           		return; 
        
           	mono_handle_native_crash (mono_get_signame (SIGSEGV), &mctx, (MONO_SIG_HANDLER_INFO_TYPE*)info); 
        
           	if (mono_do_crash_chaining) { 
        
           		if (!mono_chain_signal (MONO_SIG_HANDLER_PARAMS)) 
        
           			mono_chain_signal_to_default_sigsegv_handler (); 
        
           		return; 
        
           	} 
        
           }

They would only chain to the previous signal handler

runtime/src/mono/mono/mini/mini-posix.c

Lines 193 to 210 in 61d3943

    
           gboolean 
        
           MONO_SIG_HANDLER_SIGNATURE (mono_chain_signal) 
        
           { 
        
           	int signal = MONO_SIG_HANDLER_GET_SIGNO (); 
        
           	struct sigaction *saved_handler = (struct sigaction *)get_saved_signal_handler (signal); 
        
           	// Ignores chaining to default signal handlers i.e. when saved_handler->sa_handler == SIG_DFL 
        
           	if (saved_handler && saved_handler->sa_handler) { 
        
           		if (!(saved_handler->sa_flags & SA_SIGINFO)) { 
        
           			saved_handler->sa_handler (signal); 
        
           		} else { 
        
           #ifdef MONO_ARCH_USE_SIGACTION 
        
           			saved_handler->sa_sigaction (MONO_SIG_HANDLER_PARAMS); 
        
           #endif /* MONO_ARCH_USE_SIGACTION */ 
        
           		} 
        
           		return TRUE; 
        
           	} 
        
           	return FALSE;

only after attempting to walk native and managed stacks

runtime/src/mono/mono/mini/mini-exceptions.c

Lines 2992 to 3012 in 61d3943

    
           g_async_safe_printf("\n=================================================================\n"); 
        
           g_async_safe_printf("\tNative Crash Reporting\n"); 
        
           g_async_safe_printf("=================================================================\n"); 
        
           g_async_safe_printf("Got a %s while executing native code. This usually indicates\n", signal); 
        
           g_async_safe_printf("a fatal error in the mono runtime or one of the native libraries \n"); 
        
           g_async_safe_printf("used by your application.\n"); 
        
           g_async_safe_printf("=================================================================\n"); 
        
           mono_dump_native_crash_info (signal, mctx, info); 
        
           /* !jit_tls means the thread was not registered with the runtime */ 
        
           // This must be below the native crash dump, because we can't safely 
        
           // do runtime state probing after we have walked the managed stack here. 
        
           if (jit_tls && mono_thread_internal_current () && mctx) { 
        
           	g_async_safe_printf ("\n=================================================================\n"); 
        
           	g_async_safe_printf ("\tManaged Stacktrace:\n"); 
        
           	g_async_safe_printf ("=================================================================\n"); 
        
           	mono_walk_stack_full (print_stack_frame_signal_safe, mctx, jit_tls, mono_get_lmf (), MONO_UNWIND_LOOKUP_IL_OFFSET | MONO_UNWIND_SIGNAL_SAFE, NULL); 
        
           	g_async_safe_printf ("=================================================================\n"); 
        
           }

Alternatives

If there is any particular reason to preserve the order of sa_sigaction/sa_handler with respect to PROCNotifyProcessShutdown and PROCCreateCrashDumpIfEnabled for CoreCLR, a config knob can be added to allow Android CoreCLR to opt into the swapped ordering behavior. This may be in the form of config property key/values

runtime/src/coreclr/dlls/mscoree/exports.cpp

Lines 237 to 238 in 54ca569

    
           const char** propertyKeys, 
        
           const char** propertyValues,

or clrconfigvalues. That way AndroidSDK/AndroidAppBuilder may opt-in at build-time.

Given that the history of the ordering didn't reveal any problems with swapping the order, we can fallback to this behavior if the order swap causes problems down the line.

The other way around is more restrictive. Should we first introduce all the overhead to enable an opt-in/opt-out config knob, and later discover that no platforms need to invoke their previous handlers before PROCNotifyProcessShutdown/PROCCreateCrashDumpIfEnabled, it seems harder to justify removing the knob.

Copilot

Pull request overview

Adjusts CoreCLR’s signal chaining so shutdown notification and crash dump creation happen before invoking a previously-registered signal handler, ensuring these steps still run when the prior handler doesn’t return (notably on Android).

Changes:

Reorders PROCNotifyProcessShutdown and PROCCreateCrashDumpIfEnabled to run before chaining to the prior sigaction handler.
Adds an assertion to document/enforce that the “custom handler” path isn’t reached for SIG_DFL/SIG_IGN.

jkotas · 2026-01-28T23:42:53Z

src/coreclr/pal/src/exception/signal.cpp

+
+    _ASSERTE(!IsSigDfl(action) && !IsSigIgn(action));
+
+    PROCNotifyProcessShutdown(IsRunningOnAlternateStack(context));


I do not think this works well when there are multiple runtimes loaded in the process that all want to handle segfaults. It can be multiple .NET runtimes (e.g. CoreCLR + NAOT, or multiple NAOT), or it can be .NET and some other runtime (e.g. Java runtime).

The expected behavior in these situations is that the given runtime will check whether the signal happened in the code that it cares about. If yes, it will handle the signal. If no, it will forward the signal to the next runtime, and so on.

With this change, I think we will shutdown our runtime instance and generate crashdump if there is segfault gracefully handled by some other runtime.

Gracefully handled by another runtime, as in sa_sigaction/sa_handler? Wouldn't those still hit PROCNotifyProcessShutdown/PROCCreateCrashDumpIfEnabled in the original implementation? Or do they somehow return from invoke_previous_action

If the signal is handled in some other runtime, the handler registered by that runtime would not return.

I see, so given that we cannot tell how the other runtime will handle the signal, would it make sense then to pivot to an opt-in config switch that allows triggering a shutdown/create dump, even if the other runtime handled it gracefully?

I am not sure yet if there is a way for Android CoreCLR to not have a previously registered signal handler, so in those cases we wouldn't ever create crash dumps for signals.

Do we know what the handlers that are registered on Android before us do?

I don't have the expertise to discover exactly what handlers are reigstered, but with Copilot CLI's help I think I was able to connect them to android runtime's stuff

01-27 18:34:20.359 30541 30565 F DOTNET : CoreCLR: previous handler for 01-27 18:34:20.359 30541 30565 F DOTNET : SIGILL 01-27 18:34:20.359 30541 30565 F DOTNET : : 01-27 18:34:20.359 30541 30565 F DOTNET : handler= 01-27 18:34:20.359 30541 30565 F DOTNET : 0x0000746225158743 01-27 18:34:20.365 30541 30565 F DOTNET : dladdr failed 01-27 18:34:20.371 30541 30565 F DOTNET : /proc/self/maps: 01-27 18:34:20.371 30541 30565 F DOTNET : 7462250ab000-7462251e4000 r-xp 00044000 07:c0 14 /apex/com.android.runtime/bin/linker64 01-27 18:34:20.372 30541 30565 F DOTNET : CoreCLR: previous handler for 01-27 18:34:20.375 30541 30565 F DOTNET : SIGFPE 01-27 18:34:20.375 30541 30565 F DOTNET : : 01-27 18:34:20.375 30541 30565 F DOTNET : handler= 01-27 18:34:20.375 30541 30565 F DOTNET : 0x0000746225158743 01-27 18:34:20.375 30541 30565 F DOTNET : dladdr failed 01-27 18:34:20.378 30541 30565 F DOTNET : /proc/self/maps: 01-27 18:34:20.378 30541 30565 F DOTNET : 7462250ab000-7462251e4000 r-xp 00044000 07:c0 14 /apex/com.android.runtime/bin/linker64 01-27 18:34:20.379 30541 30565 F DOTNET : CoreCLR: previous handler for 01-27 18:34:20.379 30541 30565 F DOTNET : SIGBUS 01-27 18:34:20.379 30541 30565 F DOTNET : : 01-27 18:34:20.379 30541 30565 F DOTNET : handler= 01-27 18:34:20.379 30541 30565 F DOTNET : 0x0000746204cf1c90 01-27 18:34:20.379 30541 30565 F DOTNET : module_base= 01-27 18:34:20.379 30541 30565 F DOTNET : 0x0000746204a81000 01-27 18:34:20.379 30541 30565 F DOTNET : module= 01-27 18:34:20.380 30541 30565 F DOTNET : /system/lib64/libandroid_runtime.so 01-27 18:34:20.380 30541 30565 F DOTNET : symbol= 01-27 18:34:20.380 30541 30565 F DOTNET : _ZN5incfs13SignalHandler7handlerEiP7siginfoPv 01-27 18:34:20.380 30541 30565 F DOTNET : symbol_addr= 01-27 18:34:20.380 30541 30565 F DOTNET : 0x0000746204cf1c90 01-27 18:34:20.381 30541 30565 F DOTNET : /proc/self/maps: 01-27 18:34:20.381 30541 30565 F DOTNET : 746204b5d000-746204d14000 r-xp 000dc000 fe:05 16575744 /system/lib64/libandroid_runtime.so 01-27 18:34:20.381 30541 30565 F DOTNET : CoreCLR: previous handler for 01-27 18:34:20.381 30541 30565 F DOTNET : SIGABRT 01-27 18:34:20.381 30541 30565 F DOTNET : : 01-27 18:34:20.381 30541 30565 F DOTNET : handler= 01-27 18:34:20.381 30541 30565 F DOTNET : 0x0000746225158743 01-27 18:34:20.382 30541 30565 F DOTNET : dladdr failed 01-27 18:34:20.385 30541 30565 F DOTNET : /proc/self/maps: 01-27 18:34:20.385 30541 30565 F DOTNET : 7462250ab000-7462251e4000 r-xp 00044000 07:c0 14 /apex/com.android.runtime/bin/linker64 01-27 18:34:20.385 30541 30565 F DOTNET : CoreCLR: previous handler for 01-27 18:34:20.385 30541 30565 F DOTNET : SIGINT 01-27 18:34:20.385 30541 30565 F DOTNET : : 01-27 18:34:20.385 30541 30565 F DOTNET : SIG_DFL 01-27 18:34:20.385 30541 30565 F DOTNET : CoreCLR: previous handler for 01-27 18:34:20.385 30541 30565 F DOTNET : SIGQUIT 01-27 18:34:20.385 30541 30565 F DOTNET : : 01-27 18:34:20.386 30541 30565 F DOTNET : SIG_DFL 01-27 18:34:20.386 30541 30565 F DOTNET : CoreCLR: previous handler for 01-27 18:34:20.386 30541 30565 F DOTNET : SIGTRAP 01-27 18:34:20.386 30541 30565 F DOTNET : : 01-27 18:34:20.386 30541 30565 F DOTNET : handler= 01-27 18:34:20.386 30541 30565 F DOTNET : 0x0000746225158743 01-27 18:34:20.386 30541 30565 F DOTNET : dladdr failed 01-27 18:34:20.393 30541 30565 F DOTNET : /proc/self/maps: 01-27 18:34:20.393 30541 30565 F DOTNET : 7462250ab000-7462251e4000 r-xp 00044000 07:c0 14 /apex/com.android.runtime/bin/linker64 01-27 18:34:20.393 30541 30565 F DOTNET : CoreCLR: previous handler for 01-27 18:34:20.393 30541 30565 F DOTNET : SIGSEGV 01-27 18:34:20.393 30541 30565 F DOTNET : : 01-27 18:34:20.393 30541 30565 F DOTNET : handler= 01-27 18:34:20.393 30541 30565 F DOTNET : 0x0000746225158743 01-27 18:34:20.393 30541 30565 F DOTNET : dladdr failed 01-27 18:34:20.395 30541 30565 F DOTNET : /proc/self/maps: 01-27 18:34:20.395 30541 30565 F DOTNET : 7462250ab000-7462251e4000 r-xp 00044000 07:c0 14 /apex/com.android.runtime/bin/linker64 01-27 18:34:20.395 30541 30565 F DOTNET : CoreCLR: previous handler for 01-27 18:34:20.395 30541 30565 F DOTNET : SIGTERM 01-27 18:34:20.395 30541 30565 F DOTNET : : 01-27 18:34:20.395 30541 30565 F DOTNET : SIG_DFL 01-27 18:34:20.395 30541 30565 F DOTNET : CoreCLR: previous handler for 01-27 18:34:20.395 30541 30565 F DOTNET : INJECT_ACTIVATION_SIGNAL 01-27 18:34:20.395 30541 30565 F DOTNET : : 01-27 18:34:20.395 30541 30565 F DOTNET : SIG_DFL

@grendello, would you happen to know how to tell what signal handlers might be registered by default on Android?

would it make sense then to pivot to an opt-in config switch that allows triggering a shutdown/create dump, even if the other runtime handled it gracefully?

I wonder if for such opt-in, we should just create a dump and instead of shutting down proceed to the other registered handler to be a good citizen of the Android ecosystem?

I wonder if for such opt-in, we should just create a dump and instead of shutting down proceed to the other registered handler to be a good citizen of the Android ecosystem?

That can lead to things slowing down to crawl if the other runtime sends and handles multiple instances of the signal over a short period of time. There is no clear winner here.

I agree that this should be an opt-in.

That way AndroidSDK/AndroidAppBuilder may opt-in at build-time.

We may want to enumerate the scenarios for collecting a crash dump. For example, is collecting a crash dump of a appstore-installed app on retail device something we want to enable?

[CoreCLR][Signal] Bump shutdown notif and crashdump before prev handler

5be9bbf

mdh1418 requested review from Copilot, janvorli, jkotas, lateralusX, noahfalk and tmds January 28, 2026 23:12

mdh1418 added the area-ExceptionHandling-coreclr label Jan 28, 2026

dotnet-policy-service bot assigned mdh1418 Jan 28, 2026

Copilot started reviewing on behalf of mdh1418 January 28, 2026 23:13 View session

Copilot AI reviewed Jan 28, 2026

View reviewed changes

jkotas reviewed Jan 28, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[CoreCLR][Signal] Bump shutdown notif and crashdump before prev handler #123735

[CoreCLR][Signal] Bump shutdown notif and crashdump before prev handler #123735

mdh1418 commented Jan 28, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

jkotas Jan 28, 2026 •

edited

Loading

Uh oh!

mdh1418 Jan 29, 2026

Uh oh!

janvorli Jan 29, 2026

Uh oh!

mdh1418 Jan 29, 2026

Uh oh!

janvorli Jan 29, 2026

Uh oh!

mdh1418 Jan 29, 2026

Uh oh!

janvorli Jan 29, 2026

Uh oh!

jkotas Jan 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

	if (signalRestarts)
	{
	// Shutdown and create the core dump before we restore the signal to the default handler.
	PROCNotifyProcessShutdown(IsRunningOnAlternateStack(context));

	PROCCreateCrashDumpIfEnabled(code, siginfo, context, true);

	// Restore the original and restart h/w exception.
	restore_signal(code, action);

	return;
	}
	else
	{
	// We can't invoke the original handler because returning from the
	// handler doesn't restart the exception.
	PROCAbort(code, siginfo, context);
	}

	/**
	* mono_set_signal_chaining:
	*
	* Enable/disable signal chaining. This should be called before \c mono_jit_init.
	* If signal chaining is enabled, the runtime saves the original signal handlers before
	* installing its own handlers, and calls the original ones in the following cases:
	* - a \c SIGSEGV / \c SIGABRT signal received while executing native (i.e. not JITted) code.
	* - \c SIGPROF
	* - \c SIGFPE
	* - \c SIGQUIT
	* - \c SIGUSR2
	* Signal chaining only works on POSIX platforms.
	*/
	void
	mono_set_signal_chaining (gboolean chain_signals)
	{
	mono_do_signal_chaining = chain_signals;
	}

	/**
	* mono_set_crash_chaining:
	*
	* Enable/disable crash chaining due to signals. When a fatal signal is delivered and
	* Mono doesn't know how to handle it, it will invoke the crash handler. If chrash chaining
	* is enabled, it will first print its crash information and then try to chain with the native handler.
	*/
	void
	mono_set_crash_chaining (gboolean chain_crashes)
	{
	mono_do_crash_chaining = chain_crashes;
	}

	if (!ji) {
	if (!mono_do_crash_chaining && mono_chain_signal (MONO_SIG_HANDLER_PARAMS))
	return;

	mono_handle_native_crash (mono_get_signame (SIGSEGV), &mctx, (MONO_SIG_HANDLER_INFO_TYPE*)info);

	if (mono_do_crash_chaining) {
	if (!mono_chain_signal (MONO_SIG_HANDLER_PARAMS))
	mono_chain_signal_to_default_sigsegv_handler ();
	return;
	}
	}

	gboolean
	MONO_SIG_HANDLER_SIGNATURE (mono_chain_signal)
	{
	int signal = MONO_SIG_HANDLER_GET_SIGNO ();
	struct sigaction saved_handler = (struct sigaction )get_saved_signal_handler (signal);

	// Ignores chaining to default signal handlers i.e. when saved_handler->sa_handler == SIG_DFL
	if (saved_handler && saved_handler->sa_handler) {
	if (!(saved_handler->sa_flags & SA_SIGINFO)) {
	saved_handler->sa_handler (signal);
	} else {
	#ifdef MONO_ARCH_USE_SIGACTION
	saved_handler->sa_sigaction (MONO_SIG_HANDLER_PARAMS);
	#endif /* MONO_ARCH_USE_SIGACTION */
	}
	return TRUE;
	}
	return FALSE;

	g_async_safe_printf("\n=================================================================\n");
	g_async_safe_printf("\tNative Crash Reporting\n");
	g_async_safe_printf("=================================================================\n");
	g_async_safe_printf("Got a %s while executing native code. This usually indicates\n", signal);
	g_async_safe_printf("a fatal error in the mono runtime or one of the native libraries \n");
	g_async_safe_printf("used by your application.\n");
	g_async_safe_printf("=================================================================\n");
	mono_dump_native_crash_info (signal, mctx, info);

	/* !jit_tls means the thread was not registered with the runtime */
	// This must be below the native crash dump, because we can't safely
	// do runtime state probing after we have walked the managed stack here.
	if (jit_tls && mono_thread_internal_current () && mctx) {
	g_async_safe_printf ("\n=================================================================\n");
	g_async_safe_printf ("\tManaged Stacktrace:\n");
	g_async_safe_printf ("=================================================================\n");

	mono_walk_stack_full (print_stack_frame_signal_safe, mctx, jit_tls, mono_get_lmf (), MONO_UNWIND_LOOKUP_IL_OFFSET \| MONO_UNWIND_SIGNAL_SAFE, NULL);

	g_async_safe_printf ("=================================================================\n");
	}


		_ASSERTE(!IsSigDfl(action) && !IsSigIgn(action));

		PROCNotifyProcessShutdown(IsRunningOnAlternateStack(context));

[CoreCLR][Signal] Bump shutdown notif and crashdump before prev handler #123735

Are you sure you want to change the base?

[CoreCLR][Signal] Bump shutdown notif and crashdump before prev handler #123735

Conversation

mdh1418 commented Jan 28, 2026

Sigsegv behavior Android CoreCLR vs other platforms

Android CoreCLR

MacOS/Linux/NativeAOT(linux)

History investigation

Android CoreCLR behavior after swapping order

Android Mono behavior

Alternatives

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

jkotas Jan 28, 2026 • 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!

mdh1418 Jan 29, 2026

Choose a reason for hiding this comment

Uh oh!

janvorli Jan 29, 2026

Choose a reason for hiding this comment

Uh oh!

mdh1418 Jan 29, 2026

Choose a reason for hiding this comment

Uh oh!

janvorli Jan 29, 2026

Choose a reason for hiding this comment

Uh oh!

mdh1418 Jan 29, 2026

Choose a reason for hiding this comment

Uh oh!

janvorli Jan 29, 2026

Choose a reason for hiding this comment

Uh oh!

jkotas Jan 29, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

jkotas Jan 28, 2026 •

edited

Loading