StackTrace/StackFrame don't have a file name or position in .NET Core on Windows, but do with .NET Core on Unix and .NET Framework

[hughbe]

The following example is a test that passes with netfx, passes with netcoreapp on Unix, but not with netcoreapp on Windows.

[Fact]
public void Ctor_FileInfo_CorrectlyGetsFileName()
{
    var stackTrace = new StackTrace(fNeedFileInfo: true);
    StackFrame[] frames = stackTrace.GetFrames());
    Assert.True(frames.Any(f => f.GetFileName() != null));
}

[karelz]

That's weird. @joperezr is it on purpose?

[hughbe]

This seems like a recent regression. I actually noticed it before writing tests in dotnet/corefx#21040 (they fail on Unix because of this bug), because the stack trace test failures no longer have line numbers or file info in them with .NET Core. This made it super hard to track down failures. But when I changed to .NET Framework, I had line numbers

I thought it was just a tooling thing, but looks like a bug, and a pretty bad one at that.

[karelz]

That looks suspicious, @joperezr can you please take a look for 2.0 into it? (or route it ASAP) Thanks!
cc @danmosemsft

[danmoseley]

@noahfalk ?

[hughbe]

This issue gets even weirder. I only occurs in Debug mode on Windows, not Release

[stephentoub]

cc: @mikem8361

[mikem8361]

If the only scenario that this occurs is on Windows Debug, then I'm moving it to 2.1.

[hughbe]

@mikem8361 could you also confirm that this isn't the cause of the following difference between netfx and netcoreapp (on Windows)

Code:

[Fact]
public void InvokeMethodThatThrowsException()
{
    ThrowExceptionPlease();
}

public void ThrowExceptionPlease()
{
    throw new Exception();
}

Netfx:

System.Diagnostics.Tests.StackTraceTests.InvokeMethodThatThrowsException [FAIL]
        System.Exception : Exception of type 'System.Exception' was thrown.
        Stack Trace:
          C:\Users\hugh\Documents\GitHub\corefx\src\System.Diagnostics.StackTrace\tests\StackTraceTests.cs(274,0): at S
  ystem.Diagnostics.Tests.StackTraceTests.ThrowExceptionPlease()
          C:\Users\hugh\Documents\GitHub\corefx\src\System.Diagnostics.StackTrace\tests\StackTraceTests.cs(269,0): at S
  ystem.Diagnostics.Tests.StackTraceTests.InvokeMethodThatThrowsException()

Netcoreapp:

System.Diagnostics.Tests.StackTraceTests.InvokeMethodThatThrowsException [FAIL]
        System.Exception : Exception of type 'System.Exception' was thrown.
        Stack Trace:
              at System.Diagnostics.Tests.StackTraceTests.ThrowExceptionPlease()

I can also repro this example above in Release mode, so I'm not sure if it's related, as the tests seemed to fail in Windows Release in the dotnet/corefx#21040.

Note that netcoreapp has no line numbers and no no file name so this makes things hard to action on. I thought it was just a tooling thing but what do I know

[mikem8361]

What version of the .NET Core Windows runtime were you using? Did you generate portable PDBs or Windows PDBs for your test app? If you are using Windows PDBs, make sure that microsoft.diasymreader.native.amd64.dll is in your shared framework binaries ("\Program Files\dotnet\shared\Microsoft.NETCore.App<version>"). If your app is built with Portable PDBs, there was a bug in System.Diagnostics.StackTrace that should be fixed now.

[hughbe]

I'm running from master in the test projects for master

[hughbe]

(As in, these are contributions to corefx, not my own app)
You may want to take a look at dotnet/corefx#21040

[hughbe]

Sorry to keep flogging a dead horse, but I'm not sure why the following has different behaviour in .NET Core vs .NET Framework.

• Clone corefx and run build and build -framework=netfx
• Navigate to src/System.Composition/tests and add the following test to ExportTests.cs

[Fact]
public void THROW()
{
    throw new InvalidOperationException();
}

• Run msbuild /T:BuildAndTest and observe the following

Discovering: System.Composition.Runtime.Tests
  Discovered:  System.Composition.Runtime.Tests
  Starting:    System.Composition.Runtime.Tests
     System.Compostition.Tests.ExportTests.THROW [FAIL]
        System.InvalidOperationException : Operation is not valid due to the current state of the object.
        Stack Trace:
              at System.Compostition.Tests.ExportTests.THROW()
  Finished:    System.Composition.Runtime.Tests

• Run msbuild /T:BuildAndTest /P:TargetGroup=netfx and observe the following

Discovering: System.Composition.Runtime.Tests
    Discovered:  System.Composition.Runtime.Tests
    Starting:    System.Composition.Runtime.Tests
      System.Compostition.Tests.ExportTests.THROW [FAIL]
        System.InvalidOperationException : Operation is not valid due to the current state of the object.
        Stack Trace:
          C:\Users\hugh\Documents\GitHub\corefx\src\System.Composition.Runtime\tests\ExportTests.cs(15,0): at System.Co
  mpostition.Tests.ExportTests.THROW()
    Finished:    System.Composition.Runtime.Tests

Notice that there are no line numbers or file paths for netcoreapp. If this is a bug in netcoreapp or even in the tooling for corefx, then isn't this really bad? In more advanced examples than the one I added, we can't diagnose where a test failure happened!

[mikem8361]

The source/line number info on .NET Core is missing because microsoft.diasymreader.native.amd64.dll doesn't exist in the bin directory. It is from the Microsoft.DiaSymReader.Native package which is part of the shared framework, but doesn't seem to be part of the corefx runtime binaries. It is used by the coreclr runtime to load Windows PDBs. Now if the tests used portable PDBs that would work on (.NET Core only).

[mikem8361]

And that is also reason there are source/line numbers on the Linux runs (because they can only use portable PDBs).

[danmoseley]

microsoft.diasymreader.native.amd64.dll doesn't exist in the bin directory. It is from the Microsoft.DiaSymReader.Native package which is part of the shared framework, but doesn't seem to be part of the corefx runtime binaries

@weshaggard can we fix this? (or change to portable pdb's on windows)

[danmoseley]

If I manually copy "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Roslyn\*diasym*" to
eg C:\git\corefx\bin\Windows_NT.AnyCPU.Debug\System.Console.Tests\netstandard I get line numbers in my UAP tests!

@weshaggard what is the correct way of fixing this? for now I'm pasting this line into tests.targets, which only works for uap. <TestCommandLines Include='copy /y "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Roslyn\*diasym*" .'/>

[mellinoe]

The right way to fix it is to reference the Microsoft.DiaSymReader.Native package in this project: https://github.com/dotnet/corefx/blob/master/external/test-runtime/XUnit.Runtime.depproj. The build system should do the rest of the work to deploy it to the test runtime folder, and things should work from there (at least based on my understanding of the discussion above).

[danmoseley]

Let's leave this open while we see whether it fixes the problem.

[weshaggard]

Yes what @mellinoe says is the correct way to fix this.

[danmoseley]

@weshaggard we have line numbers for netcoreapp now but this doesn't appear to work for UAP nor ILC

eg https://mc.dot.net/#/product/netcore/master/source/official~2Fcorefx~2Fmaster~2F/type/test~2Ffunctional~2Fuwp~2F/build/20170626.02/workItem/System.DirectoryServices.Tests/analysis/xunit/System.DirectoryServices.ActiveDirectory.Tests.ActiveDirectoryInterSiteTransportTests~2FFindByTransportType_ConfigurationSetTypeWithName_Throws

Can you help with that? I assume ILC is a harder problem.

[mikem8361]

Fixed with PR dotnet/coreclr#14696