FSharp.Core symbols/pdbs aren't accessible from the Microsoft Symbol Store

[baronfel]

I am unable to retrieve symbols for FSharp.Core via the MS Symbol Store (https://msdl.microsoft.com/download/symbols), which I'm led to believe is the appropriate place due to #294 (comment). I'm attempting to retrieve the symbols using dotnet symbol.

Repro steps

Provide the steps required to reproduce the problem:

1. install the dotnet symbol global tool (dotnet tool install --global dotnet-symbol --version 1.0.41502)
2. run dotnet symbol '/path/to/fsharp.core.dll'

Expected behavior

The portable PDB for FSharp.Core is downloaded.

Actual behavior

The PDB cannot be found:

root@535f0e0fb2b1:/app# dotnet symbol -d FSharp.Core.dll
Downloading from http://msdl.microsoft.com/download/symbols/
ERROR: HttpSymbolStore: 404 Not Found 'http://msdl.microsoft.com/download/symbols/fsharp.core.dll/5c64a99829a000/fsharp.core.dll'
ERROR: HttpSymbolStore: 404 Not Found 'http://msdl.microsoft.com/download/symbols/fsharp.core.pdb/f5231a9a17274c96b20f451dae0f3ad6FFFFFFFF/fsharp.core.pdb'

Known workarounds

None

Commentary

This might be related to the fact that we don't yet ship portable PDBs, though I'm not certain if the dotnet symbol tool is making that assumption.

It would be nice to have the PDBs available in the package as well, or as a snupkg, whatever the deployment mechanism of the week is, because then the current community workaround logic for packing PDBs on publish (ie deploying PDBs for diagnostics alongside the deployed application) would 'just work' as well.

Related information

Provide any related information (optional):

• Operating system: Debian 10.0 (docker image for dotnet/sdk:3.0)
• .NET Runtime kind: .Net Core 3.0 preview 9
• Editing Tools: N/A

[baronfel]

I also checked via the new Nuget Symbol Server and that one failed as well. After further reading that symbol server only supports portable PDBs so it stands to reason that FSharp.Core PDBs wouldn't be available there yet.

[baronfel]

One thing that's confusing to me (and that I'm possible misunderstanding) is that current PDBs are embedded.

I am probably just a dunce, since looking at this stacktrace from a netcoreapp3.0 app loaded into dotnet dump I see FSharp functions in the callstack:

> clrstack                                                                                                                                                                                                        
OS Thread Id: 0x1 (0)
        Child SP               IP Call Site
00007FFD977A2130 00007f8afea4e00c [HelperMethodFrame: 00007ffd977a2130] System.Threading.WaitHandle.WaitOneCore(IntPtr, Int32)
00007FFD977A2280 00007F8A8426942D System.Threading.WaitHandle.WaitOneNoCheck(Int32) [/_/src/System.Private.CoreLib/shared/System/Threading/WaitHandle.cs @ 161]
00007FFD977A22C0 00007F8A84269FAF System.Threading.WaitHandle.WaitOne(System.TimeSpan) [/_/src/System.Private.CoreLib/shared/System/Threading/WaitHandle.cs @ 405]
00007FFD977A22E0 00007F8A853CCD67 Microsoft.FSharp.Control.AsyncPrimitives+ResultCell`1[[System.__Canon, System.Private.CoreLib]].TryWaitForResultSynchronously(Microsoft.FSharp.Core.FSharpOption`1<Int32>)
00007FFD977A2330 00007F8A853CA5AA Microsoft.FSharp.Control.AsyncPrimitives.RunSynchronouslyInCurrentThread[[System.__Canon, System.Private.CoreLib]](System.Threading.CancellationToken, Microsoft.FSharp.Control.FSharpAsync`1<System.__Canon>)
00007FFD977A23C0 00007F8A853C9D9A Microsoft.FSharp.Control.AsyncPrimitives.RunSynchronously[[System.__Canon, System.Private.CoreLib]](System.Threading.CancellationToken, Microsoft.FSharp.Control.FSharpAsync`1<System.__Canon>, Microsoft.FSharp.Core.FSharpOption`1<Int32>)
00007FFD977A2400 00007F8A853C8DAB Microsoft.FSharp.Control.FSharpAsync.RunSynchronously[[System.__Canon, System.Private.CoreLib]](Microsoft.FSharp.Control.FSharpAsync`1<System.__Canon>, Microsoft.FSharp.Core.FSharpOption`1<Int32>, Microsoft.FSharp.Core.FSharpOption`1<System.Threading.CancellationToken>)
00007FFD977A24C0 00007F8A84751D6C MemoryLeak.App.main(System.String[]) [/app/Program.fs @ 40]
00007FFD977A2878 00007f8afdb6495f [GCFrame: 00007ffd977a2878] 
00007FFD977A2D60 00007f8afdb6495f [GCFrame: 00007ffd977a2d60]

Soooo...no actual problem here? Though the line-numbers are missing but that could just be sourcelink?

[cartermp]

Is this still an issue for you? Related to this? #5682

[baronfel]

This can be closed, embedded PDBs solve this nicely.