Fix XA_BROKEN_EXCEPTION_TRANSITIONS support

[roubachof]

NOTE: the SIGSEGV only happens while debugging.
If in RELEASE or ran in DEBUG mode without debugging, an UNHANDLED EXCEPTION is raised, but the app doesn't crash.

I am here trying to create blur views for Xamarin.Forms, for the android implementation I chose https://github.com/mmin18/RealtimeBlurView.

I translated in C# all the classes, you can find them here:

https://github.com/roubachof/Sharpnado.Presentation.Forms/tree/secret/Sharpnado.Presentation.Forms.Droid/Renderers/MaterialFrame/RealtimeBlurView

In his java implementation, mmin18 has the following code:

https://github.com/mmin18/RealtimeBlurView/blob/master/library/src/com/github/mmin18/widget/RealtimeBlurView.java#L259-L267

For stoping the drawing process he throws a custom "STOP_EXCEPTION" in the Draw method of the blur view:

https://github.com/mmin18/RealtimeBlurView/blob/master/library/src/com/github/mmin18/widget/RealtimeBlurView.java#L321-L330

Remark: you have to interrupt the drawing of all the next children, so returning in the blur view's Draw method is not enough....

It seems to be fine in plain android since I couldn't find an issue talking about SIGSEGV and STOP_EXCEPTION in the original repo.

But in Xamarin.Android I get a sig segv exception:

Loaded assembly: System.Runtime.Serialization.dll [External]
**Sharpnado.Presentation.Forms.Droid.Renderers.MaterialFrame.RealtimeBlurView.RealtimeBlurView+StopException:** 'Exception of type 'Sharpnado.Presentation.Forms.Droid.Renderers.MaterialFrame.RealtimeBlurView.RealtimeBlurView+StopException' was thrown.'

04-13 14:29:09.259 D/Mono    ( 3665): DllImport attempting to load: '/system/lib/liblog.so'.
04-13 14:29:09.259 D/Mono    ( 3665): DllImport loaded library '/system/lib/liblog.so'.
04-13 14:29:09.260 D/Mono    ( 3665): DllImport searching in: '/system/lib/liblog.so' ('/system/lib/liblog.so').
04-13 14:29:09.260 D/Mono    ( 3665): Searching for '__android_log_print'.
04-13 14:29:09.260 D/Mono    ( 3665): Probing '__android_log_print'.
04-13 14:29:09.260 D/Mono    ( 3665): Found as '__android_log_print'.
04-13 14:29:09.264 I/MonoDroid( 3665): UNHANDLED EXCEPTION:
04-13 14:29:09.264 I/MonoDroid( 3665): Sharpnado.Presentation.Forms.Droid.Renderers.MaterialFrame.RealtimeBlurView.RealtimeBlurView+StopException: Exception of type 'Sharpnado.Presentation.Forms.Droid.Renderers.MaterialFrame.RealtimeBlurView.RealtimeBlurView+StopException' was thrown.
04-13 14:29:09.264 I/MonoDroid( 3665):   at Sharpnado.Presentation.Forms.Droid.Renderers.MaterialFrame.RealtimeBlurView.RealtimeBlurView.Draw (Android.Graphics.Canvas canvas) [0x0001c] in D:\Dev\Sharpnado\src\Xamarin-Forms-Practices\Sharpnado.Presentation.Forms\Sharpnado.Presentation.Forms.Droid\Renderers\MaterialFrame\RealtimeBlurView\RealtimeBlurView.cs:409 
04-13 14:29:09.264 I/MonoDroid( 3665):   at Android.Views.View.n_Draw_Landroid_graphics_Canvas_ (System.IntPtr jnienv, System.IntPtr native__this, System.IntPtr native_canvas) [0x00011] in <d3b924763d4a465c85b26f6e8edc8a53>:0 
04-13 14:29:09.264 I/MonoDroid( 3665):   at (wrapper dynamic-method) Android.Runtime.DynamicMethodNameCounter.55(intptr,intptr,intptr)
04-13 14:29:09.273 W/obile.practice( 3665): JNI RegisterNativeMethods: attempt to register 0 native methods for android.runtime.JavaProxyThrowable
04-13 14:29:09.277 D/Mono    ( 3665): DllImport searching in: '__Internal' ('(null)').
04-13 14:29:09.277 D/Mono    ( 3665): Searching for 'java_interop_jnienv_throw'.
04-13 14:29:09.277 D/Mono    ( 3665): Probing 'java_interop_jnienv_throw'.
04-13 14:29:09.277 D/Mono    ( 3665): Found as 'java_interop_jnienv_throw'.
[0:] 04-13 14:29:09.278 | SharpnadoInternals | 1 | INFO | Stop exception received: rendering was stopped

