Skip to content
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

Closed
rodolfoBee opened this issue Oct 17, 2024 · 1 comment
Closed

Debug Information File uploaded but not applied to event. #1539

rodolfoBee opened this issue Oct 17, 2024 · 1 comment
Assignees

Comments

@rodolfoBee
Copy link
Member

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.

Image

Due to possible PII involved, more information on the issue is available in this internal ticket

@getsantry getsantry bot moved this to Waiting for: Product Owner in GitHub Issues with 👀 3 Oct 17, 2024
@loewenheim loewenheim self-assigned this Oct 17, 2024
@loewenheim
Copy link
Contributor

loewenheim commented Oct 17, 2024

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:

  1. Symbolicator receives an event with an image of type pe_dotnet and debug id <DEBUG_ID> inside. That makes sense because it's a .NET event.
  2. Symbolicator asks Sentry for a portable pdb file with debug id <DEBUG_ID>. It specifically requests a portable pdb because that is the only debug file format we support for .NET events.
  3. Sentry replies that it doesn't have a portable pdb file with debug id <DEBUG_ID>, which is true—the uploaded file is a Windows PDB file!
  4. Symbolicator returns the event and reports that the portable pdb file couldn't be found.
  5. Sentry receives Symbolicator's reply and sees that it couldn't find the file with debug id <DEBUG_ID>. But it has a file with that debug id! So it thinks that the file must have been uploaded after symbolication, even though that's clearly not true.

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 DebugType portable, as explained here. That will use the portable pdb format, which we support for .NET.

@bruno-garcia bruno-garcia added this to GDX Oct 19, 2024
@github-project-automation github-project-automation bot moved this to Done in GDX Oct 21, 2024
loewenheim added a commit to getsentry/sentry that referenced this issue Nov 11, 2024
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.
loewenheim added a commit to getsentry/sentry that referenced this issue Nov 11, 2024
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.
loewenheim added a commit that referenced this issue Nov 11, 2024
#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.
loewenheim added a commit to getsentry/sentry that referenced this issue Nov 12, 2024
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.
loewenheim added a commit to getsentry/sentry that referenced this issue Nov 12, 2024
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.
loewenheim added a commit that referenced this issue Nov 20, 2024
#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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Archived in project
Development

No branches or pull requests

3 participants