-
Notifications
You must be signed in to change notification settings - Fork 22
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
Document how to symbolicate fuzzer stack traces #24
Comments
Those stacks are the stack at the time that the leaked memory was allocated. There are some build configurations where you can see symbolicated stack traces instead of just addresses. This makes the information much more actionable and easier to process without using Yes, we should definitely document this once we figure it out. I don't think we want to adopt a post-processing tool into this repo / tool. IME, post-processing tools, especially of ad-hoc/human readable formats rather than something like JSON, are a pain to maintain across upstream upgrades. |
https://clang.llvm.org/docs/AddressSanitizer.html#symbolizing-the-reports seems relevant. Unfortunately, it looks like the |
I had
and after that, I get properly symbolicated stack traces for your example leak:
|
Thanks for your research! I was able to replicate this using Feel free to close this question. |
I think we should keep this open to track documenting this stuff. I'll also move it to the book repo's issue tracker. |
Hi, first of all
cargo-fuzz
is awesome 👍.I have been playing a little with it. And I found out that resolving memory leaks is not as easy as I thought.
An example:
Searching online for the documentation, I wasn't able to find what this trace means and how to correlate it with the original source code. Not even in LLVM sanitizer docs. After some playing with
objdump
I found a manually intensive way of retrieving the information one by one.To simplify this, I have created a PoC tool in Python to do this automatically.
It is located at https://github.com/MatejKastak/cargo-fuzz-sourcer if anyone is interested.
The question ❓
objdump
reasonable?I hope I am not missing something obvious and reinventing the wheel.
The text was updated successfully, but these errors were encountered: