allow for more coverage data in total
#519
Conversation
| @@ -46,6 +46,9 @@ impl TotalCoverage { | |||
| pub async fn update_bytes(&self, new_data: &[u8]) -> Result<()> { | |||
| match self.data().await { | |||
| Ok(Some(mut total_data)) => { | |||
| if total_data.len() < new_data.len() { | |||
| total_data.resize_with(new_data.len(), || 0); | |||
There was a problem hiding this comment.
The total table is the concatenation of the modules in filesystem-iteration order. This is not defined, but we assume it is stable. I don't think this assumption is actually valid.
Even if it held, the resizing of the total (on input coverage analysis where we discover a new module) assumes the new coverage data is appended to the old, but this isn't necessarily true. Suppose we always iterated files in a lexicographic ordering. If our total coverage only included fuzz.exe before, and then we discover core.dll, the new total.cov will have us merge core.dll.cov over the existing fuzz.exe.cov, then extend total.cov to accomodate the difference in size.
Stability of coverage map size does hold for each individual module. So I think the real fix is to just create and rewrite the total.cov on each input, instead of merging over the last one. In this way, we can just piggyback on the correct merging of the individual modules.
There was a problem hiding this comment.
I've updated the combined total to use the per-module totals.
Note, the per-module total is now a BTreeMap, which means they will be consistently sorted based on the filenames. Let's call that... eventual consistency? ;)
ghost
locked as resolved and limited conversation to collaborators
No description provided.