-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Incorrect stack trace for stripped binaries #1092
Conversation
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1092 +/- ##
==========================================
+ Coverage 63.56% 64.41% +0.85%
==========================================
Files 19 19
Lines 2566 2563 -3
Branches 910 909 -1
==========================================
+ Hits 1631 1651 +20
+ Misses 676 647 -29
- Partials 259 265 +6
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR! I have one minor remark.
Also, what's the output with your changes?
The stack trace contains module+offset line after patching:
|
Thank you! |
If the executable is stripped, I expect the
FailureSignalHandler
to dump module+offset for each stack frame, but the output is always(unknown)
.Seems like this is because of a typo in
OpenObjectFileContainingPcAndGetStartAddress
.Code to reproduce:
repro.zip
Just extract and run
./run_test.py
on the host (docker and python3 are required).Expected output
Actual output