Open roubachof opened 4 years ago
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.
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)
{
}
}
}
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":
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.
Related:
XA_BROKEN_EXCEPTION_TRANSITIONS
, which it really should do...Debugger.IsAttached
is now the controlling factorWhat 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.
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.
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#…)
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!
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:
Steps to Reproduce
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/master@905836d SQLite: xamarin/sqlite/3.28.0@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