=================================================================
	Native Crash Reporting
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

No native Android stacktrace (see debuggerd output).

=================================================================
	Basic Fault Address Reporting
=================================================================
Memory around native instruction pointer (0xe566e21b):
0xe566e20b  83 ec 0c 57 e8 2c bf fd ff 83 c4 10 89 c6 b1 01  ...W.,..........
0xe566e21b  83 7e 0c ff 74 1e 8b 07 83 ec 04 ff 77 30 56 57  .~..t.......w0VW
0xe566e22b  ff 50 0c b1 01 83 c4 10 83 f8 01 74 07 83 f8 02  .P.........t....
0xe566e23b  75 19 31 c9 8b 44 24 04 8b 00 3b 44 24 18 0f 85  u.1..D$...;D$...

=================================================================
	Managed Stacktrace:
=================================================================
	  at <unknown> <0xffffffff>
	  at Java.Interop.NativeMethods:java_interop_jnienv_get_method_id <0x00015>
	  at InstanceMethods:GetMethodID <0x0020f>
	  at Java.Interop.JniType:GetInstanceMethod <0x00097>
	  at JniInstanceMethods:GetMethodInfo <0x001ab>
	  at JniInstanceMethods:InvokeVirtualVoidMethod <0x000ef>
	  at Android.Graphics.Canvas:RestoreToCount <0x00137>
	  at PreDrawListener:OnPreDraw <0x00875>
	  at IOnPreDrawListenerInvoker:n_OnPreDraw <0x0008e>
	  at Android.Runtime.DynamicMethodNameCounter:53 <0x000a7>
	  at Android.Runtime.DynamicMetho
dNameCounter:53 <0x000af>
=================================================================
04-13 14:29:09.297 F/libc    ( 3665): Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x80000c in tid 3665 (obile.practices), pid 3665 (obile.practices)

Steps to Reproduce

1. Clone https://github.com/roubachof/Xamarin-Forms-Practices
2. Select the "secret" branch
3. Select DebugInfinite configuration
4. Debug on android emulator

Expected Behavior

No SIGSEV should be raised

Actual Behavior

Version Information

Microsoft Visual Studio Community 2019
Version 16.5.2
VisualStudio.16.Release/16.5.2+29926.136
Microsoft .NET Framework
Version 4.8.03752

Installed Version: Community

Visual C++ 2019 00435-60000-00000-AA963
Microsoft Visual C++ 2019

ASP.NET and Web Tools 2019 16.5.236.49856
ASP.NET and Web Tools 2019

ASP.NET Web Frameworks and Tools 2019 16.5.236.49856
For additional information, visit https://www.asp.net/

Azure App Service Tools v3.0.0 16.5.236.49856
Azure App Service Tools v3.0.0

Azure Functions and Web Jobs Tools 16.5.236.49856
Azure Functions and Web Jobs Tools

C# Tools 3.5.0-beta4-20153-05+20b9af913f1b8ce0a62f72bea9e75e4aa3cf6b0e
C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Common Azure Tools 1.10
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.

Extensibility Message Bus 1.2.0 (d16-2@8b56e20)
Provides common messaging-based MEF services for loosely coupled Visual Studio extension components communication and integration.

Fabric.DiagnosticEvents 1.0
Fabric Diagnostic Events

IntelliCode Extension 1.0
IntelliCode Visual Studio Extension Detailed Info

JetBrains ReSharper Ultimate 2019.3.4 Build 193.0.20200226.112949
JetBrains ReSharper Ultimate package for Microsoft Visual Studio. For more information about ReSharper Ultimate, visit http://www.jetbrains.com/resharper. Copyright © 2020 JetBrains, Inc.

Microsoft Azure Service Fabric Tools for Visual Studio 16.0
Microsoft Azure Service Fabric Tools for Visual Studio

