Panic if defmt data comes in too thick and fast

[ExplodingWaffle]

thread 'main' panicked at 'no entry found for key', probe-rs-cli-util\src\rtt.rs:259:81

This seems to be related to the application sending too much data over RTT/defmt. minimal repro:

let var1 = 1234u32;
let var2 = 5678u32;
let var3 = 4321u32;

loop {
    info!("{} {} {}", var1, var2, var3)
}

Obviously this example is a bit stupid but this happened to me while sending messages in my application every 1ms (with rtic). Not sure what should happen here but probably not this.

[Dirbaio]

I think this is actually 2 separate bugs:

• probe-rs-debugger not switching RTT to BlockIfFull, so if you print too fast the buffer fills up, which corrupts the defmt stream.
• the indexing there should handle the error, and print "defmt decode failed" and carry on, instead of crashing (if the stream is corrupted, it's possible a corrupted defmt frame decodes correctly by chance to a garbage index) (OR perhaps decode() is supposed to already fail on garbage indexes, in which case the bug is somewhere else?)

[noppej]

As per matrix discussion, labeling this as an enhancement ... to add a config option to set defmt into blocking mode on connect, and have the config default to "true".

@Dirbaio The second part you are referring to with the possible index corruption. Is that a bug for defmt crate, or ???

[noppej]

@ExplodingWaffle I was not able to reproduce your panic with the test case provided. That said, I made the change suggested by @Dirbaio (switching RTT to BlockIfFul).

Can you please re-test this against the PR #1210 ? (Hint: You can install with cargo install --git https://github.com/probe-rs/probe-rs --force --branch blocking_defmt probe-rs-debugger, then when you are done, you can revert by doing the same for branch master)

[noppej]

Closing this as fixed in #1210. Please feel free to re-open with additional information if you can still reproduce it.