Implements API for retrieval of symbols and other debug artifacts from symbol store.
License: MIT License
Has been moved to diagnostics repo. The specs have been moved to documentation/symbols and the code to src/Microsoft.SymbolStore and src/Microsoft.FileFormats
The latest builds are still available on the dotnet-tools feed:
https://dev.azure.com/dnceng/public/_artifacts/feed/dotnet-tools/NuGet/Microsoft.SymbolStore https://dev.azure.com/dnceng/public/_artifacts/feed/dotnet-tools/NuGet/Microsoft.FileFormats https://dev.azure.com/dnceng/public/_artifacts/feed/dotnet-tools/NuGet/dotnet-symbol
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
![dotnet-maestro[bot] avatar](https://avatars.githubusercontent.com/in/16706?v=4 "dotnet-maestro[bot]")
@tmat commented on Thu Jun 07 2018
Extract embedded PDBs, convert them to Windows PDBs and publish Windows PDBs to symbol server.
The Portable PDBs do not need to be published.
This is only needed so that Windows PDBs are available to tools that do not support Embedded PDBs yet.
Since case insensitive file systems are not exactly the rage there are quite a few symbol servers out there which require exactly the Microsoft emitted case rules which are different from the ones in the SSQP document.
In particular the rules that those servers are following are:
Foo.pdb instead of foo.pdb) in the example.SSQP currently defines:
This will allow the downloader (dotnet-symbol) to get the cross-OS DAC along with the other "special" clr binaries. This is also the first step in getting the uploader to work with it too.
Coredumps created with gdb have garbage for the ELF module headers. It seems fairly random because some native modules and some don't. lldb and gdb don't have a problem loading these dumps without any problems.
Detecting this and display a warning or error message that this dump was created with gdb would be good.
This can be fixed in the file format for ELF core dumps by creating a special derived ELF file class that uses the core dumps header info by returning the proper bitness, endianess and module type.
This makes distinguishing ELF modules from the PE modules in the core dump more difficult. The signature check for PE's would have to be first.
Would be great to have a simple Getting Started - what is this repo for, what scenarios are enabled, sample code on how to consume the bits.
For instance I'd like to have an API that allows me to download the .pdb file given the input .dll file and the path to the symbol server. I know symchk does it, but I want control over where the .pdb is placed on disk. I'm not clean if this repo/library can solve my problem and if yes, how do I use it. What's the .dll name or Nuget package that I should reference to use the library? What's the simplest Program.cs code snippet that does something?
Thanks!
This will allow an improved xplat/lldb core dump work flow. All the managed PDBs are not downloaded (10 to 15 minutes for a simple webapp). SOS does a good job at download the PDBs it needs on demand.
The --host-only works if the user doesn't care about native symbols and modules, but not for 5.x (master) runtime core dumps. lldb works a lot better with all the native runtime modules (mainly libcoreclr.so) present next to the core dump when lldb loads the dump.
Also publish packages to build artifacts instead of relying on dropping them to share.
Need to add the rollForwardOnNoCandidateFx config to support when there is only 2.2.x or 3.0.x .NET Core installed.
Given just the GUID for a module, dotnet-symbol can retrieve the binary and symbol files from the server.
The use-case is when I only have a crash dump and need to get the associated files for working in the debugger.
Microsoft debuggers, on Windows, have integrated symbol fetch that can get the pdb hash directly from the dump, but this is not available with other debuggers like Xcode.
The ELF key generator needs to search the program headers for a Interp type if the host-only flag is set.
There is very subtle bug in the Windows PDB key generator that caused the pdb checksum list never to be passed to the SymbolStoreKey constructor (one of the closing parentheses is in the wrong place causing pdbChecksums to be passed to the string.Format instead of BuildKey).
PDBFileKeyGenerator.cs line 52:
- return BuildKey(path, string.Format("{0}{1:x}", signature.ToString("N"), age, pdbChecksums));
+ return BuildKey(path, string.Format("{0}{1:x}", signature.ToString("N"), age), clrSpecialFile: false, pdbChecksums);
Once this was fixed, symbol downloads for Windows PDBs (i.e. Microsoft.Extensions.Hosting.Abstractions.ni.pdb) started failing because ChecksumValidator.cs seems to only handle portable PDBs:
private static uint GetPdbStreamOffset(Stream pdbStream)
{
pdbStream.Position = 0;
using (var reader = new BinaryReader(pdbStream, Encoding.UTF8, leaveOpen: true))
{
pdbStream.Seek(4 + // Signature
2 + // Version Major
2 + // Version Minor
4, // Reserved)
SeekOrigin.Begin);
// skip the version string
uint versionStringSize = reader.ReadUInt32(); <<------- exception
pdbStream.Seek(versionStringSize, SeekOrigin.Current);
In preparation for chasing a potential memory leak in an .NET Core MVC app (linux/docker), I'm trying to setup a linux environment for analyzing memory dumps.
Two machines - Ubuntu 16.04 & Ubuntu 18.04.
Both have .NET Core SDKs:
2.1.700
2.2.300
Tried to follow the instructions and getting stuck on the second step (dotnet-symbol gets installed without a problem).
dotnet symbol coredump throws No executable found matching command "dotnet-symbol". If I add /home/<user>/.dotnet/tools to the $PATH, the error changes to
Downloading from http://msdl.microsoft.com/download/symbols/
ERROR: Input files not foundDoesn't seem to matter if I have a global.json local file, specifying .NET Core SDK 2.1
What am I missing?
Should be a.pdb/7ace356ee85544148c5aa8a96f2b8035ffffffff/a.pdb instead of a.pdb/7ace356ee85544148c5aa8a96f2b8035FFFFFFFF/a.pdb because https://github.com/dotnet/symstore/blob/master/docs/specs/SSQP_Key_Conventions.md.
It always displays the below error message:
dotnet-symbol -d -o c:\temp\symout c:\temp\cdb.webapp.dmp
Downloading from http://msdl.microsoft.com/download/symbols/
Writing files to c:\temp\symout
ERROR: Unable to read bytes at offset 0x0
Steps in the sample NuGet symbol server readme don't work anymore. The project is a tool project now, and doesn't run with dotnet run, and simply changing the project type raises complaints about files not being copied to the artifacts dir.
I was trying to use it to stand up a quick symbol server to see if some non-online symbols would be matched up and used correctly against a snapshot, but wasn't able to make it work.
It also didn't seem to load some recent runtime.win-x64.Microsoft.NETCore.App.<version>.symbols.nupkg files that I stuck in a nuget_feed dir in artifacts, but that is probably another issue not worth looking at until some overall flow works.
lldb needs the host program when loading a core dump, otherwise no modules show up in the target modules list command. For .NET Core it is usually dotnet, but it necessarily won't be the correct version installed on the machine loading the core dump. Self-contained apps make this even a harder problem, but the "host" program is apphost renamed to the project/program name.
To improve the work flow for analyzing core dumps, add a option that just downloads the host and attempts to download the correct version of apphost and renames it to the program name.
Is there any way to use this from a corporate proxy in Linux?
~/.dotnet/tools/dotnet-symbol --symbols --output symbols /opt/rh/rh-dotnet21/root/usr/lib64/dotnet/shared/Microsoft.NETCore.App/2.1.2/libcoreclr.so
Downloading from http://msdl.microsoft.com/download/symbols/
Writing files to symbols
ERROR: HttpSymbolStore: 404 Not Found 'http://msdl.microsoft.com/download/symbols/_.debug/elf-buildid-sym-4eead6109bc9146f462bbcf1311de3c833b5cf64/_.debug'https://github.com/dotnet/symstore/blob/master/nuget.exe
Is this file needed? I thought that this need went away a long time ago, and it certainly doesn't work off of Windows.
This file is currently unattributed, so is violating our licensing policy. We could attribute it, but I'd prefer to just delete it.
/cc @tmat
SymbolChecksum needs implementing.
Working on PR.
Tried to enable symbol publisher in dotnet/sourcelink repo again, now hitting the following error:
E:\A\_work\866\s\.packages\microsoft.dotnet.arcade.sdk\1.0.0-beta.18616.5\tools\Publish.proj(131,5): error : Invalid ELF BuildID '<null>' for tools/netcoreapp2.0/runtimes/alpine-x64/native/libgit2-a904fc6.so
2018-12-18T18:19:49.9924832Z E:\A\_work\866\s\.packages\microsoft.dotnet.arcade.sdk\1.0.0-beta.18616.5\tools\Publish.proj(131,5): error : Invalid ELF BuildID '<null>' for tools/netcoreapp2.0/runtimes/alpine-x64/native/libgit2-a904fc6.so
Repro by getting https://www.nuget.org/packages/LibGit2Sharp.NativeBinaries/1.0.258 package and publishing all files it contains.
Hello,
When I run dotnet symbol to download debug symbols for .NET Core SDK 2.1.10 it throw the following error:
...
Writing: /usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.10/System.Diagnostics.FileVersionInfo.pdb
Cached: /root/.dotnet/symbolcache/system.componentmodel.annotations.pdb/5b25c24677e342c39b52d7d0bb347779FFFFFFFF/system.componentmodel.annotations.pdb
Writing: /usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.10/System.ComponentModel.Annotations.pdb
Cached: /root/.dotnet/symbolcache/system.private.corelib.pdb/d86a24c58e91402d8f6d21028185ef75FFFFFFFF/system.private.corelib.pdb
Writing: /usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.10/System.Private.CoreLib.pdb
ERROR: The operation was canceled. -> Unable to read data from the transport connection: Operation canceled.
Looks like dotnet symbol is trying to download large file and can't do it because exceed read timeout. Could you please check it?
Steps to reproduce:
Create Dockerfile:
FROM mcr.microsoft.com/dotnet/core/sdk:2.1.603@sha256:8eda326c4c0bd038f3cc5aeb5c8af8374b88f1b90eb444ed91bab42f2e17840f
RUN dotnet tool install -g dotnet-symbol
ENV PATH=$PATH:/root/.dotnet/tools
RUN dotnet symbol --diagnostics --symbols --output /usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.10 '/usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.10/*'
Run docker build to build this docker file:
docker build . -f Dockerfile
It should show error described above.
Thank you.
Hi all,
what do you thing about handling a common Linux debug symbols extension .debug in additional to Microsoft specific .dbg? See
https://github.com/dotnet/corefx/blob/master/src/System.Reflection.Metadata/specs/PE-COFF.md
Version Major=any, Minor=0x504d of the data format has the same structure as above. The Age shall be 1. The format of the .pdb file that this PE/COFF file was built with is Portable PDB. The Major version specified in the entry indicates the version of the Portable PDB format. Together 16B of the Guid concatenated with 4B of the TimeDateStamp field of the entry form a PDB ID that should be used to match the PE/COFF image with the associated PDB (instead of Guid and Age). Matching PDB ID is stored in the #Pdb stream of the .pdb file.
The Age shall be 1
You add the ffffffff as the age for protable pdb. Why ???
After installing Linux x64 3.0.100 release, I tried to download the symbols for the runtime.
$ dotnet --list-runtimes
Microsoft.AspNetCore.All 2.1.13 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.7 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.13 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.7 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.0.0 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.13 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.7 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.0.0 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
$ dotnet-symbol --recurse-subdirectories /usr/share/dotnet/shared/Microsoft.NETCore.App/3.0.0/libcoreclr.so -o 3.0.0-symbols
Downloading from http://msdl.microsoft.com/download/symbols/
Writing files to 3.0.0-symbols
Writing: 3.0.0-symbols/libcoreclr.so
Writing: 3.0.0-symbols/libcoreclr.so.dbg
Writing: 3.0.0-symbols/libmscordaccore.so
Writing: 3.0.0-symbols/libmscordbi.so
ERROR: HttpSymbolStore: 404 Not Found 'http://msdl.microsoft.com/download/symbols/libsos.so/elf-buildid-coreclr-b4c030672d8bb8cffdae6ebfac0717763f6677f8/libsos.so'
ERROR: HttpSymbolStore: 404 Not Found 'http://msdl.microsoft.com/download/symbols/sos.netcore.dll/elf-buildid-coreclr-b4c030672d8bb8cffdae6ebfac0717763f6677f8/sos.netcore.dll'
$ md5sum 3.0.0-symbols/libcoreclr.so* /usr/share/dotnet/shared/Microsoft.NETCore.App/3.0.0/libcoreclr.so
b47b275c67a0669c16bdc4f877ef999a 3.0.0-symbols/libcoreclr.so
f3476f8f604902fc320ee7e43ea55529 3.0.0-symbols/libcoreclr.so.dbg
b31e674bd71a6a552c7effd2d7ba3838 /usr/share/dotnet/shared/Microsoft.NETCore.App/3.0.0/libcoreclr.soAs shown the versions do not match.
The downloaded 3.0.0-symbols/libcoreclr.so is missing debug info, but does have a symtab
This is required before we can switch to NuGet.config.
Seems like it's currently published to https://dotnet.myget.org/F/dotnet-buildtools/api/v3/index.json
@mikem8361 commented on Thu Apr 18 2019
@tmat commented on Thu Jun 07 2018
Extract embedded PDBs, convert them to Windows PDBs and publish Windows PDBs to symbol server.
The Portable PDBs do not need to be published.
This is only needed so that Windows PDBs are available to tools that do not support Embedded PDBs yet.
Hello,
We've created a coredump using the createdump utility. Upon trying to use dotnet-dump analyze we see the following:
> clrstack -all
...
00007F85D2FFA4D0 00007F85FE7F08B0 /app/NLog.dll!Unknown
00007F85D2FFA500 00007F85FCF5B2AF /app/NLog.dll!Unknown
00007F85D2FFA570 00007F85FCF55E96 /app/NLog.dll!Unknown
00007F85D2FFA5B0 00007F85FCF55DC2 /app/NLog.dll!Unknown
00007F85D2FFA5F0 00007F85FCF559C5 /app/NLog.dll!Unknown
...
Following this documentation, when attempting to generate symbols from the dump we see the following
> dotnet-symbol ./3f13aaf3-3485-01c7-1ee6-82a583e97eb2.coredump
Downloading from http://msdl.microsoft.com/download/symbols/
ERROR: Unreasonably large ELFHeader ProgramHeaderCount
How should we proceed with debugging this?
dotnet info:
.NET Core SDK (reflecting any global.json):
Version: 3.0.100
Commit: 04339c3a26
Runtime Environment:
OS Name: ubuntu
OS Version: 18.04
OS Platform: Linux
RID: ubuntu.18.04-x64
Base Path: /usr/share/dotnet/sdk/3.0.100/
Host (useful for support):
Version: 3.0.0
Commit: 95a0a61858
.NET Core SDKs installed:
2.2.402 [/usr/share/dotnet/sdk]
3.0.100 [/usr/share/dotnet/sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.2.7 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.2.7 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.0.0 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.2.7 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.0.0 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
In the spec for ELF Key Conventions the build-id is specified as 20-bytes.
This applies to any ELF format files that have not been stripped of debugging information, commonly ending in ‘.so.dbg’ or ‘.dbg’. The key is computed by reading the 20 byte sequence of the ELF Note section that is named “GNU” and that has note type PRPSINFO (3). The file name is not used in the index because there are cases where all we have is the build id. The final key is formatted
However, the build-id is only 20 bytes if using --build-id=sha1. If using --build-id=md5 or --build-id=uuid then it's only 16 bytes. More info here.
The key convention should specify what to do in such a scenario
The File.ReadAllBytes used in the symbol uploader has a 2GB limit on the size of file and throws an exception.
One possible fix is to break the read into multiple "block" size chunks.
It should verify that the symbol file has the correct index.
@mikem8361 commented on Tue May 15 2018
Since we upload to both msdl and symweb now, it would be more efficient to modify the symbol uploader build task to accept multiple symbol server URLs and PATs. The PAT would have to become a metadata on the SymbolServer TaskItem. This would allow the files to be opened, read and any Portable PDB to Windows conversion to happen only once.
The Microsoft.Symbol.Uploader internal PublishFileInfo lifetime logic would have to change not to Dispose after the file is uploaded.
@mikem8361 commented on Thu Apr 18 2019
@mikem8361 commented on Thu Apr 18 2019
Also publish to dotnet-core blob feed instead of the myget buildtools feed
@JohnTortugo commented on Mon May 13 2019
@mikem8361 - Doesn't make sense to move this project to Arcade? @markwilkie
@mikem8361 commented on Mon May 13 2019
If the arcade repo is a better place for it, that's fine with me. I just wanted an appropriate github repo to file the issue because DotNet-SymUploader is a internal AzDO repo.
@JohnTortugo commented on Tue Jun 04 2019
@mikem8361 is there any special reason for publishing the symbol uploader to https://dotnet.myget.org/F/dotnet-buildtools/api/v3/index.json or could we lets say, as part of moving the project to Arcade, publish it to dotnet-core?
@mikem8361 commented on Tue Jun 04 2019
We haven’t had enough time to convert dotnet-symuploader repo to the latest arcade that allows it to be published to our blob store feed. We have so much engineering work in the repo’s the diagnostics team owns.
But it is part of the plan to publish to the blob feed.
mikem
└─ dotnet symbol --symbols --output temp /opt/dotnet/shared/Microsoft.NETCore.App/2.2.6/lib*.so
Downloading from http://msdl.microsoft.com/download/symbols/
Writing files to temp
ERROR: HttpSymbolStore: 404 Not Found 'http://msdl.microsoft.com/download/symbols/_.debug/elf-buildid-sym-4fdad002ae9b8fcecc5c8b20667401861aaa7275/_.debug'
ERROR: HttpSymbolStore: 404 Not Found 'http://msdl.microsoft.com/download/symbols/_.debug/elf-buildid-sym-4baa6f597f3b39b06285fb14ff19c98ddb4dbd42/_.debug'
ERROR: HttpSymbolStore: 404 Not Found 'http://msdl.microsoft.com/download/symbols/_.debug/elf-buildid-sym-ff778e81219d68c28823bf63ad9f7a958c66de05/_.debug'
ERROR: HttpSymbolStore: 404 Not Found 'http://msdl.microsoft.com/download/symbols/_.debug/elf-buildid-sym-ad0250338153a9301b3a5dcf065e7e6f3a17d249/_.debug'
ERROR: HttpSymbolStore: 404 Not Found 'http://msdl.microsoft.com/download/symbols/_.debug/elf-buildid-sym-710de1e06b2755686bc85ec533aeb395bb8b60df/_.debug'
ERROR: HttpSymbolStore: 404 Not Found 'http://msdl.microsoft.com/download/symbols/_.debug/elf-buildid-sym-7f5a2f1de5bdeb9401b1d42e135bfb49f72f718d/_.debug'
ERROR: HttpSymbolStore: 404 Not Found 'http://msdl.microsoft.com/download/symbols/_.debug/elf-buildid-sym-5002f8f693920439599edb77f4485f5bbdd108d2/_.debug'
ERROR: HttpSymbolStore: 404 Not Found 'http://msdl.microsoft.com/download/symbols/_.debug/elf-buildid-sym-5a76ee87804b070d31270e5567800c57d45358b0/_.debug'
ERROR: HttpSymbolStore: 404 Not Found 'http://msdl.microsoft.com/download/symbols/_.debug/elf-buildid-sym-9d5194ba8e6824ad97032450a0c208b52fa7fcd5/_.debug'
└─ l /opt/dotnet/shared/Microsoft.NETCore.App/2.2.6/lib*.so
.rwxr-xr-x 2.9M root 18 Jul 10:49 /opt/dotnet/shared/Microsoft.NETCore.App/2.2.6/libclrjit.so
.rwxr-xr-x 8.5M root 18 Jul 10:49 /opt/dotnet/shared/Microsoft.NETCore.App/2.2.6/libcoreclr.so
.rwxr-xr-x 669k root 18 Jul 10:49 /opt/dotnet/shared/Microsoft.NETCore.App/2.2.6/libcoreclrtraceptprovider.so
.rwxr-xr-x 913k root 18 Jul 10:49 /opt/dotnet/shared/Microsoft.NETCore.App/2.2.6/libdbgshim.so
.rwxr-xr-x 293k root 18 Jul 10:49 /opt/dotnet/shared/Microsoft.NETCore.App/2.2.6/libhostpolicy.so
.rwxr-xr-x 3.3M root 18 Jul 10:49 /opt/dotnet/shared/Microsoft.NETCore.App/2.2.6/libmscordaccore.so
.rwxr-xr-x 2.2M root 18 Jul 10:49 /opt/dotnet/shared/Microsoft.NETCore.App/2.2.6/libmscordbi.so
.rwxr-xr-x 623k root 18 Jul 10:49 /opt/dotnet/shared/Microsoft.NETCore.App/2.2.6/libsos.so
.rwxr-xr-x 71k root 18 Jul 10:49 /opt/dotnet/shared/Microsoft.NETCore.App/2.2.6/libsosplugin.so
Arch Linux, dotnet-runtime 2.2.6+108-1
Please see context here: dotnet/arcade#4304 (comment)
From @mikem8361 :
The NullReferenceException definitely needs to be fixed but I'm sure it is either network time out or error path. I can make some simple fixes to log all inner exceptions in the aggregated one to diagnose this in the future.
Example builds:
https://dnceng.visualstudio.com/internal/_build/results?buildId=419023
https://dnceng.visualstudio.com/internal/_build/results?buildId=417308
I’m getting some warnings from the build task:
warning : Invalid file type: tools/bincore/RunCsc
warning : Invalid file type: tools/bincore/RunVbc
these are bash scripts (with no extensions).
Packages may contain all sorts of files, the tool should silently skip files whose extension it doesn't recognize.
reports
It was not possible to find any compatible framework version
The specified framework 'Microsoft.NETCore.App', version '2.1.0' was not found.
- Check application dependencies and target a framework version installed at:
/usr/share/dotnet
- Installing .NET Core prerequisites might help resolve this problem:
https://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409
- The .NET Core framework and SDK can be installed from:
https://aka.ms/dotnet-download
- The following versions are installed:
3.0.0-preview-27122-01 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]
dotnet info
.NET Core SDK (reflecting any global.json):
Version: 3.0.100-preview-009812
Commit: e3abf6e935
Runtime Environment:
OS Name: debian
OS Version: 9
OS Platform: Linux
RID: debian.9-x64
Base Path: /usr/share/dotnet/sdk/3.0.100-preview-009812/
Host (useful for support):
Version: 3.0.0-preview-27122-01
Commit: 00c5c8bc40
.NET Core SDKs installed:
3.0.100-preview-009812 [/usr/share/dotnet/sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.App 3.0.0-preview-18579-0056 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.0.0-preview-27122-01 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download
Short term fix to detect PDBs >2GB and skip them (show a warning that the file is skipped).
It would be great to support MSCF compression on symbol storage as was made in symstore.exe. This ticket is connected with #52
I would be great to add the symbol storage generator.
In README.md build status info is referring to unreachable url(timeout error).
Windows
x64 Debug https://ci.dot.net/job/dotnet_symstore/job/master/job/Windows_NT_Debug/
x64 Release https://ci.dot.net/job/dotnet_symstore/job/master/job/Windows_NT_Release/
Ubuntu 16.04
Debug https://ci.dot.net/job/dotnet_symstore/job/master/job/Ubuntu16.04_Debug/
Release https://ci.dot.net/job/dotnet_symstore/job/master/job/Ubuntu16.04_Release/
Icon is not rendered and build status is not available.
@tmat commented on Fri Jun 08 2018
When running the task on unofficial builds (DryRun=true) the PAT is not available.
@mikem8361 commented on Thu Jul 26 2018
I thought about this a little and one could argument that a DryRun should fail if there is no PAT. It is part of the validation.
If there is a good reason that you just want the checking from the Portable to Windows PDB conversion, then we can make the change.
I've seen a few times the Symbol Uploader dump a large stack trace when it fails to communicate with the symbol server for some reason - i.e., when AzDO feed is flaky or some network problem happen. It would be good to capture this common problem and present a more meaningful error message.
See sample problem here: https://dnceng.visualstudio.com/internal/_build/results?buildId=378145&view=results or https://github.com/aspnet/AspNetCore-Internal/issues/3202
The dotnet-symbol readme mentions the following:
The best way to generate core dumps on Linux (not supported on Windows or OSX) is to use the createdump facility that is part of .NET Core 2.0 and greater. It can be setup to automatically generate a "minidump" like ELF core dump when your .NET Core app crashes. The normal Linux system core generation also works just fine but they are usually a lot larger than necessary.
My questions:
Also, I'm trying to understand how to use portable pdbs on Linux, or at all for that matter, and my search led to this dotnet-symbol tool. Do I need to use dotnet-symbol at all? Assuming I have portable PDBs and a core dump from a .NET Core 3.1 app, what tools can actually use portable PDBs besides VS?
I would be great to support two-tier storage.
/Users/jasonimison/src/symstore/.packages/microsoft.build.tasks.git/1.0.0-beta-63102-01/build/Microsoft.Build.Tasks.Git.targets(20,5): error MSB4018: System.TypeInitializationException: The type initializer for 'LibGit2Sharp.Core.NativeMethods' threw an exception. ---> System.PlatformNotSupportedException: osx.10.14-x64 [/Users/jasonimison/src/symstore/src/NugetSymbolServer/NugetSymbolServer.csproj]
PR incoming
Add symbol publishing to official build or add embedded PDBs to the binaries.
It may be only the newer DirectorySymbolStore, but the other ones need to be checked.
The DirectorySymbolStore can't find the DAC or DBI in a directory for the special coreclr based index.
Add info trace when the DirectorySymbolStore finds a file.
Add "SymbolStore.Equals" overrides to all the symbol stores.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.