-
Notifications
You must be signed in to change notification settings - Fork 72
Add Murch’s inputs September 2025 #238
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Looks like it is adding 20 more lines of coverage, which is a minimal improvement. Given that there were two very recent pull requests to add inputs/coverage, I am not sure if the minimal improvement is due to the repo already being saturated or if there is something wrong with your setup. I'll go ahead and merge this, nonetheless. |
With two other contributions merged just days before, 20 additional lines seems pretty decent? For the moment, my working thesis is that the setup is fine. 🤷 |
Actually, a similar fluctuation of only a few lines in coverage difference was seen in #239 (comment) (a pull which should not influence coverage at all), so I fear that your setup may still not be working. If you are using libFuzzer, do you have logs around the |
I did a fresh merge from my current active fuzzing dir, here are the relevant lines:
|
Ah, nice. This one looks good/plausible. I wonder if the result changes if you do not merge into a new empty folder and keep the existing fuzz input folders. So the command would just end in e.g. Also, I wonder how the active fuzzing logs look like. Do they contain many |
This is from merging into the existing
|
I guess they occasionally add coverage, but doesn’t look like a ton. But then, some of our targets are pretty well-established, so there might not be much to find there anymore. Do you have a specific suggestion which target to fuzz for logs? |
Thanks for the new merge. This indeed shows that the coverage is already saturated for most targets on your machine and not adding many new files (module reductions maybe). Reducing the size of the fuzz inputs is also useful.
Yeah, I guess this still seems plausible.
Any would be fine, but I'd look at |
Currently running a 10 minute single thread fuzzing on
What I’m wondering is that my use of |
It found some new functions and in 600 seconds on a single thread added 903 to coverage. Seems to work fine?
|
Are there also RELOAD lines? According to https://llvm.org/docs/LibFuzzer.html#fork-mode:
Not sure what it means, but possibly, the child process could just spend time re-discovering already existing coverage (and not even sharing it with the other fuzz processes)? |
Since the |
I think that is just leveldb non-determinism. You may see the same "new" coverage on the next run? |
That might be it. It just inited back to 34599, whereas the previous run was 34592.
|
Curious whether it is gonna be useful this time.