made gdb pretty-printing more robust when printing uninitialized vec#66576
Merged
bors merged 1 commit intorust-lang:masterfrom Nov 23, 2019
Merged
made gdb pretty-printing more robust when printing uninitialized vec#66576bors merged 1 commit intorust-lang:masterfrom
bors merged 1 commit intorust-lang:masterfrom
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.
Contributor
|
(rust_highfive has picked a reviewer for you, use r? to override) |
Contributor
Author
|
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: |
Member
|
@bors: r+ |
Collaborator
|
📌 Commit 9b40e0b has been approved by |
emilyalbini
added a commit
to emilyalbini/rust
that referenced
this pull request
Nov 22, 2019
…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
Centril
added a commit
to Centril/rust
that referenced
this pull request
Nov 23, 2019
…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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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