Microsoft Azure Tools 2.9
Microsoft Azure Tools for Microsoft Visual Studio 2019 - v2.9.30207.1

Microsoft Continuous Delivery Tools for Visual Studio 0.4
Simplifying the configuration of Azure DevOps pipelines from within the Visual Studio IDE.

Microsoft JVM Debugger 1.0
Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines

Microsoft Library Manager 2.1.25+gdacdb9b7a1
Install client-side libraries easily to any web project

Microsoft MI-Based Debugger 1.0
Provides support for connecting Visual Studio to MI compatible debuggers

Microsoft Visual C++ Wizards 1.0
Microsoft Visual C++ Wizards

Microsoft Visual Studio Tools for Containers 1.1
Develop, run, validate your ASP.NET Core applications in the target environment. F5 your application directly into a container with debugging, or CTRL + F5 to edit & refresh your app without having to rebuild the container.

Microsoft Visual Studio VC Package 1.0
Microsoft Visual Studio VC Package

Mono Debugging for Visual Studio 16.5.514 (c4f36a9)
Support for debugging Mono processes with Visual Studio.

NuGet Package Manager 5.5.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit https://docs.nuget.org/

ProjectServicesPackage Extension 1.0
ProjectServicesPackage Visual Studio Extension Detailed Info

ResXManager 1.40.3444.0
Manage localization of all ResX-Based resources in one place. Shows all resources of a solution and let's you edit the strings and their localizations in a well-arranged data grid.

SettingsWindow Extension 1.0
SettingsWindow Visual Studio Extension Detailed Info

SQL Server Data Tools 16.0.62003.05170
Microsoft SQL Server Data Tools

StylerPackage Extension 1.0
StylerPackage Visual Stuido Extension Detailed Info

TypeScript Tools 16.0.20225.2001
TypeScript Tools for Microsoft Visual Studio

Visual Basic Tools 3.5.0-beta4-20153-05+20b9af913f1b8ce0a62f72bea9e75e4aa3cf6b0e
Visual Basic components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Visual F# Tools 10.8.0.0 for F# 4.7 16.5.0-beta.20104.8+7c4de19faf36647c1ef700e655a52350840c6f03
Microsoft Visual F# Tools 10.8.0.0 for F# 4.7

Visual Studio Code Debug Adapter Host Package 1.0
Interop layer for hosting Visual Studio Code debug adapters in Visual Studio

Visual Studio Container Tools Extensions (Preview) 1.0
View, manage, and diagnose containers within Visual Studio.

Visual Studio Tools for Containers 1.0
Visual Studio Tools for Containers

Visual Studio Tools for Kubernetes 1.0
Visual Studio Tools for Kubernetes

VisualStudio.DeviceLog 1.0
Information about my package

VisualStudio.Mac 1.0
Mac Extension for Visual Studio

Xamarin 16.5.000.528 (d16-5@2b54082)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin Designer 16.5.0.470 (remotes/origin/d16-5@681de3fd6)
Visual Studio extension to enable Xamarin Designer tools in Visual Studio.

Xamarin Templates 16.5.49 (0904f41)
Templates for building iOS, Android, and Windows apps with Xamarin and Xamarin.Forms.

Xamarin.Android SDK 10.2.0.100 (d16-5/988c811)
Xamarin.Android Reference Assemblies and MSBuild support.
Mono: c0c5c78
Java.Interop: xamarin/java.interop/d16-5@fc18c54
ProGuard: xamarin/proguard@905836d
SQLite: xamarin/sqlite@46204c4
Xamarin.Android Tools: xamarin/xamarin-android-tools/d16-5@9f4ed4b

Xamarin.iOS and Xamarin.Mac SDK 13.16.0.11 (aa73e41)
Xamarin.iOS and Xamarin.Mac Reference Assemblies and MSBuild support.

Log File

[roubachof]

I had a little more info with this try:

JNI DETECTED ERROR IN APPLICATION: JNI GetMethodID called with pending exception android.runtime.JavaProxyThrowable: Sharpnado.Presentation.Forms.Droid.Renderers.MaterialFrame.RealtimeBlurView.RealtimeBlurView+StopException: Exception of type 'Sharpnado.Presentation.Forms.Droid.Renderers.MaterialFrame.RealtimeBlurView.RealtimeBlurView+StopException' was thrown.

