Add Murch’s inputs February 2025

murchandamus commented at 8:22 pm on February 3, 2025: contributor

I used the process described in the README of my fuzzing-helpers repository: https://github.com/murchandamus/fuzzing-helpers?tab=readme-ov-file#upstreaming-the-results-about-every-two-months

Add Murch’s inputs February 2025 7ca0eff221

maflcko commented at 1:47 pm on February 4, 2025: contributor

This pull: https://drahtbot.space/host_reports/DrahtBot/reports/coverage_fuzz/monotree/1172bc4157eefe80/7ca0eff221557a8b/fuzz.coverage/index.html master: https://drahtbot.space/host_reports/DrahtBot/reports/coverage_fuzz/monotree/1172bc4157eefe80/ff2648d1387dfbaf/fuzz.coverage/index.html

maflcko commented at 1:47 pm on February 4, 2025: contributor

Looks like a mild improvement. Thx

maflcko merged this on Feb 4, 2025

maflcko closed this on Feb 4, 2025

maflcko commented at 7:12 pm on February 4, 2025: contributor

Sorry, I went ahead to temporarily revert this in commit 131d343df8db95fbaa58eb6acb84c5f7b3b4f4c1, as it seems to be increasing the load on the CI sufficiently to cause timeouts.

This should be fixed on the CI side. A few options are:

Bump 2h timeout for the fuzz task
Bump the CI machine(s) for a faster CPU
Make the fuzz targets faster
Something else?

murchandamus commented at 7:20 pm on February 4, 2025: contributor

There do seem to be a few targets that always take a lot of time during the merge. Are these the ones that are also causing an issue here? E.g., package_rbf, addrman_serdeser, wallet_notifications come to mind.

I could also remove the threads that are fuzzing with shorter limits, if we think that this is unduly inflating the count of inputs that we carry around, although I assume that it just finds shorter inputs faster that we would eventually find with more fuzzing. Perhaps we should prune more often?

maflcko commented at 7:21 pm on February 4, 2025: contributor

Yeah, ideally all fuzz targets are fast, but I think the low hanging fruits to improve there are taken.

Moreover, it looks like you are using all sanitizers to merge the folders, but none when searching new fuzz inputs? I wonder if this will bloat the merged set of files, given that the fuzz engine does not specifically try to reduce fuzz inputs based on sanitizer coverage while searching for new inputs?

I don’t know the answer, but my recommendation would be to either also search with sanitizers, or not use them to merge.

murchandamus commented at 7:26 pm on February 4, 2025: contributor

I do have a couple threads that run with sanitizers on the nightly fuzzing while most run without sanitizers, but maybe that’s not enough

maflcko commented at 7:35 pm on February 4, 2025: contributor

Ok, then it should be fine. The option to merge without sanitizers remains open, so that the qa-assets repo is a slimmer version focussing on CI. Obviously this could mean that sanitizer coverage is smaller in the CI, but it may be fine, given that people curate the sanitizer coverage outside of qa-assets either way?

murchandamus commented at 8:40 pm on February 4, 2025: contributor

I was merging without sanitizers for previous months, but then my submissions caused CI errors. I’m happy to adjust my procedure to always use sanitizers, never use sanitzers, or something else, but I must admit, it’s not entirely clear to me what would work best.

Do you think I should try to fuzz with a mix of sanitized threads and unsanitized threads, but merge without sanitizers afterwards? Wouldn’t that cause CI errors on submission again?

maflcko commented at 10:03 pm on February 4, 2025: contributor

I was merging without sanitizers for previous months, but then my submissions caused CI errors.

I presume you are referring to (mostly) integer sanitizer issues that were lacking a suppression or minor code fixup? In that case, I think it is preferable to discover triggerable errors than not to. If they were ignored, someone else will just run into them later on (if they haven’t already).

I’m happy to adjust my procedure to always use sanitizers, never use sanitzers, or something else, but I must admit, it’s not entirely clear to me what would work best. Do you think I should try to fuzz with a mix of sanitized threads and unsanitized threads, but merge without sanitizers afterwards? Wouldn’t that cause CI errors on submission again?

Yes, I think that makes sense, because:

Using sanitizers (in combination with non-sanitizer builds) during fuzz input generation is recommended practise and done by OSS-Fuzz and I presume everyone else fuzzing Bitcoin Core.
Assuming you refer to fuzz crashes as CI errors, this is desired, because the whole point of fuzzing is to find fuzz crashes.
It may lead to a slimmer qa-assets, causing less bloat. This is desirable, because at some level of bloat (even if the CI machines are upgraded to be faster), GitHub may delete the qa-assets repo due to it being outside the “reasonable” size.

So if you don’t mind, can you re-do this merge without sanitizers, so that the size and runtime can be compared?

murchandamus commented at 6:20 pm on February 5, 2025: contributor

Sure, I am re-doing the merge with the same inputs, i.e., the active-fuzzing corpus I set aside yesterday to make this upstream PR, using a branch that does not have sanitizers enabled. I did enable the suppressions, though.

murchandamus commented at 8:50 pm on February 5, 2025: contributor

I opened another pull request for the inputs merged without using sanitizers in #218.

murchandamus referenced this in commit e04b4af876 on Feb 6, 2025

murchandamus commented at 10:39 pm on February 6, 2025: contributor

I also updated my documentation to recommend merging without sanitizers: https://github.com/murchandamus/fuzzing-helpers

Add Murch’s inputs February 2025 #217