通过SOS CLR调查 [英] Investigation of CLR via SOS

问题描述

目前，我挖更深的CLR，并试图找到我的管理对象的适当大小。

Currently I am digging deeper into CLR and try to find proper size of my managed objects.

我有两个简单类型：

XClass

    class XClass
{
    public XStruct StructField = new XStruct();
    public int IntField;
    public double DoubleField;
}

和 XStruct

struct XStruct
{
    public short ShortField;
    public long LongField;
}

此外cosider code段，其中涉及该对象：

Also cosider code snippet where this objects are involved:

static unsafe void Main(string[] args)
{
    double angle = 0.34;

    {
        double anotherDouble = 1.49;

        XStruct xStruct = new XStruct();
        xStruct.ShortField = 12;
        xStruct.LongField = 1234567890;

        XClass classObject = new XClass();
        classObject.DoubleField = angle + anotherDouble;
        classObject.IntField = 123;
        classObject.StructField = xStruct;

        <<<<<<<<BREAKPOINT>>>>>>>

        xStruct.ShortField = 3;
    }

    double* ptr = &angle;

    Console.WriteLine(*(ptr - 1));
    Console.ReadKey();
}

所以，我试图让有关XStruct放置在堆栈中的一些信息，但我不能找到它。

So, I try to get some info about XStruct placed in stack, but I cannot find it there.

!dso
PDB symbol for clr.dll not loaded
OS Thread Id: 0x1f94 (8084)
ESP/REG  Object   Name
0018EF1C 0260252c ConsoleApplication2.XClass
0018EF20 0260252c ConsoleApplication2.XClass
0018F290 0260252c ConsoleApplication2.XClass
0018F2C4 0260251c System.Object[]    (System.String[])
0018F2E0 0260252c ConsoleApplication2.XClass
0018F2E8 0260252c ConsoleApplication2.XClass
0018F30C 0260251c System.Object[]    (System.String[])
0018F3C0 0260251c System.Object[]    (System.String[])
0018F51C 0260251c System.Object[]    (System.String[])
0018F554 0260251c System.Object[]    (System.String[])
0018FA90 02601238 System.SharedStatics

请解释为什么 ConsoleApplication2.XStruct 不显示为什么 ConsoleApplication2.XClass 显示为堆栈对象。我认为XClass（如正常参考型）应该放在堆中。或者，也许是我的的理解！DSO 不正确。

Please, explain why ConsoleApplication2.XStruct is not displayed and why ConsoleApplication2.XClass is displayed as object in stack. I thought that XClass (as normal reference type) should be placed in heap. Or may be my understanding of !dso is incorrect.

感谢。

推荐答案

！DSO ==转储的堆栈对象。围绕对象，一个结构是不是一个对象。

!dso == Dump Stack Objects. Focus on "Objects", a struct is not an object.

的唯一原因，SOS能够查找对象引用的一切都是因为它可以使用，当它编译的方法的抖动所产生的元数据。此数据由垃圾收集器时，它会执行堆栈散步找对象引用回来。你可以阅读更多关于它在这个答案。值类型值从该元数据丢失，GC不关心他们。

The only reason that SOS is capable of finding objects references at all is because it can use the metadata that the jitter generates when it compiles a method. This data is used by the garbage collector when it performs stack walks to find object references back. You can read more about it in this answer. Value type values are missing from this metadata, the GC doesn't care about them.

您可以通过创建它们的数组，给结构的第一个字段一个独特的价值推断结构的大小。看看与VS调试，调试+的Windows +内存+内存1的阵列，把变量名中的地址栏中。你会在结构值早在十六进制转储，阵头之后。千万要注意，结构，大小依赖于CLR版本和程序的位数因此只使用此信息作为提示。

You can infer the size of a struct by creating an array of them, giving the first field of the struct a distinctive value. Look at the array with the VS debugger, Debug + Windows + Memory + Memory1, put the variable name in the Address field. You'll the struct values back in the hex dump, after the array header. Do beware that structure sizes depend on the CLR version and the bitness of the process so only ever use this info as a hint.

这篇关于通过SOS CLR调查的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！