[0:] 04-14 16:25:19.086 | SharpnadoInternals | 1 | INFO | OnPreDraw()
[0:] 04-14 16:25:19.096 | SharpnadoInternals | 1 | INFO | Draw( throwing stop exception )
**Sharpnado.Presentation.Forms.Droid.Renderers.MaterialFrame.RealtimeBlurView.RealtimeBlurView+StopException:** 'Exception of type 'Sharpnado.Presentation.Forms.Droid.Renderers.MaterialFrame.RealtimeBlurView.RealtimeBlurView+StopException' was thrown.'

04-14 16:25:20.142 D/Mono    (12442): Requesting loading reference 7 (of 8) of Mono.Android.dll
04-14 16:25:20.142 D/Mono    (12442): Loading reference 7 of Mono.Android.dll asmctx DEFAULT, looking for System.Runtime.Serialization, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e
04-14 16:25:20.143 D/Mono    (12442): Assembly Ref addref Mono.Android[0x7447141f80] -> System.Runtime.Serialization[0x73d7b6b100]: 3
04-14 16:25:24.172 D/Mono    (12442): DllImport attempting to load: '/system/lib64/liblog.so'.
04-14 16:25:24.173 D/Mono    (12442): DllImport loaded library '/system/lib64/liblog.so'.
04-14 16:25:24.173 D/Mono    (12442): DllImport searching in: '/system/lib64/liblog.so' ('/system/lib64/liblog.so').
04-14 16:25:24.173 D/Mono    (12442): Searching for '__android_log_print'.
04-14 16:25:24.173 D/Mono    (12442): Probing '__android_log_print'.
04-14 16:25:24.173 D/Mono    (12442): Found as '__android_log_print'.
04-14 16:25:24.175 I/MonoDroid(12442): UNHANDLED EXCEPTION:
04-14 16:25:24.175 I/MonoDroid(12442): Sharpnado.Presentation.Forms.Droid.Renderers.MaterialFrame.RealtimeBlurView.RealtimeBlurView+StopException: Exception of type 'Sharpnado.Presentation.Forms.Droid.Renderers.MaterialFrame.RealtimeBlurView.RealtimeBlurView+StopException' was thrown.
04-14 16:25:24.175 I/MonoDroid(12442):   at Sharpnado.Presentation.Forms.Droid.Renderers.MaterialFrame.RealtimeBlurView.RealtimeBlurView.Draw (Android.Graphics.Canvas canvas) [0x0001c] in D:\Dev\Sharpnado\src\Xamarin-Forms-Practices\Sharpnado.Presentation.Forms\Sharpnado.Presentation.Forms.Droid\Renderers\MaterialFrame\RealtimeBlurView\RealtimeBlurView.cs:420 
04-14 16:25:24.176 I/MonoDroid(12442):   at Android.Views.View.n_Draw_Landroid_graphics_Canvas_ (System.IntPtr jnienv, System.IntPtr native__this, System.IntPtr native_canvas) [0x00011] in <d3b924763d4a465c85b26f6e8edc8a53>:0 
04-14 16:25:24.176 I/MonoDroid(12442):   at (wrapper dynamic-method) Android.Runtime.DynamicMethodNameCounter.53(intptr,intptr,intptr)
04-14 16:25:24.180 W/obile.practice(12442): JNI RegisterNativeMethods: attempt to register 0 native methods for android.runtime.JavaProxyThrowable
04-14 16:25:24.181 D/Mono    (12442): DllImport searching in: '__Internal' ('(null)').
04-14 16:25:24.181 D/Mono    (12442): Searching for 'java_interop_jnienv_throw'.
04-14 16:25:24.181 D/Mono    (12442): Probing 'java_interop_jnienv_throw'.
04-14 16:25:24.181 D/Mono    (12442): Found as 'java_interop_jnienv_throw'.
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570] JNI DETECTED ERROR IN APPLICATION: JNI GetMethodID called with pending exception android.runtime.JavaProxyThrowable: Sharpnado.Presentation.Forms.Droid.Renderers.MaterialFrame.RealtimeBlurView.RealtimeBlurView+StopException: Exception of type 'Sharpnado.Presentation.Forms.Droid.Renderers.MaterialFrame.RealtimeBlurView.RealtimeBlurView+StopException' was thrown.
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at Sharpnado.Presentation.Forms.Droid.Renderers.MaterialFrame.RealtimeBlurView.RealtimeBlurView.Draw (Android.Graphics.Canvas canvas) [0x0001c] in D:\Dev\Sharpnado\src\Xamarin-Forms-Practices\Sharpnado.Presentation.Forms\Sharpnado.Presentation.Forms.Droid\Renderers\MaterialFrame\RealtimeBlurView\RealtimeBlurView.cs:420 
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at Android.Views.View.n_Draw_Landroid_graphics_Canvas_ (System.IntPtr jnienv, System.IntPtr native__this, System.IntPtr native_canvas) [0x00011] in <d3b924763d4a465c85b26f6e8edc8a53>:0 
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at (wrapper dynamic-method) Android.Runtime.DynamicMethodNameCounter.53(intptr,intptr,intptr)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void crc6481cdfe7db7671a93.RealtimeBlurView.n_draw(android.graphics.Canvas) (RealtimeBlurView.java:-2)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void crc6481cdfe7db7671a93.RealtimeBlurView.draw(android.graphics.Canvas) (RealtimeBlurView.java:72)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean android.view.View.draw(android.graphics.Canvas, android.view.ViewGroup, long) (View.java:21849)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean android.view.ViewGroup.drawChild(android.graphics.Canvas, android.view.View, long) (ViewGroup.java:4432)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.view.ViewGroup.dispatchDraw(android.graphics.Canvas) (ViewGroup.java:4193)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.view.View.draw(android.graphics.Canvas) (View.java:21978)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean android.view.View.draw(android.graphics.Canvas, android.view.ViewGroup, long) (View.java:21849)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean android.view.ViewGroup.drawChild(android.graphics.Canvas, android.view.View, long) (ViewGroup.java:4432)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.view.ViewGroup.dispatchDraw(android.graphics.Canvas) (ViewGroup.java:4193)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean android.view.View.draw(android.graphics.Canvas, android.view.ViewGroup, long) (View.java:21847)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean android.view.ViewGroup.drawChild(android.graphics.Canvas, android.view.View, long) (ViewGroup.java:4432)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.view.ViewGroup.dispatchDraw(android.graphics.Canvas) (ViewGroup.java:4193)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.view.View.draw(android.graphics.Canvas) (View.java:21978)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean android.view.View.draw(android.graphics.Canvas, android.view.ViewGroup, long) (View.java:21849)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean android.view.ViewGroup.drawChild(android.graphics.Canvas, android.view.View, long) (ViewGroup.java:4432)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.view.ViewGroup.dispatchDraw(android.graphics.Canvas) (ViewGroup.java:4193)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean android.view.View.draw(android.graphics.Canvas, android.view.ViewGroup, long) (View.java:21847)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean android.view.ViewGroup.drawChild(android.graphics.Canvas, android.view.View, long) (ViewGroup.java:4432)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.view.ViewGroup.dispatchDraw(android.graphics.Canvas) (ViewGroup.java:4193)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean android.view.View.draw(android.graphics.Canvas, android.view.ViewGroup, long) (View.java:21847)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean android.view.ViewGroup.drawChild(android.graphics.Canvas, android.view.View, long) (ViewGroup.java:4432)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.view.ViewGroup.dispatchDraw(android.graphics.Canvas) (ViewGroup.java:4193)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean android.view.View.draw(android.graphics.Canvas, android.view.ViewGroup, long) (View.java:21847)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean android.view.ViewGroup.drawChild(android.graphics.Canvas, android.view.View, long) (ViewGroup.java:4432)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.view.ViewGroup.dispatchDraw(android.graphics.Canvas) (ViewGroup.java:4193)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean android.view.View.draw(android.graphics.Canvas, android.view.ViewGroup, long) (View.java:21847)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean android.view.ViewGroup.drawChild(android.graphics.Canvas, android.view.View, long) (ViewGroup.java:4432)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.view.ViewGroup.dispatchDraw(android.graphics.Canvas) (ViewGroup.java:4193)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean android.view.View.draw(android.graphics.Canvas, android.view.ViewGroup, long) (View.java:21847)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean android.view.ViewGroup.drawChild(android.graphics.Canvas, android.view.View, long) (ViewGroup.java:4432)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.view.ViewGroup.dispatchDraw(android.graphics.Canvas) (ViewGroup.java:4193)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean android.view.View.draw(android.graphics.Canvas, android.view.ViewGroup, long) (View.java:21847)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean android.view.ViewGroup.drawChild(android.graphics.Canvas, android.view.View, long) (ViewGroup.java:4432)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.view.ViewGroup.dispatchDraw(android.graphics.Canvas) (ViewGroup.java:4193)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean android.view.View.draw(android.graphics.Canvas, android.view.ViewGroup, long) (View.java:21847)
=================================================================
	Native Crash Reporting
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

