StreamDeserializer enters a busy-loop for malformed input #647
Comments
|
Fixed in 1.0.51. |
bors bot
added a commit
to rust-lang/rust-analyzer
that referenced
this issue
Apr 5, 2020
3859: Update serde_json r=kjeremy a=kjeremy Grabs fix for serde-rs/json#647 Co-authored-by: kjeremy <kjeremy@gmail.com>
bors bot
added a commit
to rust-lang/rust-analyzer
that referenced
this issue
May 10, 2020
4406: Update cargo-metadata r=matklad a=edwin0cheng This PR update `cargo-metadata` to 0.10.0 and it also relax the` serde-derive` deps to 1.0 for tests in `proc-macro-srv`. cc @robojumper r= @matklad , I think you would have something to say related to serde-rs/json#647 (comment) ? 4410: Improve wording in comment r=matklad a=edwin0cheng 4411: do not remove then block when you unwrap else block #4361 r=matklad a=bnjjj close #4361 4417: Omit default types in HirDisplay SourceCode mode r=matklad a=TimoFreiberg Closes #4390 Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com> Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com> Co-authored-by: Timo Freiberg <timo.freiberg@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See the test in
oli-obk/cargo_metadata@ea84dc3
There, the
for message in stream_deserilizerloop loops infinitelly, because serde repeteadly tries to parse the same invalid portion of input.I think the correct behavior here is to "poison" the Iterator after the first error and return
None. I can also imagine some error-recovey strategy (like skipping to the next utf8 codepoint), but poisoning seems more reliable to me.The text was updated successfully, but these errors were encountered: