System.Runtime.InteropServices.StructLayoutAttribute.Size behavior on reference types

[seanoct]

Description

We’re seeing this issue when we try to migrate our solution from .NET 6 to .NET 8.

Once we got the code compiling and running, our application freezes. I guess something changed from .NET 6 to .NET 8 that isn’t apparent.

After some digging around, this is what I've found.
We have some 3rd party objects that implement IDispose. The 3rd party objects seems to do a lock (this) {} in their Dispose and it is out of our control.

Now when we instantiate an instance of this object inside a using {} block, the code hangs at the closing scope.

key.Down() returns a new instance of SegmentKey (as far as I can tell from VS decompilation) with some vendor bookkeeping logic.

If we remove the using block, the GC thread will freeze (eventually) – I’m assuming that it’s also hitting the lock.

This is what our code looks like when it freezes:

public static bool HasSubkey(this SegmentKey key, string name)
{
    using (SegmentKey subkey = key.Down(name, false))
    {
        try
        {
            return subkey.Name() == name;
        }
        catch { }
    } // freezes here
    return false;
}

This is what the SegmentKey’s (3rd party) Dispose looks like from VS decompilation:

public override void Dispose()
{
    lock (this) // debugger says that we freeze here
    {
        .
        .
        .
    }
}

Looking into this, I peeked around the memory and cross referenced with documentation on how CLR objects work (https://mycodingplace.wordpress.com/2018/01/10/object-header-get-complicated/). I see this:

If my understanding is correct, that value of 0x0100007f indicates that our object is BIT_SBLK_SPIN_LOCK’ed.

I thought maybe the vendor is doing something silly, so I experimented with a plain C# object. It too had BIT_SBLK_SPIN_LOCK (among other bits set).

If I try to lock o, then the thread freezes – even if I do so directly after allocation:

public static bool HasSubkey(this SegmentKey key, string name)
{
    System.Object o = new System.Object();
    lock (o) { } // freezes on lock

    using (SegmentKey subkey = key.Down(name, false))
    {
        try
        {
            return subkey.Name() == name;
        }
        catch { }
    }
    return false;
}

I don't think threads are involved. This is all happening on the main thread. It seems like the main thread is deadlocking itself.

For me, this is 100% reproducible on .NET 8. It always happens on the 4th call to HasSubKey (which I determined by counting breakpoint hits).

I tried clearing out the bin/ directory and forcing a clean rebuild. Didn't help.

I’ve also tried the clrgc trick from this post: https://maoni0.medium.com/is-the-regression-in-gc-or-something-else-38f10018dd21 (which I discovered after reading through #95191). I was successfully able to load clrgc, but it didn’t have any noticeable effect on preventing the freeze.

Reproduction Steps

not sure if I can provide a sandboxed repro steps

Expected behavior

a newly instantiated object isn't locked

Actual behavior

a newly instantiated object is locked

Regression?

No response

Known Workarounds

No response

Configuration

Windows 11 x64

trying to migrate .NET 6 -> 8

Other information

Not sure if this is useful, I think if you try to do Monitor.TryLock() on this object, the function never returns -- and the thread deadlocks as well

[dotnet-policy-service]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

[jkotas]

The memory that the new objects are allocated from is expected to be filled with zeros. From your screenshots, it looks like that 3ff000 was somehow written into this memory and that makes the object appear locked. We need to find how 3ff000 got written into that memory.

What's the debugger and version that you use to debug the app? Does the problem reproduce without your debugger attached?

[seanoct]

Visual Studio 17.12.4

Regardless if run it from visual studio or directly out of the bin/ directory (i.e. double-click the exe), the freeze will occur.

[jkotas]

Would you be able to use Time Travel Debugging to diagnose this? The steps are:
  

1. Install windbg debugger (https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/)
2. Find TTD.exe tool in the windbg installation and run your app under it in an admin window: TTD.exe <path_to_your_app>.exe. It should generate time trace trace.
3. Start windbg debugger and open the time travel trace generated by previous step.

Once you are in the windbg debugger, open the prompt:

• g to run to the end of the trace
• Find the address of memory location with the bad 3fff value
• ba w4 <hex address> to set a write breakpoint at 4 bytes that are corrupted
• g- to run execution backwards. It should stop at the place where the offending 3fff got written

Let me know if you need help with any of these steps.

[seanoct]

I'll look at this more tomorrow. I need some time to familiarize myself with this tool

[seanoct]

I think I might have found something. @jkotas, is there a way that we can talk about it offline?

[jkotas]

You can email me (my email is in my github profile) and we can go from there.

[seanoct]

I sent you an email. Hopefully you received it!

[jkotas]

Thank you for sharing the details. Here is a simplified repro:

[StructLayout(LayoutKind.Explicit, Size=100)]
class Test
{
    [FieldOffset(0)]
    private byte b;

    unsafe void M()
    {
        fixed (byte* p = &b)
        {
            // Code treats p as a pointer to a buffer of 100 bytes and ends up overwriting memory
            // beyond the end of this instance
        }
    }
}

StructLayout controls unmanaged layout of the type (ie the layout that you get when calling Marshal.StructureToPtr). The managed layout matches the unmanaged layout for blittable types only. The problem in this specific example is that the type is not treated as blittable and the runtime only allocates one byte of memory in the managed layout.

@jkoritzinsky Is it expected that StructLayoutAttribute.Size is not respected for managed layout in this example?

[seanoct]

This seems dangerous from a contractual perspective (between a compiler <-> programmer).

https://learn.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.structlayoutattribute talks a bit about blittable/non-blittable data types and memory layout. It doesn't clearly spell out what it does if StructLayoutAttribute.Size isn't in agreement with the size calculated from the fields.

I think -- regardless of blittable/non-blittable data types -- the compiler should respect StructLayoutAttribute.Size if it's > 0.