No native Android stacktrace (see debuggerd output).

=================================================================
	Basic Fault Address Reporting
=================================================================
Memory around native instruction pointer (0x7452729278):0x7452729268  

04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean android.view.ViewGroup.drawChild(android.graphics.Canvas, android.view.View, long) (ViewGroup.java:4432)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.view.ViewGroup.dispatchDraw(android.graphics.Canvas) (ViewGroup.java:4193)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean android.view.View.draw(android.graphics.Canvas, android.view.ViewGroup, long) (View.java:21847)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean android.view.ViewGroup.drawChild(android.graphics.Canvas, android.view.View, long) (ViewGroup.java:4432)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.view.ViewGroup.dispatchDraw(android.graphics.Canvas) (ViewGroup.java:4193)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.view.View.draw(android.graphics.Canvas) (View.java:21978)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void com.android.internal.policy.DecorView.draw(android.graphics.Canvas) (DecorView.java:808)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean crc6481cdfe7db7671a93.RealtimeBlurView_PreDrawListener.n_onPreDraw() (RealtimeBlurView_PreDrawListener.java:-2)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean crc6481cdfe7db7671a93.RealtimeBlurView_PreDrawListener.onPreDraw() (RealtimeBlurView_PreDrawListener.java:37)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at boolean android.view.ViewTreeObserver.dispatchOnPreDraw() (ViewTreeObserver.java:1088)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.view.ViewRootImpl.performTraversals() (ViewRootImpl.java:2769)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.view.ViewRootImpl.doTraversal() (ViewRootImpl.java:1745)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.view.ViewRootImpl$TraversalRunnable.run() (ViewRootImpl.java:7768)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.view.Choreographer$CallbackRecord.run(long) (Choreographer.java:967)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.view.Choreographer.doCallbacks(int, long) (Choreographer.java:791)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.view.Choreographer.doFrame(long, int) (Choreographer.java:726)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.view.Choreographer$FrameDisplayEventReceiver.run() (Choreographer.java:952)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.os.Handler.handleCallback(android.os.Message) (Handler.java:883)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.os.Handler.dispatchMessage(android.os.Message) (Handler.java:100)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.os.Looper.loop() (Looper.java:214)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void android.app.ActivityThread.main(java.lang.String[]) (ActivityThread.java:7356)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at java.lang.Object java.lang.reflect.Method.invoke(java.lang.Object, java.lang.Object[]) (Method.java:-2)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run() (RuntimeInit.java:492)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]   at void com.android.internal.os.ZygoteInit.main(java.lang.String[]) (ZygoteInit.java:930)
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570] 
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]     in call to GetMethodID
04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570]     from void crc6481cdfe7db7671a93.RealtimeBlurView.n_draw(android.graphics.Canvas)

