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

feat(minidump): Get CFI info from eh_frame even if err in debug_frame #218

Merged
merged 1 commit into from
Apr 15, 2020

Conversation

calixteman
Copy link
Contributor

In case of error in .debug_frame section the CFI info in .eh_frame weren't retrieved.

@calixteman calixteman requested a review from a team April 9, 2020 15:22
Copy link
Member

@jan-auer jan-auer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! Patch looks good, thanks for ensuring that the error is eventually returned.

However, are you sure that the caller can swallow the error and still use the partially written CFI? Generally, the writer can fail at places that may leave invalid or partial records behind, which may lead to errors when feeding them into Breakpad.

I was briefly thinking about mentioning this in the description of the process method. Since it's quite uncertain that the CFI is still valid, however, I am now leaning towards not doing that. What do you think?

@jan-auer jan-auer changed the title [minidump] Get CFI info from eh_frame even if err in debug_frame feat(minidump): Get CFI info from eh_frame even if err in debug_frame Apr 9, 2020
@calixteman
Copy link
Contributor Author

Thank you! Patch looks good, thanks for ensuring that the error is eventually returned.

However, are you sure that the caller can swallow the error and still use the partially written CFI? Generally, the writer can fail at places that may leave invalid or partial records behind, which may lead to errors when feeding them into Breakpad.

I'd say that's ok.
Most of the CFI for firefox at least are in the eh_frame section (the same gcc & clang).
So in this case skipping CFI from debug_frame section is not bad.
The idea here is just to let the user decides what he wants to do: skip everything in case of error or keep what he has.
FYI, I fixed a bug in gimli which was causing trouble because of a "bad" debug_frame section:
gimli-rs/gimli@53c802a

I was briefly thinking about mentioning this in the description of the process method. Since it's quite uncertain that the CFI is still valid, however, I am now leaning towards not doing that. What do you think?

From my pov, CFI here is valid but incomplete so not so bad.

@jan-auer
Copy link
Member

FYI, I fixed a bug in gimli which was causing trouble

Thanks, I'll bump gimli as soon as it is released.

CFI here is valid but incomplete so not so bad

Okay, I'm merging this now. From the interface, I still think that if we error at the wrong point, we might have emitted only a partial record (i.e. stopped in the middle of printing a register name). In that case, you'd be left with invalid CFI.

As you said, based on the error, the user can then decide if they still want to use the written CFI or not. 👍

@jan-auer jan-auer merged commit b0b94d4 into getsentry:master Apr 15, 2020
jan-auer added a commit that referenced this pull request Apr 16, 2020
* master:
  fix(minidump): Skip TooManyRegisterRules errors in CFI (#219)
  feat(examples): Add a --trace flag to the run script
  fix(minidump): Get CFI info from eh_frame even if err in debug_frame (#218)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants