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/7.0-staging] Fix a memory leak in runtime interop stubs when using an array of structs of types that use old-style managed marshalers #93148

Merged

Conversation

github-actions[bot]
Copy link
Contributor

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

Backport of #93089 to release/7.0-staging

/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/7.0-staging] [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/7.0-staging] 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 7.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/7.0-staging branch from 9d8610c to c503766 Compare October 9, 2023 18:15
@jkoritzinsky jkoritzinsky merged commit be8f744 into release/7.0-staging Oct 9, 2023
110 checks passed
@jkotas jkotas deleted the backport/pr-93147-to-release/7.0-staging branch October 13, 2023 01:49
@ghost ghost locked as resolved and limited conversation to collaborators Nov 12, 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.

3 participants