This stack is interesting cause we can see all the calls from the initial DecorView.draw(android.graphics.Canvas) corresponding to the decor.Draw(blurView.mBlurringCanvas); in RealtimeBlurView.cs, to the RealtimeBlurView.Draw (Android.Graphics.Canvas canvas) line 420 matching the throw STOP_EXCEPTION; statement in the same file.

[roubachof]

So to sum-up, looking at this line of log:

04-14 16:25:24.183 F/obile.practice(12442): java_vm_ext.cc:570] 
JNI DETECTED ERROR IN APPLICATION: 
JNI GetMethodID called with pending exception android.runtime.JavaProxyThrowable: 
Sharpnado.Presentation.Forms.Droid.Renderers.MaterialFrame.RealtimeBlurView.RealtimeBlurView+StopException: 
Exception of type 'Sharpnado.Presentation.Forms.Droid.Renderers.MaterialFrame.RealtimeBlurView.RealtimeBlurView+StopException' was thrown.

It seems that JNI is mistaking a custom user exception needed for the correctness of the result, exception which should be caught by the calling method, for a Unhandled Exception.

class StopException : RuntimeException {}

class PreDrawCallback : ViewTreeObserver.IOnPreDrawListener
{
    public bool OnPreDraw()
    {

        try
        {
            ...

            decor.Draw(blurView.mBlurringCanvas); 
                |=>  throws StopException 
                    |=>  JNI throws an error outside of this scope;
        }
        catch(StopException e)
        {
        }
    }
}

[jonpryor]

You are unfortunately encountering a "corner case" of our unhandled exception debugger integration.

"Normal" .NET+IDE semantics are that exceptions are handled in "two passes":

1. The first pass is to see if the exception is unhandled, so that if a debugger is attached it can alert you that there is an unhandled exception.
2. The second pass actually performs stack unwinding, using the catch handlers found in the first pass.

Java exceptions don't have this two pass model, and the way we've "papered over" this difference is that when a debugger isn't attached -- the case which works for you! -- then at every managed-to-Java invocation boundary we catch every exception, then set a "pending exception" within Java which wraps the caught exception, then return to Java. This allows Java to raise the exception on its side, and allow any Java-side catch blocks to work. When a debugger is attached, we never handle exceptions at the VM boundaries, so that there can be an "unhandled exception" for the IDE to report.

We had a way to way to allow apps with the debugger attached to use the non-debugger exception handling case -- which is "differently broken" in that no exceptions would ever be unhandled, because (unless you're on a new Thread) there's always a Java stack frame to return to, and thus all exceptions are in fact handled! -- but this appears to have bitrotten some time in 2015.

At present, unfortunately the best I can suggest is that you not use a debugger when hitting this code path. (Printf debugging, anyone?)

What we should do is fix the feature which allowed enabling "Release"-style behavior even when a debugger is attached, so that proper exception propagation can occur.

What we should also do is figure out if there's a better way to improve this scenario.

[jonpryor]

Related:

• https://github.com/xamarin/monodroid/commit/5cef6a7bbef5173ec14ad8ad976f92d674ef18a8
• https://github.com/xamarin/xamarin-android/blob/f4fc2552299a3174a14dfeb314a2d3867218037d/src/Xamarin.Android.Build.Tasks/Tasks/GeneratePackageManagerJava.cs#L202
  • Note that we this doesn't actually check the value of XA_BROKEN_EXCEPTION_TRANSITIONS, which it really should do...
• https://github.com/xamarin/xamarin-android/blob/f4fc2552299a3174a14dfeb314a2d3867218037d/src/Mono.Android/Android.Runtime/JNINativeWrapper.cs#L72
  • Debugger.IsAttached is now the controlling factor

What we need to do is "reverse" the logic in JNINativeWrapper.cs so that we can check JNIEnv.PropagateExceptions before checking JNINativeWrapper.cs, and finagle things so that this actually "makes sense".

What we may also want to do -- but requires further consideration -- is skip this filtering for non-Java exception types. This would cause Java.Lang.Throwable subclasses to always be caught and raised on the Java side, which in turn means they could never be "unhandled". I'm still not sure if this is actually a good idea or not.

[roubachof]

Thank you for the answer, I think I understand the issue now.

I am a big fan of printf debugging, the thing is this is a visual component I'm working on (blur view for Xamarin.Forms), so it would mean that people couldn't develop their app (using hot reload...) if they are using my component...

Also, even if I disregard the debugging issue, the fact that jni throws an UnhandledException in release causes a major performance issue...

every managed-to-Java invocation boundary we catch every exception, then set a "pending exception" within Java which wraps the caught exception, then return to Java

So if an exception occurs in the Java world, and this exception is not caught in the java world, it will create an UnhandledException in jni, even in this exception is caught on the c# side (my scenario) ?
This seems a bit problematic since it breaks the semantic of the code.

[jonpryor]

This seems a bit problematic since it breaks the semantic of the code.

In "no debugger" execution, we preserve the "normal" Java runtime semantics, not the .NET IDE Debugger "two pass exception handling" semantics.

if an exception occurs in the Java world, and this exception is not caught in the java world, it will create an UnhandledException in jni, even in this exception is caught on the c#

This is where a more specific example would be handy. Imagine two implementations of java.lang.Runnable which throws an exception, one in C#, one from Java:

C#:

// C#
public class CSharpThrows : Java.Lang.IRunnable {
    public void Run()
    {
        throw new global::System.Exception("From C#!");
    }

    public static void InvokeRun(Java.Lang.IRunnable r)
    {
        r.Run();
    }
}

Java:

// Java
public class JavaThrows implements Runnable {
    public void run() {
        throw new RuntimeException("From Java!");
    }

    public static void callRun(Runnable r) {
        r.run();
    }
}

If we cause an exception to be thrown from Java, called by C#:

CSharpThrows.InvokeRun(new JavaThrows());

IRunnable.Run() is a JNI boundary. When Java throws an exception, the exception is obtainable from JNIEnv::ExceptionOccurred(), cleared in Java via JNIEnv::ExceptionClear(), and then the exception is marshaled to C# and raised within .NET.

If we cause an exception to be thrown from C#, called by Java:

JavaThrows.callRun(new CSharpThrows());

If no debugger is attached, then IRunnable.Run() is a JNI boundary...in the "other" direction: the C# exception will be caught at the boundary, wrapped into a Java.Interop.JavaProxyThrowable (if not a Java.Lang.Throwable subclass, which is the case here), the wrapped exception is set as the "pending" exception via JNIEnv::Throw(), code execution will return to Java, and Java will "throw" the pending exception. This allows Java finally blocks and catch handlers to enter the picture.

All of the above is before "unhandled exceptions" enter the picture.

On a "pure Java call stack", if there is an unhandled exception, java.lang.Thread.getDefaultUncaughtExceptionHandler() and java.lang.Thread.UncaughtExceptionHandler.uncaughtException() will be executed, providing the unhandled exception as an argument. Xamarin.Android registers with this infrastructure, and will raise the AppDomain.UnhandledException event when UncaughtExceptionHandler.uncaughtException() is executed.

As soon as there is a managed stack frame on the call stack, behavior depends upon whether or not a debugger is attached. If a C# method throws an exception or at a managed::Java stack frame boundary when the Java method throws an exception -- and the Java exception is "handled" (cleared), marshaled, and raised in managed code -- then:

When a debugger is attached, Mono will look for a managed method which handles the thrown exception. Whether or not such a handler is found, a "first chance exception" dialog will be shown in the IDE. If execution continues, then Mono will execute the handler found during the first pass, if any. If no handler was found, then AppDomain.UnhandledException will be raised.

When no debugger is attached, all JNI boundaries are considered to catch all exceptions. If a Java::managed transition is in the call stack, the exception will be caught in C#, marshaled, and raised in Java. Java will then have a chance to execute finally blocks and look for catch blocks. (If, as part of Java's normal handling, it encountered a managed::Java transition, the exception will be caught, marshaled, and raised in C#…)

[xplatform]

We also ran into a similar issue with the following code. This code worked in VS 16.5.5. But once we upgraded to VS 16.6.x, it stopped working. The RuntimeException thrown in ExitMessagePump() would cause the application to crash in the debug mode. I tried 16.7.1 and16.8.0 Preview 1.0, but neither of them worked in the debug mode.

    public void StartMessagePump()
    {
        try
        {
            Looper.Loop();
        }
        catch (Java.Lang.RuntimeException e)
        {
            // If ExitLoopHack, they want us to exit, so eat it, otherwise rethrow it
            if (e.Message != "ExitLoopHack!")
            {
                throw;
            }
        }
    }

    public void ExitMessagePump()
    {
        Device.BeginInvokeOnMainThread(() =>
        {
            // Xamarin Managed->Java->Managed exception handling is broken.
            // See issue #7634: https://bugzilla.xamarin.com/show_bug.cgi?id=7634
            // Workaround given in issue #16903: https://bugzilla.xamarin.com/show_bug.cgi?id=16903
            // This appears to work for us
            AndroidEnvironment.RaiseThrowable(new Java.Lang.RuntimeException("ExitLoopHack!"));
        });
    }

Do you think you will fix this issue in VS 16.8?

Thanks!