Accept more issue types (such as invalid reads) #80
Conversation
This file contains 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
This test currently fails, as `cargo valgrind` panics due to a currently unknown reason.
This commit is a quick and dirty solution to #74 and similar issues. The valgrind output looks something like this: <what>Invalid read of size 4</what> <stack> ... </stack> <auxwhat>Address 0x4aa3b28 is 0 bytes after a block of size 24 alloc'd</auxwhat> <stack> ... </stack> `serde` (rightfully) did not allow deserializing the same field twice into a single stack trace. Therefore the solution is to just let it read into a vector. The code using it now just always reads the first entry in this vector, effectively discarding the additional information, which is not good, but easiest for now.
Previously the filter in the iterator over errors did filter out stuff
like `InvalidRead`s, since they don't leak memory. As they still uncover
errors in the implementations, those issues should be reported.
Note, that the main code does not correctly handle such issues, and dis-
play output like this:
Error leaked 0 B in 0 blocks
Info at core::fmt::num::imp::<impl core::fmt::Display for i32>::fmt (num.rs:317)
at core::fmt::num::<impl core::fmt::Debug for i32>::fmt (num.rs:195)
at <&T as core::fmt::Debug>::fmt (mod.rs:2368)
at {closure#0} (builders.rs:505)
at {closure#0}<core::fmt::builders::{impl#6}::entry::{closure_env#0}> (builders.rs:430)
at and_then<(), core::fmt::Error, (), core::fmt::builders::{impl#5}::entry_with::{closure_env#0}<core::fmt::builders::{impl#6}::entry::{closure_env#0}>> (result.rs:1346)
at entry_with<core::fmt::builders::{impl#6}::entry::{closure_env#0}> (builders.rs:416)
at core::fmt::builders::DebugSet::entry (builders.rs:505)
at core::fmt::builders::DebugList::entries (builders.rs:695)
at <[T] as core::fmt::Debug>::fmt (mod.rs:2618)
at <&mut T as core::fmt::Debug>::fmt (mod.rs:2372)
at fmt (rt.rs:173)
at core::fmt::write (mod.rs:1182)
at write_fmt<std::io::stdio::StdoutLock> (mod.rs:1827)
at <&std::io::stdio::Stdout as std::io::Write>::write_fmt (stdio.rs:787)
at write_fmt (stdio.rs:761)
at print_to<std::io::stdio::Stdout> (stdio.rs:1117)
at std::io::stdio::_print (stdio.rs:1227)
at issue_74::ex4 (issue-74.rs:34)
at issue_74::main (issue-74.rs:66)
Summary Leaked 0 B total
This should be improved in another commit.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Fixes #74, which reported the panic caused by some errors containing multiple stack traces (e.g. a main one and an auxiliary one with a dedicated error message. This PR accepts such additional error traces and displays them accordingly. The output for the code in question in #74 looks now like this:
While the auxiliary stack trace is not yet printed, this at least makes the tool usable with such errors.