Fix XA_BROKEN_EXCEPTION_TRANSITIONS support #4548
Comments
roubachof
changed the title
|
I had a little more info with this try:
This stack is interesting cause we can see all the calls from the initial |
|
So to sum-up, looking at this line of log: 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)
{
}
}
} |
roubachof
changed the title
|
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":
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
changed the title
|
Related:
What we need to do is "reverse" the logic in What we may also want to do -- but requires further consideration -- is skip this filtering for non-Java exception types. This would cause |
|
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
So if an exception occurs in the Java world, and this exception is not caught in the java world, it will create an |
In "no debugger" execution, we preserve the "normal" Java runtime semantics, not the .NET IDE Debugger "two pass exception handling" semantics.
This is where a more specific example would be handy. Imagine two implementations of 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());
If we cause an exception to be thrown from C#, called by Java: JavaThrows.callRun(new CSharpThrows());If no debugger is attached, then All of the above is before "unhandled exceptions" enter the picture. On a "pure Java call stack", if there is an unhandled exception, 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 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 |
|
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. 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
Drawmethod 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@fc18c54
ProGuard: xamarin/proguard@905836d
SQLite: xamarin/sqlite@46204c4
Xamarin.Android Tools: xamarin/xamarin-android-tools@9f4ed4b
Xamarin.iOS and Xamarin.Mac SDK 13.16.0.11 (aa73e41)
Xamarin.iOS and Xamarin.Mac Reference Assemblies and MSBuild support.
Log File
The text was updated successfully, but these errors were encountered: