Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Fix leak by freeing NSObjectData#24094

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Draft
BrzVlad wants to merge1 commit intodotnet:main
base:main
Choose a base branch
Loading
fromBrzVlad:fix-nsobject-leak

Conversation

@BrzVlad
Copy link
Member

Every NSObject allocates native memory forNSObjectData via aNSObjectDataHandle critical handle. When the handle dies, the memory wasn't reclaimed becauseIsInvalid method was implemented incorrectly. Fixing this bug, leads to crashes inReleaseManagedRef which tries to access the native data that was already freed. Normally, this shouldn't happen becauseNSObject is a normal finalizable object andNSObjectDataHandle is a critical finalizable object. This means that the finalizer forNSObject would always run first, considering that the 2 objects die at the same time. This means that the nativeNSObjectData would be cleared only after the finalizer forNSObject has run andReleaseManagedRef finished executing. However, this is not the case because the "finalization" code ofNSObject is not run from the finalizer thread but it is enqueued toNSObject_Disposer. This means that now the critical finalizer could have actually released the native memory before the finalization of theNSObject is done.

The simple fix for this is to create a GCHandle keeping theNSObjectDataHandle alive until allNSObject finalization is done, at the end ofReleaseManagedRef.

dartasen reacted with eyes emoji
Every NSObject allocates native memory for `NSObjectData` via a `NSObjectDataHandle` critical handle. When the handle dies, the memory wasn't reclaimed because `IsInvalid` method was implemented incorrectly. Fixing this bug, leads to crashes in `ReleaseManagedRef` which tries to access the native data that was already freed. Normally, this shouldn't happen because `NSObject` is a normal finalizable object and `NSObjectDataHandle` is a critical finalizable object. This means that the finalizer for `NSObject` would always run first, considering that the 2 objects die at the same time. This means that the native `NSObjectData` would be cleared only after the finalizer for `NSObject` has run and `ReleaseManagedRef` finished executing. However, this is not the case because the "finalization" code of `NSObject` is not run from the finalizer thread but it is enqueued to `NSObject_Disposer`. This means that now the critical finalizer could have actually released the native memory before the finalization of the `NSObject` is done.The simple fix for this is to create a GCHandle keeping the `NSObjectDataHandle` alive until all `NSObject` finalization is done, at the end of `ReleaseManagedRef`.
@BrzVlad
Copy link
MemberAuthor

This seems to have started happening after#23300. I didn't look into that change and I don't have much understanding of this area. Fixes a leak I noticed in an app reported indotnet/runtime#119491. The app was leaking about 50mb per 3hours, so it looks like this could be problematic in certain scenarios. Tested locally by rebuildingMicrosoft.iOS.dll and patching the above app with it.


publicoverrideboolIsInvalid{
get=>handle!=IntPtr.Zero;
get=>handle==IntPtr.Zero;
Copy link
Member

Choose a reason for hiding this comment

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

🤦‍♂️

dartasen reacted with laugh emoji
@rolfbjarnerolfbjarne self-assigned thisOct 24, 2025
@rolfbjarnerolfbjarne marked this pull request as draftOctober 27, 2025 17:27
@dartasen
Copy link
Contributor

Is there any progress towards that critical subject ?

@rolfbjarne
Copy link
Member

@dartasen this is actively being worked on, we're trying different solutions to find the best one with the least impact to execution speed and memory usage.

dartasen reacted with heart emoji

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@rolfbjarnerolfbjarnerolfbjarne left review comments

At least 1 approving review is required to merge this pull request.

Assignees

@rolfbjarnerolfbjarne

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@BrzVlad@dartasen@rolfbjarne

[8]ページ先頭

©2009-2025 Movatter.jp