GCHandle Target unexpectedly change during VS debugger breakpoint debugging

[Liangjia0411]

Description

When using coreclr as the runtime and debugging C# code with Visual Studio debugger, we discovered that the GCHandle's Target value unexpectedly changes (becomes null or changes to objects of other types). This causes program exceptions. This issue only occurs when using debugger breakpoints; the program runs normally without breakpoint debugging.

Environment Information

• .NET version: 9.0.3
• Visual Studio version: 17.13.2

Additional Information

We suspect this might be related to how the debugger handles interactions between managed and unmanaged code, especially when dealing with pinned GCHandles. This leads to abnormal garbage collector behavior or the debugger incorrectly displaying/modifying the GCHandle's target.

Reproduction Steps

1. Use coreclr as the runtime
2. Enable mixed debugging (Native + Managed)
3. Set a breakpoint at the third line of the following code:

public static unsafe bool LoadFileToArray(ref byte[] Result, string FileName, uint Flags = 0) 
{
   using var gcHandleScopeForResult = new Interop.GCHandleScope(Result, GCHandleType.Pinned);
   var interopArrayForResult = new Interop.RefStructArray<byte>(Result, gcHandleScopeForResult.GetHandle());
   bool Return_Temp = MonoInit.BoolConverter.ToManagedBool(Internal_LoadFileToArray(ref interopArrayForResult, FileName, Flags));
   Result = interopArrayForResult.GetArrayAfterInterop();
   return Return_Temp;
}

Expected behavior

When execution reaches the third line, the GCHandle in gcHandleScopeForResult should still point to the passed Result array.

Actual behavior

1. In the first line of code, a GCHandle is created for Result and stored in gcHandleScopeForResult
2. When the breakpoint hits the third line, we find that the GCHandle's Target in gcHandleScopeForResult has become null

3. With mixed debugging enabled, this issue consistently occurs in specific scenarios when breaking at this function, but we haven't encountered this problem in other scenarios
4. With mixed debugging enabled, if no breakpoints are set, the program runs normally
5. As we continue stepping through with breakpoints, the Target value may change again, for example, in one case it changed to a string object

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

[jkotas]

One possible explanation of this crash is that your program has use-after-free or double-free bug related to GC handles. Bugs like that are non-deterministic, and it just happens that the crash only reproduces under debugger in your case.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

[Liangjia0411]

I think it's a problem with the debugger; The exception will only occur when mixed debugging is enabled and breakpoints are made in the above code at specific times, otherwise the related functions can run normally

[AaronRobinsonMSFT]

@Liangjia0411 The debugger doesn't modify a user's GCHandles. As @jkotas mentioned this is likely related to user code being freed. Can you please share the code for the marshalling logic in that function. I'm unfamiliar with those APIs so I'm assuming they are yours or from a package.

[Liangjia0411]

@jkotas @AaronRobinsonMSFT The problem here is indeed caused by the GCHandle I assigned being freed in another thread.
I found that a thread called .NET Counter Poller released my GCHandle. Do you know what this is?

[jkotas]

The most likely explanation is that you have use-after-free bug in your code. Your code freed the GCHandle while still keeping a copy of it somewhere, .NET Counter Poller allocated the handle, set it to a new value and it is freeing it know.

GCHandle is unsafe primitive with manually managed lifetime, similar to native memory. You have to be very careful to free it exactly once and do not use it after it has been freed. If you do not free it, it is memory leak. If you free it more than once, it is double-free bug. If you use it after it has been freed, it is use-after-free bug.

[Liangjia0411]

The current scenario is: I create a GCHandle, and this GCHandle was immediately released by .NET Counter Poller

[jkotas]

Have any of your code (or code in NuGet packages referenced by your app) operated on GCHandles before this point? Or is this the very first time your code operates on GCHandles in your app?

[Liangjia0411]

Prior to this, GCHandles had been used before

[jkotas]

There is likely a GCHandle double-free bug in the code that run prior to this point.