Fix CLR->COM RCW ownership tracking on the slow path#126731
Fix CLR->COM RCW ownership tracking on the slow path#126731AaronRobinsonMSFT merged 2 commits intodotnet:mainfrom
Conversation
Have the slow GetCOMIPFromRCW helper report whether the returned interface pointer actually requires cleanup, so RCW cache hits after OLE TLS initialization are not released as if they were freshly acquired.\n\nFixes dotnet#126619\n\nCo-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Tagging subscribers to this area: @agocke |
There was a problem hiding this comment.
Pull request overview
Fixes CLR→COM stub cleanup ownership tracking when StubHelpers.GetCOMIPFromRCW() falls back to the slow path on native-created threads, preventing erroneous Release calls for RCW-cache hits after OLE TLS initialization (issue #126619).
Changes:
- Extend the QCall slow helper (
StubHelpers_GetCOMIPFromRCWSlow) to return an explicitpfNeedsReleaseflag. - Update the slow helper implementation to set
pfNeedsRelease=trueonly for freshly acquired COM IPs (and keep it false for RCW-cache hits). - Update managed
StubHelpers.GetCOMIPFromRCWto delegatepfNeedsReleasedetermination to the slow path.
Show a summary per file
| File | Description |
|---|---|
| src/coreclr/vm/stubhelpers.h | Updates the slow-path QCall signature to include an explicit ownership/cleanup flag. |
| src/coreclr/vm/stubhelpers.cpp | Implements ownership tracking: cache hits return borrowed pointers (no release), fresh acquisitions require release. |
| src/coreclr/System.Private.CoreLib/src/System/StubHelpers.cs | Plumbs pfNeedsRelease through the slow path so cleanup behavior matches actual pointer ownership. |
Copilot's findings
- Files reviewed: 3/3 changed files
- Comments generated: 1
Extend TrackMyLifetimeTesting with a simple Method() call and add a native-thread callback test that exercises the agile RCW path covered by dotnet#126619. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
@elinor-fung @jkoritzinsky I've added a test here. It was a bit complicated and I wasted about an hour trying to reason why other tests were failing. Apparently Copilot missed the semantic meaning of |
|
/backport to release/10.0 |
|
Started backporting to |
…126757) Backport of #126731 to release/10.0 /cc @AaronRobinsonMSFT ## Customer Impact - [x] Customer reported - [ ] Found internally This causes issues with COM object lifetime management. It is a real issue with COM interop and will impact anyone using COM interop from an unmanaged thread. User reported issue can be found at #126619. ## Regression - [x] Yes - [ ] No This was introduced in #114609. That work was apart of the removal of `HELPER_METHOD_FRAME` completed in .NET 10 - #95695. ## Testing A test has been added to ensure this particular issue won't crop up again and adds more coverage to built-in COM interop support. ## Risk Low. This is addressing a real regression and putting back the logic to what is was prior to work done around `HELPER_METHOD_FRAME` removal. --------- Co-authored-by: Aaron R Robinson <arobins@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Fixes #126619.
This was a regression introduced in #114609
When
System.StubHelpers.GetCOMIPFromRCW()misses the fast path on a native-created thread, the slow path can create OLE TLS and still resolve the COM interface pointer from the RCW cache. Those cache hits are borrowed and should not be released by the stub cleanup path.This change moves the
pfNeedsReleasedecision to the slow helper so it can distinguish between:ComObject::GetComIPFromRCWThrowingTesting: