[debugger] Removing usage of mono_unhandled_exception #4927
Conversation
|
@thaystg, @jonathanpeppers: "semantics" question: if you have a managed1 > managed2 call stack in which managed2 throws an exception which is caught by managed1: public void managed1 ()
{
try {
managed2 ();
}
catch (Exception e) {
Console.WriteLine (e);
}
}
public void managed1 ()
{
throw new Exception ("Wee!");
}what happens when ^^ is run within the debugger? Will we get a "first chance exception" on the How does this align with what .NET & Visual Studio do (no mono in the picture)? |
|
Visual Studio on Windows can break on this line: throw new Exception ("Wee!");But only if you have the
VS for Mac probably has something similar? |
|
@jonathanpeppers: which indicates the Visual Studio with .NET has a first-chance exception, which is entirely expected. :-) I'm not at all sure how to reasonably test the "last chance notification": https://docs.microsoft.com/en-us/windows/win32/debug/debugger-exception-handling
i.e. if Regardless, the question here isn't entirely about "VS with .NET", it's about "VS with Mono with @thaystg's changes". What happens there? |
|
I've tested with my PR using VSMac and mono, and VSMac can break on this line: |
…bugger handle with an exception when running on android. The biggest difference is on xamarin-android side. Relates to dotnet/android#4927
Trying to remove the usage of unhandled_exception function to make debugger handle with an exception when running on android. The biggest difference is on xamarin-android side. Where I removed the try catch added when generating dynamic methods while debugging and let the debugger handle the caught or uncaught exceptions. Relates to dotnet/android#4927
| @@ -51,26 +51,34 @@ public static Delegate CreateDelegate (Delegate dlg) | |||
|
|
|||
| ig.Emit (OpCodes.Call, wait_for_bridge_processing_method!); | |||
|
|
|||
| var label = ig.BeginExceptionBlock (); | |||
| bool filter = Debugger.IsAttached || !JNIEnv.PropagateExceptions; | |||
| if (!filter) { | |||
There was a problem hiding this comment.
@thaystg: This presents a question: is there any way to "mimic" the "normal" .NET Unhandled Exception behaviors while still catching the exception?
Related: #4548
The problem is that when the catch block doesn't exist, in a managed > Java > managed callstack, if the rightmost frame throws (and no catch block is present around it) and execution doesn't return to Java, and we unwind the rightmost Java > managed frames, then JVM state may be corrupted.
In an ideal world, every "marshal method" would have a try{…} catch (Exception) {…} handler, so that when a managed method throws an exception it can be properly caught & propagated back to Java. The problem with this ideal is it means every exception is by definition "handled", thus "mooting" the entire concept of "first chance unhandled exceptions". (There'd still eventually be an unhandled exception, but that would be on the leftmost managed frame, after the rightmost frame had been unwound.)
Is this possible?
There was a problem hiding this comment.
Are you telling me that removing the try catch when the debugger is attached is a problem because when we have a case like:
managed -> Java -> managed (which throws the unhandled exception), debugger will stop in the exception, but when we continue the execution we may get an error because JVM state may be corrupted? Which kind of error? shouldn't the process be finished in this case?
If I test #4548 I will reproduce the case that you are saying?
There was a problem hiding this comment.
Are you telling me that removing the try catch when the debugger is attached is a problem because when we have a case like:
managed -> Java -> managed (which throws the unhandled exception), debugger will stop in the exception, but when we continue the execution we may get an error because JVM state may be corrupted?
Yup. Because the debugger is running, there are no try/catch blocks at Java-to-managed boundaries, and because there are try/catch blocks, if there is an exception thrown from managed code, the JVM state is corrupted, and Android aborts the process.
Desktop repro:
$ git clone https://github.com/xamarin/java.interop.git
$ cd java.interop
$ make prepare
$ cat > d <<EOF
diff --git a/tests/Java.Interop-Tests/Java.Interop/TestType.cs b/tests/Java.Interop-Tests/Java.Interop/TestType.cs
index 4640d5f1..2cd108b1 100644
--- a/tests/Java.Interop-Tests/Java.Interop/TestType.cs
+++ b/tests/Java.Interop-Tests/Java.Interop/TestType.cs
@@ -172,7 +172,8 @@ namespace Java.InteropTests
static Delegate GetMethodThrowsHandler ()
{
Action<IntPtr, IntPtr> h = MethodThrowsHandler;
- return JniEnvironment.Runtime.MarshalMemberBuilder.CreateMarshalToManagedDelegate (h);
+// return JniEnvironment.Runtime.MarshalMemberBuilder.CreateMarshalToManagedDelegate (h);
+ return h;
}
static void MethodThrowsHandler (IntPtr jnienv, IntPtr n_self)
EOF
$ git apply < d
$ make
$ make run-tests TESTS=bin/TestDebug/Java.Interop-Tests.dllDesired behavior: nothing bad happens. ;-)
Actual results: horrible flaming death:
$ make run-tests TESTS=bin/TestDebug/Java.Interop-Tests.dll
r=0; \
msbuild /p:Configuration=Debug build-tools/scripts/RunNUnitTests.targets /p:TestAssembly=bin/TestDebug/Java.Interop-Tests.dll || r=1; \
exit $r;
…
=================================================================
Native Crash Reporting
=================================================================
Got a segv while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
=================================================================
Native stacktrace:
=================================================================
0x101da3779 - /Library/Frameworks/Mono.framework/Versions/Current/Commands/mono : mono_dump_native_crash_info
0x101d3b5be - /Library/Frameworks/Mono.framework/Versions/Current/Commands/mono : mono_handle_native_crash
0x101d9d8f8 - /Library/Frameworks/Mono.framework/Versions/Current/Commands/mono : altstack_handle_and_restore
0x10c849e4e - /Users/jon/android-toolchain/jdk-11/lib/server/libjvm.dylib : _ZN5Chunk9next_chopEv
0x10cb5ccec - /Users/jon/android-toolchain/jdk-11/lib/server/libjvm.dylib : checked_jni_GetBooleanField
0x10c299140 - /Users/jon/Dropbox/Developer/Java.Interop/bin/TestDebug/libjava-interop.dylib : java_interop_jnienv_get_boolean_field
0x1650e3841 - Unknown
=================================================================
Telemetry Dumper:
=================================================================
EXEC : warning : SIGSEGV handler expected:libjvm.dylib+0x5f61c3 found:0x0000000000000000 [/Users/jon/Dropbox/Developer/Java.Interop/build-tools/scripts/RunNUnitTests.targets]
Signal Handlers:
SIGSEGV: SIG_DFL, sa_mask[0]=00000000000000000000000000000000, sa_flags=none
…Again, this crash is "expected", because by not catching all exceptions (which is what JniEnvironment.Runtime.MarshalMemberBuilder.CreateMarshalToManagedDelegate() does), we're propagating a Mono exception "through" a Java-to-managed boundary, and Java Does Not Like That. (Deservedly so!)
The Good And Proper solution is to catch all exceptions at all Java-to-managed boundaries, but in doing so we "kill" the normal/expected IDE unhandled exception behavior… because now all exceptions are handled.
Is there a way to have our cake and eat it, too?
There was a problem hiding this comment.
@thaystg what is the best path forward here?
There was a problem hiding this comment.
I'm not sure how can we do this, but I would like to try to generate a try catch with some "mark" so we would know that the debugger should stop because it is not a really handled exception, it's only an exception that we catch in our forced catch.
I will come back soon to this issue to make more tests.
|
Example Project: Repro Steps:
|
|
Here is the same project ported to .NET 6: Scratch.JMJMException.zip Crashes (and doesn't break) with: log.txt This was using .NET 6.0.100-preview.6.21355.2 and Android 30.0.100-preview.6.62. |
|
@thaystg what are the next steps here? |
|
As discussed with @lewing I will work on it again as soon as possible. Only finishing 2 implementations: one about debugging after hotreload on android and another about show custom displays on wasm debugger, then I will work on it again. |
Context: dotnet/runtime#55904 (comment) Context: dotnet#4927 (comment) Context: dotnet#4927 (comment) Xamarin.Android has been using the `AppDomain.DoUnhandledException` API since the dawn of time to propagate uncaught Java exceptions to the managed world. However, said API (and AppDomains) are gone from the NET6 MonoVM runtime and we need to switch to something else - the `mono_unhandled_exception` native API. This commit introduces an internal call, `JNIEnv.monodroid_unhandled_exception`, which is used instead of the older mechanism when targetting NET6 and which calls the native API mentioned above. Add a device integration test which makes sure the uncaught exceptions are propagated as required.
Context: dotnet/runtime#55904 (comment) Context: #4927 (comment) Context: #4927 (comment) Context: xamarin/monodroid@7d62dec Context: dotnet/runtime@15ab9f9 Xamarin.Android has been using the `AppDomain.DoUnhandledException()` internal API since 2015 (xamarin/monodroid@7d62dec1) to propagate uncaught Java exceptions to the managed world. However, `AppDomain.DoUnhandledException()` was an internal API which was *removed* from MonoVM as part of the .NET 6 effort in dotnet/runtime@15ab9f98. For .NET 6, instead of calling the no-longer-present `AppDomain.DoUnhandledException()` method, call the [`mono_unhandled_exception()` embedding API][0], which in turn raises the `AppDomain.UnhandledException` event. Add a new internal call, `JNIEnv.monodroid_unhandled_exception()`, which is used on .NET 6 to invoke `mono_unhandled_exception()`. Add an on-device integration test which ensures that the uncaught exceptions are propagated as required. [0]: http://docs.go-mono.com/index.aspx?link=xhtml%3adeploy%2fmono-api-exc.html
Context: dotnet/runtime#55904 (comment) Context: #4927 (comment) Context: #4927 (comment) Context: xamarin/monodroid@7d62dec Context: dotnet/runtime@15ab9f9 Xamarin.Android has been using the `AppDomain.DoUnhandledException()` internal API since 2015 (xamarin/monodroid@7d62dec1) to propagate uncaught Java exceptions to the managed world. However, `AppDomain.DoUnhandledException()` was an internal API which was *removed* from MonoVM as part of the .NET 6 effort in dotnet/runtime@15ab9f98. For .NET 6, instead of calling the no-longer-present `AppDomain.DoUnhandledException()` method, call the [`mono_unhandled_exception()` embedding API][0], which in turn raises the `AppDomain.UnhandledException` event. Add a new internal call, `JNIEnv.monodroid_unhandled_exception()`, which is used on .NET 6 to invoke `mono_unhandled_exception()`. Add an on-device integration test which ensures that the uncaught exceptions are propagated as required. [0]: http://docs.go-mono.com/index.aspx?link=xhtml%3adeploy%2fmono-api-exc.html
[One .NET] Use Mono embedding API for exception debugger notification (#6106) Context: dotnet/runtime#56071 Context: #4877 Context: #4927 (comment) Context: #4927 (comment) Context: xamarin/monodroid@3e9de5a Context: xamarin/monodroid@b0f8597 Context: xamarin/monodroid@12a012e What should happen when an exception is thrown and a debugger is attached? This is in fact a loaded question: there's what Xamarin.Android (Legacy) *has* done, vs. what .NET 6 Android for .NET does, vs. what "should" happen. What "should" happen is easiest: 1. We should behave like a "normal" Desktop .NET app when a debugger is attached, AND 2. We shouldn't corrupt JVM state. Unfortunately, (1)+(2) is currently not possible, in part because Java doesn't have an equivalent to Windows' [two attempt][0] debugger notification infrastructure. See #4877 for details. What Legacy Xamarin.Android does is also detailed in #4877, and relies on the `Debugger.Mono_UnhandledException()` method in order to alert an attached debugger that there is an exception to show to the user. However, `Debugger.Mono_UnhandledException()` never made it to the `dotnet/runtime` repo. It never existed there. Thus, what .NET 6 Android for .NET *currently* does is…*nothing*. If an exception is thrown and a debugger is attached, the debugger is *not* notified. Eventually you'll get an unhandled exception, long after it was originally thrown; see commit c1a2ee7. PR dotnet/runtime#56071 added a new `mono_debugger_agent_unhandled_exception()` Mono embedding API which is equivalent to `Debugger.Mono_UnhandledException()` for use with .NET 6 + MonoVM. Update `src/Mono.Android` and `src/monodroid` so that `mono_debugger_agent_unhandled_exception()` is used to alert the debugger that an exception has been thrown at a JNI boundary. This should allow .NET 6 + Android to have equivalent exception handling semantics as legacy Xamarin.Android. [0]: https://docs.microsoft.com/en-us/windows/win32/debug/debugger-exception-handling
[One .NET] Use Mono embedding API for exception debugger notification (#6106) Context: dotnet/runtime#56071 Context: #4877 Context: #4927 (comment) Context: #4927 (comment) Context: xamarin/monodroid@3e9de5a Context: xamarin/monodroid@b0f8597 Context: xamarin/monodroid@12a012e What should happen when an exception is thrown and a debugger is attached? This is in fact a loaded question: there's what Xamarin.Android (Legacy) *has* done, vs. what .NET 6 Android for .NET does, vs. what "should" happen. What "should" happen is easiest: 1. We should behave like a "normal" Desktop .NET app when a debugger is attached, AND 2. We shouldn't corrupt JVM state. Unfortunately, (1)+(2) is currently not possible, in part because Java doesn't have an equivalent to Windows' [two attempt][0] debugger notification infrastructure. See #4877 for details. What Legacy Xamarin.Android does is also detailed in #4877, and relies on the `Debugger.Mono_UnhandledException()` method in order to alert an attached debugger that there is an exception to show to the user. However, `Debugger.Mono_UnhandledException()` never made it to the `dotnet/runtime` repo. It never existed there. Thus, what .NET 6 Android for .NET *currently* does is…*nothing*. If an exception is thrown and a debugger is attached, the debugger is *not* notified. Eventually you'll get an unhandled exception, long after it was originally thrown; see commit c1a2ee7. PR dotnet/runtime#56071 added a new `mono_debugger_agent_unhandled_exception()` Mono embedding API which is equivalent to `Debugger.Mono_UnhandledException()` for use with .NET 6 + MonoVM. Update `src/Mono.Android` and `src/monodroid` so that `mono_debugger_agent_unhandled_exception()` is used to alert the debugger that an exception has been thrown at a JNI boundary. This should allow .NET 6 + Android to have equivalent exception handling semantics as legacy Xamarin.Android. [0]: https://docs.microsoft.com/en-us/windows/win32/debug/debugger-exception-handling
…6657) Context: https://github.com/xamarin/xamarin-android/wiki/Blueprint#java-type-registration Context: b7a368a Context: #4877 Context: #4927 (comment) In order for Java code to call C# code, [`JNIEnv::RegisterNatives()][0] must be invoked, providing an array of `JNINativeMethod` structures, each of which contains a function pointer to invoke, kept in `JNINativeMethod::fnPtr`. Fortunately, delegates marshal as function pointers, and there is a bunch of `generator`-emitted infrastructure and coordination with Java Callable Wrappers to eventually obtain a Delegate instance to provide `JNIEnv::RegisterNatives()`. There is one deficiency in the `generator`-emitted infrastructure: it doesn't deal with C# exceptions. However, exceptions "can't" cross the JNI boundary (see b7a368a for an example of the breakage that results when exceptions do cross the boundary!), except when we *do* want exceptions to cross the JNI boundary ("improved" IDE first chance exception experience; see #4877). This "we want to catch exceptions, except when we don't" scenario has existed since the very beginning. As "the very beginning" predates [C# 4 exception filters][1], there wasn't a way for `generator` output to "selectively `catch` exceptions". We squared this circle by using `System.Reflection.Emit`: 1. During Java Callable Wrapper registration, we lookup the "marshal method getter" as provided to the `Runtime.register()` invocation, e.g. `Android.App.Activity.GetOnCreate_Landroid_os_Bundle_Handler()`. 2. `GetOnCreate_Landroid_os_Bundle_Handler()` is `generator` output, and contains a `JNINativeWrapper.CreateDelegate()` invocation: cb_onCreate_Landroid_os_Bundle_ = JNINativeWrapper.CreateDelegate ((_JniMarshal_PPL_V) n_OnCreate_Landroid_os_Bundle_); 3. `JNINativeWrapper.CreateDelegate()` uses `System.Reflection.Emit` to create a new delegate instance which *wraps* the marshal method `Activity.n_OnCreate_Landroid_os_Bundle()` in a `try`/*filtered* `catch` block and marshals the exception to Java; `JNINativeWrapper.CreateDelegate()` effectively returns: bool _run_catch_if_debugger_not_attached (Exception e) { if (Debugger.IsAttached || !JNIEnv.PropagateExceptions) { JNIEnv.mono_unhandled_exception (e); return false; } return true; } _JniMarshal_PPL_V result = (jnienv, native__this, native_savedInstanceState) => { JNIEnv.WaitForBridgeProcessing (); try { Activity.n_OnCreate_Landroid_os_Bundle_ (jnienv, native__this, native_savedInstanceState); } catch (Exception e) when (_run_catch_if_debugger_not_attached (e)) { AndroidEnvironment.UnhandledException (e); if (Debugger.IsAttached || !JNIEnv.PropagateExceptions) throw; } }; return result; Again, this was C# 2.0 at the time, so C# 4 exception filters couldn't be used, thus the need for `System.Reflection.Emit`, so that [`ILGenerator.BeginExceptionFilterBLock()`][2] could be used (the support for which is a Mono extension). After this point, use of `System.Reflection.Emit` was part of the implicit ABI between Xamarin.Android and binding assemblies. While `generator` *could* be updated to *itself* emit the `try`/`catch` block with exception filters, that would only work for binding assemblies released *after* that `generator` fix. The `System.Reflection.Emit` wrapper *can't* be skipped without breaking semantic compatibility, *or* without allowing C# exceptions to always pass through a JNI boundary, which would be Bad™. The use of `System.Refleciton.Emit` is a Known Problem™, and something we'd *like* to remove. (Hence the [`jnimarshalmethod-gen`][3] explorations…) With that background out of the way… Let us turn our attention to the `dotnet new maui` template. The default MAUI template hits `JNINativeWrapper.CreateDelegate()` 58 times during process startup, and we were wondering if we could selectively improve these particular invocations, without needing to re-think the entire "marshal method" infrastructure. *Partially specialize* `JNINativeWrapper.CreateDelegate()` for the following delegate types: * `_JniMarshal_PP_V` * `_JniMarshal_PPI_V` * `_JniMarshal_PPL_L` * `_JniMarshal_PPL_V` * `_JniMarshal_PPL_Z` * `_JniMarshal_PPII_V` * `_JniMarshal_PPLI_V` * `_JniMarshal_PPLL_V` * `_JniMarshal_PPLL_Z` * `_JniMarshal_PPIIL_V` * `_JniMarshal_PPILL_V` * `_JniMarshal_PPLIL_Z` * `_JniMarshal_PPLLL_L` * `_JniMarshal_PPLLL_Z` * `_JniMarshal_PPIIII_V` * `_JniMarshal_PPLLLL_V` * `_JniMarshal_PPLIIII_V` * `_JniMarshal_PPZIIII_V` * `_JniMarshal_PPLIIIIIIII_V` This is done via use of a T4 template, which generates `JNINativeWrapper.CreateBuiltInDelegate()`, and `JNINativeWrapper.CreateDelegate()` is updated to call `CreateBuiltInDelegate()`: partial class JNINativeWrapper { static Delegate? CreateBuiltInDelegate (Delegate dlg, Type delegateType) { switch (delegateType.Name) { case "_JniMarshal_PP_V": return … case "_JniMarshal_PPI_V": return … … } return null; } public static Delegate CreateDelegate (Delegate dlg) { … var builtin = CreateBuiltInDelegate (dlg, dlg.GetType (); if (builtin != null) return builtin; … } } This avoids use of `System.Reflection.Emit` for the specified types. Other changes: * Update `TypeManager.GetActivateHandler()` to use `_JniMarshal_PPLLLL_V` instead of `Action<IntPtr, IntPtr, IntPtr, IntPtr, IntPtr, IntPtr>`, so the fast path can be used. * Added a log message for `adb shell septprop debug.mono.log assembly`: Falling back to System.Reflection.Emit for delegate type '{delegateType}': {dlg.Method} * I was also able to remove `mono_unhandled_exception_method` from `JNINativeWrapper` as we already has this value in `JNIEnv`. ~~ Results ~~ Testing `dotnet new maui` with version: msbuild Xamarin.Android.sln -t:InstallMaui -bl -p:MauiVersion=6.0.200-preview.13.2536 A `Release` build on a Pixel 5 device, total startup time: | Startup | Average (ms) | Std Err (ms) | Std Dev (ms) | | --------- | ------------: | ------------: | ------------: | | Before | 1106.3 | 6.919 | 21.879 | | After | 1078.8 | 5.438 | 17.197 | This might save ~35ms on average? If I time the message for one call, [such as][4]: I monodroid-timing: Runtime.register: registering type `Microsoft.Maui.MauiApplication, Microsoft.Maui, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null` I monodroid-timing: Runtime.register: end time; elapsed: 0s:17::794845 The result is: | One Call | Average (ms) | Std Err (ms) | Std Dev (ms) | | --------- | ------------: | ------------: | ------------: | | Before | 23.925 | 0.050 | 0.159 | | After | 18.723 | 0.094 | 0.298 | Saving ~5.8ms for this one call. `.apk` size difference for `dotnet new android`: % apkdiff -f before.apk after.apk Size difference in bytes ([*1] apk1 only, [*2] apk2 only): + 3,390 assemblies/assemblies.blob + 54 assemblies/assemblies.x86_64.blob - 4 assemblies/assemblies.arm64_v8a.blob - 15 assemblies/assemblies.x86.blob - 65 assemblies/assemblies.armeabi_v7a.blob Summary: + 3,360 Other entries 0.03% (of 10,526,432) + 0 Dalvik executables 0.00% (of 7,816,392) + 0 Shared libraries 0.00% (of 18,414,404) + 4,096 Package size difference 0.02% (of 21,006,128) We're looking at a ~4KB size increase for this partial specialization. [0]: https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#RegisterNatives [1]: https://docs.microsoft.com/en-us/dotnet/csharp/fundamentals/exceptions/exception-handling#catch-blocks [2]: https://docs.microsoft.com/is-is/dotnet/api/system.reflection.emit.ilgenerator.beginexceptfilterblock?view=net-6.0 [3]: http://github.com/xamarin/Java.Interop/commit/c8f3e51a6cfd78bdce89e2429efae4495481f57b [4]: https://github.com/dotnet/maui/blob/bfba62ed796d3416c4fcaa7cfbea86dc8d5e04c2/src/Compatibility/ControlGallery/src/Android/MainApplication.cs
|
@lambdageek suggests that Android use: /*
* mono_install_ftnptr_eh_callback:
*
* Install a callback that should be called when there is a managed exception
* in a native-to-managed wrapper. This is mainly used by iOS to convert a
* managed exception to a native exception, to properly unwind the native
* stack; this native exception will then be converted back to a managed
* exception in their managed-to-native wrapper.
*/
void
mono_install_ftnptr_eh_callback (MonoFtnPtrEHCallback callback) |
|
@lambdageek: while looking at what In particular, this worries me: g_error ("Did not expect ftnptr_eh_callback to return.");The (not quite documented?) requirement, then, is that the This does not work for JNI stack unwind. JNI is limited to the C ABI, which doesn't have exceptions as a language or ABI feature, and thus stack unwind is cooperative, by necessity. See also: Thus, the way to get Java to unwind its stack is to return execution to Java. I suppose Thus, I don't consider |
|
@thaystg: Re-upping and re-framing this: the problems with the current approach (described in part in this PR and in #4927) is:
Additionally, we would like to update |
|
@thaystg previously mentioned:
I just read that -- not sure why I didn't see it before? Or don't remember having seen it before? ¯\(ツ)/¯ -- and thought of an "interesting" way to "mark" an exception: with another exception! namespace System.Runtime.ExceptionServices {
public partial class StackUnwinding : Exception
{
public StackUnwinding(Exception innerException);
}
}where void JniBoundary(IntPtr jnienv, IntPtr self)
{
var t = new JniTransition(jnienv);
try {
// code which may throw an exception
}
catch (StackUnwinding e) {
t.SetPendingException(e.InnerException);
}
finally {
t.Dispose();
}
}Given a Unhandled Exception Next, "first pass" is performed: the entire managed callstack is scanned to see if anything catches Finally, the "second pass" is performed to unwind the callstack, but each managed frame is unwound, right-to-left, in a *two-check" process:
This would allow us to be involved only during stack unwind back to a Java caller, without the use of exception filters, in a manner which is consistent whether or not a debugger is attached. If there are multiple Handled Exception Next, "first pass" is performed: the entire managed callstack is scanned to see if anything catches For each managed frame between Problems This also requires "special-casing" a particular exception type, a'la Alternatively, it could be a |
…8185) Context: #1198 Context: #1188 (comment) Context: #4877 Context: #4927 (comment) What happens with unhandled exceptions? throw new InvalidOperationException ("oops!"); This is a surprisingly complicated question: If this happens when a debugger is attached, the debugger will get a "first chance notification" at the `throw` site. If execution continues, odds are high that the app will abort if there is a JNI transition in the callstack. If no debugger is attached, then it depends on which thread threw the unhandled exception. If the thread which threw the unhandled exception is a .NET Thread: static void ThrowFromAnotherManagedThread() { var t = new System.Threading.Thread(() => { throw new new Java.Lang.Error ("from another thread?!"); }); t.Start (); t.Join (); } Then .NET will report the unhandled exception, *and* the app will restart: F mono-rt : [ERROR] FATAL UNHANDLED EXCEPTION: System.InvalidOperationException: oops! F mono-rt : at android_unhandled_exception.MainActivity.<>c.<ThrowFromAnotherManagedThread>b__1_0() F mono-rt : at System.Threading.Thread.StartCallback() # app restarts If the thread which threw the unhandled exception is a *Java* thread, which could be the UI thread (e.g. thrown from an `Activity.OnCreate()` override) or via a `Java.Lang.Thread` instance: static void ThrowFromAnotherJavaThread() { var t = new Java.Lang.Thread(() => { throw new InvalidOperationException ("oops!"); }); t.Start (); t.Join (); } Then .NET will report the unhandled exception, *and* the app will *not* restart (which differs from using .NET threads): E AndroidRuntime: Process: com.companyname.android_unhandled_exception, PID: 5436 E AndroidRuntime: android.runtime.JavaProxyThrowable: System.InvalidOperationException: oops! E AndroidRuntime: at android_unhandled_exception.MainActivity.<>c.<ThrowFromAnotherJavaThread>b__2_0() E AndroidRuntime: at Java.Lang.Thread.RunnableImplementor.Run() E AndroidRuntime: at Java.Lang.IRunnableInvoker.n_Run(IntPtr , IntPtr ) E AndroidRuntime: at Android.Runtime.JNINativeWrapper.Wrap_JniMarshal_PP_V(_JniMarshal_PP_V , IntPtr , IntPtr ) E AndroidRuntime: at mono.java.lang.RunnableImplementor.n_run(Native Method) E AndroidRuntime: at mono.java.lang.RunnableImplementor.run(RunnableImplementor.java:31) E AndroidRuntime: at java.lang.Thread.run(Thread.java:1012) I MonoDroid: Android.Runtime.JavaProxyThrowable: Exception_WasThrown, Android.Runtime.JavaProxyThrowable I MonoDroid: I MonoDroid: --- End of managed Android.Runtime.JavaProxyThrowable stack trace --- I MonoDroid: android.runtime.JavaProxyThrowable: System.InvalidOperationException: oops! I MonoDroid: at android_unhandled_exception.MainActivity.<>c.<ThrowFromAnotherJavaThread>b__2_0() I MonoDroid: at Java.Lang.Thread.RunnableImplementor.Run() I MonoDroid: at Java.Lang.IRunnableInvoker.n_Run(IntPtr , IntPtr ) I MonoDroid: at Android.Runtime.JNINativeWrapper.Wrap_JniMarshal_PP_V(_JniMarshal_PP_V , IntPtr , IntPtr ) I MonoDroid: at mono.java.lang.RunnableImplementor.n_run(Native Method) I MonoDroid: at mono.java.lang.RunnableImplementor.run(RunnableImplementor.java:31) I MonoDroid: at java.lang.Thread.run(Thread.java:1012) I MonoDroid: I MonoDroid: --- End of managed Android.Runtime.JavaProxyThrowable stack trace --- I MonoDroid: android.runtime.JavaProxyThrowable: System.InvalidOperationException: oops! I MonoDroid: at android_unhandled_exception.MainActivity.<>c.<ThrowFromAnotherJavaThread>b__2_0() I MonoDroid: at Java.Lang.Thread.RunnableImplementor.Run() I MonoDroid: at Java.Lang.IRunnableInvoker.n_Run(IntPtr , IntPtr ) I MonoDroid: at Android.Runtime.JNINativeWrapper.Wrap_JniMarshal_PP_V(_JniMarshal_PP_V , IntPtr , IntPtr ) I MonoDroid: at mono.java.lang.RunnableImplementor.n_run(Native Method) I MonoDroid: at mono.java.lang.RunnableImplementor.run(RunnableImplementor.java:31) I MonoDroid: at java.lang.Thread.run(Thread.java This "works", until we enter the world of crash logging for later diagnosis and fixing. The problem with our historical approach is that we would "stuff" the .NET stack trace into the "message" of the Java-side `Throwable` instance, and the "message" may not be transmitted as part of the crash logging! (This is noticeable by the different indentation levels for the `at …` lines in the crash output. Three space indents are from the `Throwable.getMessage()` output, while four space indents are from the Java-side stack trace.) We *think* that we can improve this by replacing the Java-side stack trace with a "merged" stack trace which includes both the Java-side and .NET-side stack traces. This does nothing for unhandled exceptions on .NET threads, but does alter the output from Java threads: E AndroidRuntime: FATAL EXCEPTION: Thread-3 E AndroidRuntime: Process: com.companyname.android_unhandled_exception, PID: 12321 E AndroidRuntime: android.runtime.JavaProxyThrowable: [System.InvalidOperationException]: oops! E AndroidRuntime: at android_unhandled_exception.MainActivity+<>c.<ThrowFromAnotherJavaThread>b__2_0(Unknown Source:0) E AndroidRuntime: at Java.Lang.Thread+RunnableImplementor.Run(Unknown Source:0) E AndroidRuntime: at Java.Lang.IRunnableInvoker.n_Run(Unknown Source:0) E AndroidRuntime: at Android.Runtime.JNINativeWrapper.Wrap_JniMarshal_PP_V(Unknown Source:0) E AndroidRuntime: at mono.java.lang.RunnableImplementor.n_run(Native Method) E AndroidRuntime: at mono.java.lang.RunnableImplementor.run(RunnableImplementor.java:31) E AndroidRuntime: at java.lang.Thread.run(Thread.java:1012) I MonoDroid: UNHANDLED EXCEPTION: I MonoDroid: Android.Runtime.JavaProxyThrowable: Exception_WasThrown, Android.Runtime.JavaProxyThrowable I MonoDroid: I MonoDroid: --- End of managed Android.Runtime.JavaProxyThrowable stack trace --- I MonoDroid: android.runtime.JavaProxyThrowable: [System.InvalidOperationException]: oops! I MonoDroid: at android_unhandled_exception.MainActivity+<>c.<ThrowFromAnotherJavaThread>b__2_0(Unknown Source:0) I MonoDroid: at Java.Lang.Thread+RunnableImplementor.Run(Unknown Source:0) I MonoDroid: at Java.Lang.IRunnableInvoker.n_Run(Unknown Source:0) I MonoDroid: at Android.Runtime.JNINativeWrapper.Wrap_JniMarshal_PP_V(Unknown Source:0) I MonoDroid: at mono.java.lang.RunnableImplementor.n_run(Native Method) I MonoDroid: at mono.java.lang.RunnableImplementor.run(RunnableImplementor.java:31) I MonoDroid: at java.lang.Thread.run(Thread.java:1012) I MonoDroid: I MonoDroid: --- End of managed Android.Runtime.JavaProxyThrowable stack trace --- I MonoDroid: android.runtime.JavaProxyThrowable: [System.InvalidOperationException]: oops! I MonoDroid: at android_unhandled_exception.MainActivity+<>c.<ThrowFromAnotherJavaThread>b__2_0(Unknown Source:0) I MonoDroid: at Java.Lang.Thread+RunnableImplementor.Run(Unknown Source:0) I MonoDroid: at Java.Lang.IRunnableInvoker.n_Run(Unknown Source:0) I MonoDroid: at Android.Runtime.JNINativeWrapper.Wrap_JniMarshal_PP_V(Unknown Source:0) I MonoDroid: at mono.java.lang.RunnableImplementor.n_run(Native Method) I MonoDroid: at mono.java.lang.RunnableImplementor.run(RunnableImplementor.java:31) I MonoDroid: at java.lang.Thread.run(Thread.java:1012) Note how `at …` is always a four-space indent and always lines up. *Hopefully* this means that crash loggers can provide more useful information. TODO: * Create an "end-to-end" test which uses an actual crash logger (which one?) in order to better understand what the "end user" experience is. * The "merged" stack trace always places the managed stack trace above the Java-side stack trace. This means things will look "weird"/"wrong" if you have an *intermixed* stack trace, e.g. (Java code calls .NET code which calls Java code)+ which eventually throws from .NET.
…8185) Context: #1198 Context: #1188 (comment) Context: #4877 Context: #4927 (comment) What happens with unhandled exceptions? throw new InvalidOperationException ("oops!"); This is a surprisingly complicated question: If this happens when a debugger is attached, the debugger will get a "first chance notification" at the `throw` site. If execution continues, odds are high that the app will abort if there is a JNI transition in the callstack. If no debugger is attached, then it depends on which thread threw the unhandled exception. If the thread which threw the unhandled exception is a .NET Thread: static void ThrowFromAnotherManagedThread() { var t = new System.Threading.Thread(() => { throw new new Java.Lang.Error ("from another thread?!"); }); t.Start (); t.Join (); } Then .NET will report the unhandled exception, *and* the app will restart: F mono-rt : [ERROR] FATAL UNHANDLED EXCEPTION: System.InvalidOperationException: oops! F mono-rt : at android_unhandled_exception.MainActivity.<>c.<ThrowFromAnotherManagedThread>b__1_0() F mono-rt : at System.Threading.Thread.StartCallback() # app restarts If the thread which threw the unhandled exception is a *Java* thread, which could be the UI thread (e.g. thrown from an `Activity.OnCreate()` override) or via a `Java.Lang.Thread` instance: static void ThrowFromAnotherJavaThread() { var t = new Java.Lang.Thread(() => { throw new InvalidOperationException ("oops!"); }); t.Start (); t.Join (); } Then .NET will report the unhandled exception, *and* the app will *not* restart (which differs from using .NET threads): E AndroidRuntime: Process: com.companyname.android_unhandled_exception, PID: 5436 E AndroidRuntime: android.runtime.JavaProxyThrowable: System.InvalidOperationException: oops! E AndroidRuntime: at android_unhandled_exception.MainActivity.<>c.<ThrowFromAnotherJavaThread>b__2_0() E AndroidRuntime: at Java.Lang.Thread.RunnableImplementor.Run() E AndroidRuntime: at Java.Lang.IRunnableInvoker.n_Run(IntPtr , IntPtr ) E AndroidRuntime: at Android.Runtime.JNINativeWrapper.Wrap_JniMarshal_PP_V(_JniMarshal_PP_V , IntPtr , IntPtr ) E AndroidRuntime: at mono.java.lang.RunnableImplementor.n_run(Native Method) E AndroidRuntime: at mono.java.lang.RunnableImplementor.run(RunnableImplementor.java:31) E AndroidRuntime: at java.lang.Thread.run(Thread.java:1012) I MonoDroid: Android.Runtime.JavaProxyThrowable: Exception_WasThrown, Android.Runtime.JavaProxyThrowable I MonoDroid: I MonoDroid: --- End of managed Android.Runtime.JavaProxyThrowable stack trace --- I MonoDroid: android.runtime.JavaProxyThrowable: System.InvalidOperationException: oops! I MonoDroid: at android_unhandled_exception.MainActivity.<>c.<ThrowFromAnotherJavaThread>b__2_0() I MonoDroid: at Java.Lang.Thread.RunnableImplementor.Run() I MonoDroid: at Java.Lang.IRunnableInvoker.n_Run(IntPtr , IntPtr ) I MonoDroid: at Android.Runtime.JNINativeWrapper.Wrap_JniMarshal_PP_V(_JniMarshal_PP_V , IntPtr , IntPtr ) I MonoDroid: at mono.java.lang.RunnableImplementor.n_run(Native Method) I MonoDroid: at mono.java.lang.RunnableImplementor.run(RunnableImplementor.java:31) I MonoDroid: at java.lang.Thread.run(Thread.java:1012) I MonoDroid: I MonoDroid: --- End of managed Android.Runtime.JavaProxyThrowable stack trace --- I MonoDroid: android.runtime.JavaProxyThrowable: System.InvalidOperationException: oops! I MonoDroid: at android_unhandled_exception.MainActivity.<>c.<ThrowFromAnotherJavaThread>b__2_0() I MonoDroid: at Java.Lang.Thread.RunnableImplementor.Run() I MonoDroid: at Java.Lang.IRunnableInvoker.n_Run(IntPtr , IntPtr ) I MonoDroid: at Android.Runtime.JNINativeWrapper.Wrap_JniMarshal_PP_V(_JniMarshal_PP_V , IntPtr , IntPtr ) I MonoDroid: at mono.java.lang.RunnableImplementor.n_run(Native Method) I MonoDroid: at mono.java.lang.RunnableImplementor.run(RunnableImplementor.java:31) I MonoDroid: at java.lang.Thread.run(Thread.java This "works", until we enter the world of crash logging for later diagnosis and fixing. The problem with our historical approach is that we would "stuff" the .NET stack trace into the "message" of the Java-side `Throwable` instance, and the "message" may not be transmitted as part of the crash logging! (This is noticeable by the different indentation levels for the `at …` lines in the crash output. Three space indents are from the `Throwable.getMessage()` output, while four space indents are from the Java-side stack trace.) We *think* that we can improve this by replacing the Java-side stack trace with a "merged" stack trace which includes both the Java-side and .NET-side stack traces. This does nothing for unhandled exceptions on .NET threads, but does alter the output from Java threads: E AndroidRuntime: FATAL EXCEPTION: Thread-3 E AndroidRuntime: Process: com.companyname.android_unhandled_exception, PID: 12321 E AndroidRuntime: android.runtime.JavaProxyThrowable: [System.InvalidOperationException]: oops! E AndroidRuntime: at android_unhandled_exception.MainActivity+<>c.<ThrowFromAnotherJavaThread>b__2_0(Unknown Source:0) E AndroidRuntime: at Java.Lang.Thread+RunnableImplementor.Run(Unknown Source:0) E AndroidRuntime: at Java.Lang.IRunnableInvoker.n_Run(Unknown Source:0) E AndroidRuntime: at Android.Runtime.JNINativeWrapper.Wrap_JniMarshal_PP_V(Unknown Source:0) E AndroidRuntime: at mono.java.lang.RunnableImplementor.n_run(Native Method) E AndroidRuntime: at mono.java.lang.RunnableImplementor.run(RunnableImplementor.java:31) E AndroidRuntime: at java.lang.Thread.run(Thread.java:1012) I MonoDroid: UNHANDLED EXCEPTION: I MonoDroid: Android.Runtime.JavaProxyThrowable: Exception_WasThrown, Android.Runtime.JavaProxyThrowable I MonoDroid: I MonoDroid: --- End of managed Android.Runtime.JavaProxyThrowable stack trace --- I MonoDroid: android.runtime.JavaProxyThrowable: [System.InvalidOperationException]: oops! I MonoDroid: at android_unhandled_exception.MainActivity+<>c.<ThrowFromAnotherJavaThread>b__2_0(Unknown Source:0) I MonoDroid: at Java.Lang.Thread+RunnableImplementor.Run(Unknown Source:0) I MonoDroid: at Java.Lang.IRunnableInvoker.n_Run(Unknown Source:0) I MonoDroid: at Android.Runtime.JNINativeWrapper.Wrap_JniMarshal_PP_V(Unknown Source:0) I MonoDroid: at mono.java.lang.RunnableImplementor.n_run(Native Method) I MonoDroid: at mono.java.lang.RunnableImplementor.run(RunnableImplementor.java:31) I MonoDroid: at java.lang.Thread.run(Thread.java:1012) I MonoDroid: I MonoDroid: --- End of managed Android.Runtime.JavaProxyThrowable stack trace --- I MonoDroid: android.runtime.JavaProxyThrowable: [System.InvalidOperationException]: oops! I MonoDroid: at android_unhandled_exception.MainActivity+<>c.<ThrowFromAnotherJavaThread>b__2_0(Unknown Source:0) I MonoDroid: at Java.Lang.Thread+RunnableImplementor.Run(Unknown Source:0) I MonoDroid: at Java.Lang.IRunnableInvoker.n_Run(Unknown Source:0) I MonoDroid: at Android.Runtime.JNINativeWrapper.Wrap_JniMarshal_PP_V(Unknown Source:0) I MonoDroid: at mono.java.lang.RunnableImplementor.n_run(Native Method) I MonoDroid: at mono.java.lang.RunnableImplementor.run(RunnableImplementor.java:31) I MonoDroid: at java.lang.Thread.run(Thread.java:1012) Note how `at …` is always a four-space indent and always lines up. *Hopefully* this means that crash loggers can provide more useful information. TODO: * Create an "end-to-end" test which uses an actual crash logger (which one?) in order to better understand what the "end user" experience is. * The "merged" stack trace always places the managed stack trace above the Java-side stack trace. This means things will look "weird"/"wrong" if you have an *intermixed* stack trace, e.g. (Java code calls .NET code which calls Java code)+ which eventually throws from .NET.
We don't need to call mono_unhandled_exception the runtime will handle with it.
Relates to mono/mono#20314.
We don't need to wait for mono/mono PR to be merged, mono PR only removes the unhandled_exception function.