When debugging Guid value in an object shows wrong value

[cateyes99]

Environment data

dotnet --info output:
.NET Command Line Tools (1.0.0-rc4-004771)

Product Information:
Version: 1.0.0-rc4-004771
Commit SHA-1 hash: 4228198f0e

Runtime Environment:
OS Name: Mac OS X
OS Version: 10.11
OS Platform: Darwin
RID: osx.10.11-x64
Base Path: /usr/local/share/dotnet/sdk/1.0.0-rc4-004771
VS Code version: 1.8.1
C# Extension version: 1.7.0, 1.6.2

Steps to reproduce

Create an object which has a property of Guid.

  class A {
    public Guid Id {get; set; }
  }

Asssign Guid value '86423f60-459e-4a6f-bb26-3d7a86a972db' to A.Id. Run and debug the program.

Expected behavior

In the WATCH or VARIABLES windows, check the value the object's Guid property, it should show the correct Guid value of '86423f60-459e-4a6f-bb26-3d7a86a972db'.

Actual behavior

Actually it shows '86423f60-459e-4a6f-589f-ab0a01000000' instead!

[DustinCampbell]

Could you provide a full program? I can't repro, and I'm betting I have something set up wrong.

[gregg-miskelly]

This is the same issue as #738 (the CoreCLR doesn't correctly handle function evaluations of large structs). They partially fixed this in .NET Core 1.1, so you may be able to fix this by upgrading. A full fix will be in .NET Core 2.0.

[cateyes99]

To me, i think it's only on Mac, even it's a small structure. For example as small as this one:

    public class ActivityIdentifier
    {
        public Guid ActivityId { get; set; }
        public Guid OrganizationId { get; set; }
    }

one of my colleague who used Fedora ran the same program and don't have this bug.

I don't think we should close this.

[gregg-miskelly]

@cateyes99 a 'Guid' is not a small structure - it is 128 bits, which is why you are running into this problem. This is an issue in CoreCLR. They have a partial fix in .NET Core 1.1 (see https://github.com/dotnet/coreclr/issues/6935) and a further fix for 2.0 (https://github.com/dotnet/coreclr/issues/7115). You can work around this either by making these fields instead of properties, or by upgrading to 1.1 (and 2.0 when it comes out).

[cateyes99]

Emm, that why others like my colleague using Fedora and @DustinCampbell don't get this bug then? And I also noticed if I just declare a variable of Guid and assign the Guid value to it, it actually shows correctly in debugging windows.

var id = Guid.New();

[DustinCampbell]

I had used a recent CLI to repro, so my repro was with a netcoreapp1.1 application. Is yours the same?

[gregg-miskelly]

@cateyes99 this bug only applies when dealing with functions (such as a property getter like in your example). If you have a local variable, the debugger doesn't need to run code in the target process so we can correctly display it.

[cateyes99]

ic, thanks. It is on .NET Core 1.0 and tested on my Mac. After upgrading to 1.1, it does show correctly. But still don't get why my colleague didn't have the bug on his Fedora.