Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[debugger] Calling embedded api and avoid changing System.Diagnostics.Debugger class. #6106

Merged

Conversation

thaystg
Copy link
Member

@thaystg thaystg commented Jul 20, 2021

Waiting this to be merged dotnet/runtime#56071

@thaystg thaystg requested review from jonpryor and grendello July 20, 2021 21:23
@thaystg thaystg changed the title [debugger] Trying to use embedded api and avoid changing System.Diagnostics.Debugger class. [debugger] Calling embedded api and avoid changing System.Diagnostics.Debugger class. Jul 20, 2021
@@ -247,8 +247,13 @@ static void ManualJavaObjectDispose (Java.Lang.Object obj)
static void Initialize ()
{
if (mono_unhandled_exception == null) {
#if NETCOREAPP
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels "wasteful", in that we're using Reflection to create a delegate for a method which is directly convertible to the desired type without using Reflection.

Thus, I'd prefer:

#if NETCOREAPP
				mono_unhandled_exception = monodroid_debugger_unhandled_exception;
#else   // NETCOREAPP
				var mono_UnhandledException = typeof (System.Diagnostics.Debugger)
					.GetMethod ("Mono_UnhandledException", BindingFlags.NonPublic | BindingFlags.Static);
				if (mono_UnhandledException != null)
					mono_unhandled_exception = (Action<Exception>) Delegate.CreateDelegate (typeof(Action<Exception>), mono_UnhandledException);
#endif  // NETCOREAPP

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed :)

var mono_UnhandledException = typeof (System.Diagnostics.Debugger)
.GetMethod ("Mono_UnhandledException", BindingFlags.NonPublic | BindingFlags.Static);
#endif
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code convention: #else and #endif statements should have a comment "describing" the condition they're associated with, e.g.

#endif  // NETCOREAPP

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed :)

@@ -20,6 +20,12 @@ static void get_runtime_types ()
"Mono_UnhandledException", BindingFlags.NonPublic | BindingFlags.Static);
if (mono_unhandled_exception_method == null)
AndroidEnvironment.FailFast ("Cannot find System.Diagnostics.Debugger.Mono_UnhandledException");
#endif
#if NETCOREAPP
mono_unhandled_exception_method = typeof (Android.Runtime.JNIEnv).GetMethod (
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of duplicating this logic, we should instead make JNIEnv.mono_unhandled_exception internal, so that we can directly access it here:

mono_unhandled_exception_method = JNIEnv.mono_unhandled_exception.Method;

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed :)

@thaystg thaystg marked this pull request as ready for review July 22, 2021 12:10
@thaystg
Copy link
Member Author

thaystg commented Jul 22, 2021

@jonpryor now that it's already merged on dotnet/runtime preview 7, I think this is ready for review. Do I need to bump runtime version anywhere to get the exported function working?

@jonpryor
Copy link
Member

@thaystg asked:

Do I need to bump runtime version anywhere to get the exported function working?

Kinda; dotnet-maestro does bumps, e.g. PR #6110, but PR #6110 (currently) bumps to dotnet/runtime@bd35632, which doesn't include mono_debugger_agent_unhandled_exception(), added in dotnet/runtime@3746672.

Additionally, PR #6110 has introduced issues, e.g. satellite assembly handling has changed (?!): #6110 (comment)

I don't know when we can bump main/rc1.

Which leaves .NET 6 Preview 7; we have a PR to bump that as well: PR #6112. PR #6112 fails to build for not currently understood reasons, and PR #6112 currently bumps to commit dotnet/runtime@ ba08d9a305e2e0debeed1c96b3137b44305466b8, which doesn't include dotnet/runtime@743bd89.

@thaystg: Would you be able to investigate why PR #6112 is failing to build? Once we get #6112 building and bumped to something that includes dotnet/runtime@743bd894c, we could re-target this PR (#6106) to target the release/6.0.1xx-preview7 branch.

…er_unhandled_exception

* origin/main:
  Bump to dotnet/installer@19943da 6.0.100-rc.1.21372.10 (dotnet#6110)
  [xaprepare] don't install microsoft-net-runtime-android workload (dotnet#6114)
  [Mono.Android] Use `mono_unhandled_exception` for NET6 (dotnet#6104)
  Bump to dotnet/installer@9c463710 6.0.100-rc.1.21369 (dotnet#6072)
  Bump to xamarin/xamarin-android-binutils/2.37-XA.1@77618674 v2.37 (dotnet#6096)
  [Mono.Android.Export] Fix DynamicDependency to JavaArray (dotnet#6105)
  [xaprepare] always delete ~/android-toolchain/dotnet (dotnet#6098)
  [CI] Add nuget to msi conversion and VS insert stage (dotnet#6030)
  [build] delete platform-31 folder on test jobs (dotnet#6103)
@jonpryor
Copy link
Member

@thaystg
Copy link
Member Author

thaystg commented Jul 23, 2021

latest PR build: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=5012864&view=results

I think the build is finished and passed, can we merge?
Should I do something manually to backport to preview 7?

@jonpryor
Copy link
Member

jonpryor commented Jul 23, 2021

Commit message:

[One .NET] Use new API for exception debugger notification (#6106)

Context: https://github.com/dotnet/runtime/pull/56071
Context: https://github.com/xamarin/xamarin-android/pull/4877
Context: https://github.com/xamarin/xamarin-android/pull/4927#discussion_r490457925
Context: https://github.com/xamarin/xamarin-android/pull/4927#issuecomment-875864999

Context: https://github.com/xamarin/monodroid/commit/3e9de5a51bd46263b08365ef18bed1ae472122d8
Context: https://github.com/xamarin/monodroid/commit/b0f85970102d43bab9cd860a8e8884d136d766b3
Context: https://github.com/xamarin/monodroid/commit/12a012e00b4533d586ef31ced33351b63c9de883

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 xamarin/xamarin-android#4877 for details.

What Legacy Xamarin.Android does is also detailed in
xamarin/xamarin-android#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.

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

@jonpryor jonpryor merged commit e4debf7 into dotnet:main Jul 23, 2021
jonpryor pushed a commit that referenced this pull request Jul 23, 2021
[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
@github-actions github-actions bot locked and limited conversation to collaborators Jan 25, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants