Use strong-xml instead of serde and generalize frontend
#67
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
- use strong-xml instead of serde - display all errors, not only leaks - display <auxwhat>s and additional stacks - use the description provided by valgrind instead of providing our own
|
Ok, so the issue is apparently that libstd uses (the tests ran fine on my machine) |
|
Apparently Valgrind added a workaround for this "dubious use of statx" in |
|
Hi, @TheWastl, what is the current state of this PR? Does this require another code change or a change in CI? Anyways: thanks for your work and patience! |
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.
Use
strong-xmlinstead ofserdeserdedoesn't work very well with XML, see here. This PR usesstrong-xmlinstead, andstrumfor parsing enums from strings.strong-xml's#[derive(XmlRead)]is not as versatile asserde's#[derive(Deserialize)], however, so there are certainly also drawbacks to this switchDisplay all errors, not only leaks
Previously, only errors that leaked at least 1 byte were displayed. This excludes double-frees, access to unallocated or freed memory, use of uninitialized values and other errors detected by Valgrind. They are important too, and are handled now.
Display
<auxwhat>s and additional stacksSome error kinds (for instance, double-frees) output more information than a single line of description and one stack trace. This can easily be parsed with
strong-xml, and is then displayed to the user. This fixes #20, #54 and #55.Use the description provided by valgrind instead of providing our own
Previously, all error kinds would simply display the generic message "Leaked <amount> in <n> blocks". We now support other error kinds, so this had to be changed. The alternative would be to provide our own messages for every error kind.