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

[release/8.0] Fix a memory leak in runtime interop stubs when using an array of structs of types that use old-style managed marshalers #93150

Merged
merged 2 commits into from
Oct 12, 2023

Conversation

github-actions[bot]
Copy link
Contributor

@github-actions github-actions bot commented Oct 6, 2023

Backport of #93089 to release/8.0

/cc @jkoritzinsky

Description

When passing an array of structs that contains an array field marshalled as a SAFEARRAY or "ByValArray" field to a P/Invoke or a COM interop call, the native array and its contents are not released. This PR changes the marshalling logic such that the native array and contents will be released when they should be.

Customer Impact

Customers without this fix that have interop code with this shape will have unmanaged memory leaks.

Regression

This is a regression that was introduced in .NET 5.

Testing

This fix has been manually validated in main and a unit test has been added to the PR in main. This fix has also manually been validated in the 6.0 branch with the customer and it fixes their scenario.

Risk

The risk for this PR is low. The logic here will only be hit in these two scenarios, and the expected and documented behavior is that we do not leak this memory. It is very unlikely that customers have taken a dependency on this memory being leaked.

@jkoritzinsky jkoritzinsky changed the title [release/8.0] [release/6.0] Fix a memory leak in runtime interop stubs when using an array of structs of types that use old-style managed marshalers [release/8.0] Fix a memory leak in runtime interop stubs when using an array of structs of types that use old-style managed marshalers Oct 6, 2023
@jkoritzinsky jkoritzinsky added the Servicing-consider Issue for next servicing release review label Oct 6, 2023
Copy link
Member

@jeffschwMSFT jeffschwMSFT left a comment

Choose a reason for hiding this comment

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

approved. please get a code review. we will take for consideration in 8.0.x

@jeffschwMSFT jeffschwMSFT added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Oct 9, 2023
@github-actions github-actions bot force-pushed the backport/pr-93147-to-release/8.0 branch from 9b80bde to 325eb62 Compare October 9, 2023 18:14
@jkoritzinsky
Copy link
Member

This PR is ready to be merged by someone who is authorized (I don't have authorization).

@carlossanlop
Copy link
Member

This PR is ready to be merged by someone who is authorized (I don't have authorization).

That would be me @jkoritzinsky . Feel free to ping me via Teams if you'd like me to merge a PR that is ready.

@carlossanlop carlossanlop merged commit d618afa into release/8.0 Oct 12, 2023
111 checks passed
@carlossanlop carlossanlop deleted the backport/pr-93147-to-release/8.0 branch October 12, 2023 00:03
@ghost ghost locked as resolved and limited conversation to collaborators Nov 11, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-Interop-coreclr Servicing-approved Approved for servicing release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants