[PATCH] D100161: Redistribute energy for Corpus

[taotao gu via Phabricator via cfe-commits]

gtt1995 added a comment.

In D100161#2683632 <https://reviews.llvm.org/D100161#2683632>, @morehouse wrote:

> Also, the descriptions states:
>
>> Divide the corpus into n parts according to size.
>
> Is it really according to size?  IIUC when there are multiple worker processes, any new coverage they have simply gets appended to `Files`.  So `Files` is not necessarily sorted by size.

1.Sorry, I want to know  'Files' is sorted by size necessarily in the trunk  version ,is it different from the https://github.com/Dor1s/libfuzzer-workshop? The shared data is collected on the https://github.com/Dor1s/libfuzzer-workshop , and the new evaluation data is still tested in the trunk version ,the data seems promising.

2. I have a question. When they created the task for the first time, the ’FILES‘ were sorted strictly according to the size. The newly covered seeds were added after the Files were appended, which means that the new seeds in the future may not necessarily be sorted according to the size. , Then my theory may not hold true, but from the experimental data, at the same time, the average seed size of the main corpus is very small.The cov is more, this method may give little seeds more energy from a certain angle, but I don’t seem to be able to explain this phenomenon. Can you help me?
3. Wouldn't it be better if FILEs were always sorted strictly according to size? Because the use of corpus grouping is equivalent to N more locations for extracting seeds in the entire corpus, so Rand->SkewTowardsLast(Files.size()) may not be appropriate, so it tends to extract newly added seeds .
4. How to implement File is strictly sorted according to seeds. I only came into contact with libfuzzer code last two weeks and I am not very familiar with it .


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D100161/new/

https://reviews.llvm.org/D100161