-
-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Debug Information File uploaded but not applied to event. #1539
Comments
I can reproduce this locally, and I'm pretty sure I know what's happening. They are trying to symbolicate a .NET event with a native Windows .pdb file (the file they uploaded). Unfortunately we currently don't support this case, although we would like to—see getsentry/symbolic#871. Here are the steps that happen to cause this behavior:
Of course, reprocessing cannot fix this. It's unfortunate that our error message is so confusing in this case; we'll have to think about improving that even independent of actually supporting the feature. The only suggestion I can make in the meantime is to compile with |
This is intended to improve the user experience for cases like getsentry/symbolicator#1539 in which we attempt to symbolicate a CLR event with a Windows PDB file. It maps the "unsupported" frame status returned by Symbolicator (getsentry/symbolicator#1541) to a new error variant. Properly displaying and explaining this error is left for a future PR.
This is intended to improve the user experience for cases like getsentry/symbolicator#1539 in which we attempt to symbolicate a CLR event with a Windows PDB file. It maps the "unsupported" frame status returned by Symbolicator (getsentry/symbolicator#1541) to a new error variant. Properly displaying and explaining this error is left for a future PR.
#1541) This adds a new `CacheError`/`ObjectFileStatus` variant for cases where a debug file is OK, but can't be used for the purpose for which it was requested. Currently the only such case is symbolicating .NET events with portable PDB files (see getsentry/symbolic#871). In addition, this also makes Symbolicator request both portable PDB and Windows PDB files for symbolicating .NET events. The reason for this is that although Windows PDB files can never be used for that purpose, at least this way we get a concrete error status we can report to the user. If we don't do that, we get cases like #1539.
This is intended to improve the user experience for cases like getsentry/symbolicator#1539 in which we attempt to symbolicate a CLR event with a Windows PDB file. It maps the "unsupported" frame status returned by Symbolicator (getsentry/symbolicator#1541) to a new error variant. Properly displaying and explaining this error is left for a future PR.
Take 2 of #80517. This is intended to improve the user experience for cases like getsentry/symbolicator#1539 in which we attempt to symbolicate a CLR event with a Windows PDB file. It maps the "unsupported" frame status returned by Symbolicator (getsentry/symbolicator#1541) to a new error variant. Properly displaying and explaining this error is left for a future PR.
#1554) This adds a new `CacheError`/`ObjectFileStatus` variant for cases where a debug file is OK, but can't be used for the purpose for which it was requested. Currently the only such case is symbolicating .NET events with portable PDB files (see getsentry/symbolic#871). In addition, this also makes Symbolicator request both portable PDB and Windows PDB files for symbolicating .NET events. The reason for this is that although Windows PDB files can never be used for that purpose, at least this way we get a concrete error status we can report to the user. If we don't do that, we get cases like #1539.
Sentry is failing to apply a debug file to event. The file was uploaded 3 days before the event was accepted and is valid according to the Sentry CLI. Reprocessing the event has no effect.
There are no errors raised while processing the file.
Due to possible PII involved, more information on the issue is available in this internal ticket
The text was updated successfully, but these errors were encountered: