You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
sentry-cli uploading PDBs fails when symbols embedded #2073
An error happens on the Sentry.dll because of missing pdb. Even though it's possible some DLLs won't have PDBs, it doesn't mean debug info isn't available.
In the case of Sentry.dll, the debug information is embedded in the DLL itself:
While I'm on board with supporting this in CLI, maybe we should additionally consider switching to portable PDB at some point. Here's what it does to the android sample app:
WIth embedded debug info in build.props
With portable PDB in build.props
So single-target builds are about 75 KiB smaller (APK has all the architectures that's why the diff is larger)
It's not just Sentry.dll, but customers will see this too when symbols are embedded. Though they might still get stack trace info in such cases - unless it's later trimmed out.
It would be good to get this fixed in sentry-cli itself.
But yes, also I think we can stop embedding symbols in our own dlls. Instead, we should make sure we publish symbols packages (.snupkg) with our nugets so customers will still get sources with Source Link.
Embedded symbols should be supported with the next release of CLI (assuming it gets the latest symbolic included). I'm keeping track of that so I'll assign this issue to myself too.
Is there any benefit though? If the symbols are embedded, won't we always get line numbers in the actual stack trace - thus making symbolication a no-op?
Note to self - If that's not the case, then when we bump the CLI we should also remove And '$(DebugType)' != 'embedded' from this line:
Latest Sentry CLI (2.12.0) doesn't address this. We do get embedded sources when they are part of the pdb file, but we do not get embedded sources or symbols when they are embedded in the dll. See getsentry/symbolic#750
Is there any benefit though? If the symbols are embedded...
Just to answer myself here, the benefit is largely to have embedded sources, but also I have seen at least one case where even though the symbols were originally embedded, .NET did not include filenames/line-numbers in the stack trace. This was on an Android app, so I suspect the embedded symbols in the library were stripped out when the app was built.
Note, with #2166 this issue no longer affects the Sentry .NET SDKs. However, it could still affect a user if they are embedding symbols in their own project, so we should keep this issue open until we have an updated Symbolic + Sentry CLI that handles it.
Activity
vaind commentedon Dec 5, 2022
Sample event: https://sentry.io/organizations/sentry-sdks/issues/3744250864/events/9cbaab1c74be425db3e636d26da9bc0a/?project=5428537

vaind commentedon Dec 6, 2022
While I'm on board with supporting this in CLI, maybe we should additionally consider switching to portable PDB at some point. Here's what it does to the android sample app:
WIth embedded debug info in build.props
With portable PDB in build.props
So single-target builds are about 75 KiB smaller (APK has all the architectures that's why the diff is larger)
[-]sentry-cli uploading PDBs fail on `Sentry`[/-][+]sentry-cli uploading PDBs fails when symbols embedded[/+]mattjohnsonpint commentedon Jan 6, 2023
It's not just Sentry.dll, but customers will see this too when symbols are embedded. Though they might still get stack trace info in such cases - unless it's later trimmed out.
It would be good to get this fixed in sentry-cli itself.
mattjohnsonpint commentedon Jan 6, 2023
But yes, also I think we can stop embedding symbols in our own dlls. Instead, we should make sure we publish symbols packages (.snupkg) with our nugets so customers will still get sources with Source Link.
vaind commentedon Jan 9, 2023
Embedded symbols should be supported with the next release of CLI (assuming it gets the latest symbolic included). I'm keeping track of that so I'll assign this issue to myself too.
mattjohnsonpint commentedon Jan 10, 2023
Is there any benefit though? If the symbols are embedded, won't we always get line numbers in the actual stack trace - thus making symbolication a no-op?
Note to self - If that's not the case, then when we bump the CLI we should also remove
And '$(DebugType)' != 'embedded'from this line:sentry-dotnet/src/Sentry/buildTransitive/Sentry.props
Line 38 in 6b17e2c
mattjohnsonpint commentedon Jan 10, 2023
Also, is there an issue tracking this in sentry-cli? I couldn't find one. Thanks.
mattjohnsonpint commentedon Jan 10, 2023
Nevermind, found it in Symbolic getsentry/symbolic#734. Thanks
mattjohnsonpint commentedon Jan 30, 2023
Latest Sentry CLI (2.12.0) doesn't address this. We do get embedded sources when they are part of the pdb file, but we do not get embedded sources or symbols when they are embedded in the dll. See getsentry/symbolic#750
mattjohnsonpint commentedon Jan 30, 2023
Just to answer myself here, the benefit is largely to have embedded sources, but also I have seen at least one case where even though the symbols were originally embedded, .NET did not include filenames/line-numbers in the stack trace. This was on an Android app, so I suspect the embedded symbols in the library were stripped out when the app was built.
mattjohnsonpint commentedon Feb 8, 2023
Note, with #2166 this issue no longer affects the Sentry .NET SDKs. However, it could still affect a user if they are embedding symbols in their own project, so we should keep this issue open until we have an updated Symbolic + Sentry CLI that handles it.
vaind commentedon Feb 8, 2023
closed via getsentry/sentry-cli#1463 and will be available in the next CLI release