-
Couldn't load subscription status.
- Fork 13.9k
made gdb pretty-printing more robust when printing uninitialized vec #66576
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
Conversation
…ed vec. I based this solution on my reading of: https://rethinkdb.com/blog/make-debugging-easier-with-custom-pretty-printers#what-is-still-to-be-done That post claims that there is no clean way to check for garbage pointers, and so this PR adopts the same solution of tentatively attempting to convert a dererence to a string, which throws a clean exception on garbage that we can catch and recover from. I only made the change to vec and not the other pretty printers because I wanted to focus my effort on the simplest thing that would resolve issue rust-lang#64343. In particular, I *considered* generalizing this fix to work on the other datatypes in the pretty-printing support library, but I don't want to invest effort in that until after we resolve our overall debugging support strategy; see also issues rust-lang#60826 and rust-lang#65564.
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
Oh, the specific behavior that occurs here is that when it hits garbage data, it terminates the loop over the children and prints I.e. for pretty-uninitialized-vec, you see this: |
|
@bors: r+ |
|
📌 Commit 9b40e0b has been approved by |
…r, r=alexcrichton made gdb pretty-printing more robust when printing uninitialized vec made gdb pretty-printing more robust when printing uninitialized vec I based this solution on my reading of: https://rethinkdb.com/blog/make-debugging-easier-with-custom-pretty-printers#what-is-still-to-be-done That post claims that there is no clean way to check for garbage pointers, and so this PR adopts the same solution of tentatively attempting to convert a dererence to a string, which throws a clean exception on garbage that we can catch and recover from. I only made the change to vec and not the other pretty printers because I wanted to focus my effort on the simplest thing that would resolve issue rust-lang#64343. In particular, I *considered* generalizing this fix to work on the other datatypes in the pretty-printing support library, but I don't want to invest effort in that until after we resolve our overall debugging support strategy; see also issues rust-lang#60826 and rust-lang#65564. Fix rust-lang#64343
…r, r=alexcrichton made gdb pretty-printing more robust when printing uninitialized vec made gdb pretty-printing more robust when printing uninitialized vec I based this solution on my reading of: https://rethinkdb.com/blog/make-debugging-easier-with-custom-pretty-printers#what-is-still-to-be-done That post claims that there is no clean way to check for garbage pointers, and so this PR adopts the same solution of tentatively attempting to convert a dererence to a string, which throws a clean exception on garbage that we can catch and recover from. I only made the change to vec and not the other pretty printers because I wanted to focus my effort on the simplest thing that would resolve issue rust-lang#64343. In particular, I *considered* generalizing this fix to work on the other datatypes in the pretty-printing support library, but I don't want to invest effort in that until after we resolve our overall debugging support strategy; see also issues rust-lang#60826 and rust-lang#65564. Fix rust-lang#64343
made gdb pretty-printing more robust when printing uninitialized vec
I based this solution on my reading of:
https://rethinkdb.com/blog/make-debugging-easier-with-custom-pretty-printers#what-is-still-to-be-done
That post claims that there is no clean way to check for garbage pointers, and
so this PR adopts the same solution of tentatively attempting to convert a
dererence to a string, which throws a clean exception on garbage that we can
catch and recover from.
I only made the change to vec and not the other pretty printers because I wanted
to focus my effort on the simplest thing that would resolve issue #64343. In
particular, I considered generalizing this fix to work on the other datatypes
in the pretty-printing support library, but I don't want to invest effort in
that until after we resolve our overall debugging support strategy; see also
issues #60826 and #65564.
Fix #64343