Happens rarely, mostly on slow targets ran for short (<20 minutes) periods of time.
To reproduce:
- Have a slow AFL++ fuzz target with a lot of input samples.
- Launch a fuzzing job on multiple cores for 1 second or other small value. Some fuzz targets are susceptible to this even when starting 20-minute jobs.
bb-fuzz will detect stop condition based on some (not ALL) instances, so the instances ending with '1' may not even finish loading their initial samples, so they won't have a folder under out.bb-coverage will fail if there were no instances ending with '1'.
To fix it we need to select some other folder when the first one's missing.
The relevant line is here.
Also: if a user only runs the coverage tool from bugbane (without bb-fuzz), then they may have other naming conventions for afl-fuzz instances. Currently such users will need to use bb-corpus manual.
Happens rarely, mostly on slow targets ran for short (<20 minutes) periods of time.
To reproduce:
bb-fuzzwill detect stop condition based on some (not ALL) instances, so the instances ending with '1' may not even finish loading their initial samples, so they won't have a folder underout.bb-coveragewill fail if there were no instances ending with '1'.To fix it we need to select some other folder when the first one's missing.
The relevant line is here.
Also: if a user only runs the coverage tool from bugbane (without bb-fuzz), then they may have other naming conventions for afl-fuzz instances. Currently such users will need to use
bb-corpus manual.