[Java.Interop] Add JniIdentityHashCode to ObjectDisposedException #1276
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Context: dotnet/android#9039 Context: dotnet/android@32495f3 @jonpryor suspects that the `ObjectDisposedException` being thrown within dotnet/android#9039 *may* be due to a GC-related bug. A problem with diagnosing this is tracking object lifetimes: yes, an `Android.Runtime.InputStreamInvoker` is throwing `ObjectDisposedException`, but in local reproductions, there are *multiple* `InputStreamInvoker` instances created! Which one is throwing? A local answer to that was "Update `InputStreamInvoker.Read()` to log `BaseInputStream.JniIdentityHashCode`", which *was* useful, but is not a "scalable" solution. Review all `throw new ObjectDisposedException()` calls within `Java.Interop.dll`, and update all sites which use `IJavaPeerable` to include the `JniIdentityHashCode` value in the exception message. This would result in a message like: System.ObjectDisposedException: Cannot access disposed object with JniIdentityHashCode=0x12345678. Object name: 'Android.Runtime.InputStreamInvoker'. at Java.Interop.JniPeerMembers.AssertSelf(IJavaPeerable ) …
jonathanpeppers
approved these changes
Nov 8, 2024
jonpryor
deleted the
dev/jonp/jonp-IdentityHashCode-in-ObjectDisposedException
branch
jonpryor
added a commit
to dotnet/android
that referenced
this pull request
Nov 8, 2024
Changes: dotnet/java-interop@2bdf2bc...2440416 * dotnet/java-interop@24404162: [Java.Interop] Add JniIdentityHashCode to ObjectDisposedException (dotnet/java-interop#1276)
jonpryor
added a commit
to dotnet/android
that referenced
this pull request
Nov 8, 2024
Changes: dotnet/java-interop@2bdf2bc...2440416 * dotnet/java-interop@24404162: [Java.Interop] Add JniIdentityHashCode to ObjectDisposedException (dotnet/java-interop#1276)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context: dotnet/android#9039
Context: dotnet/android@32495f3
@jonpryor suspects that the
ObjectDisposedExceptionbeing thrown within dotnet/android#9039 may be due to a GC-related bug.A problem with diagnosing this is tracking object lifetimes: yes, an
Android.Runtime.InputStreamInvokeris throwingObjectDisposedException, but in local reproductions, there are multipleInputStreamInvokerinstances created! Which one is throwing?A local answer to that was "Update
InputStreamInvoker.Read()to logBaseInputStream.JniIdentityHashCode", which was useful, but is not a "scalable" solution.Review all
throw new ObjectDisposedException()calls withinJava.Interop.dll, and update all sites which useIJavaPeerableto include theJniIdentityHashCodevalue in the exception message. This would result in a message like: