issue with afl-fuzz cpu detection?

[gasche]

I seem to fail to use ocaml-bun on my machine due a problem that may be a configuration problem on my end, but that maybe has been seen before by previous ocaml-bun users who may know what to do.

If I run afl-gotcpu, I am told that all my cores are available. But then I do

AFL_SKIP_CPUFREQ=1 bun -v -v -i input -o output _build/default/.../myprogram.exe

and I observe the following:

Fuzzers launched.  Waiting 56 seconds for the first status update...
[+] You have 4 CPU cores and 4 runnable tasks (utilization: 100%).
[+] You have 4 CPU cores and 4 runnable tasks (utilization: 100%).
[*] Checking CPU core loadout...
[*] Checking CPU core loadout...
[+] You have 4 CPU cores and 5 runnable tasks (utilization: 125%).
[*] Checking CPU core loadout...
afl-fuzz 2.52b by <lcamtuf@google.com>
[+] Disabling the UI because AFL_NO_UI is set.
[+] You have 4 CPU cores and 1 runnable tasks (utilization: 25%).
[+] Try parallel jobs - see docs/parallel_fuzzing.txt.
[*] Checking CPU core loadout...

[-] Uh-oh, looks like all 4 CPU cores on your system are allocated to
    other instances of afl-fuzz (or similar CPU-locked tasks). Starting
    another fuzzer on this machine is probably a bad plan, but if you are
    absolutely sure, you can set AFL_NO_AFFINITY and try again.

[-] PROGRAM ABORT : No more free CPU cores
         Location : bind_to_free_cpu(), afl-fuzz.c:490


[-] Uh-oh, looks like all 4 CPU cores on your system are allocated to
    other instances of afl-fuzz (or similar CPU-locked tasks). Starting
    another fuzzer on this machine is probably a bad plan, but if you are
    absolutely sure, you can set AFL_NO_AFFINITY and try again.

[-] PROGRAM ABORT : No more free CPU cores
         Location : bind_to_free_cpu(), afl-fuzz.c:490


[-] Uh-oh, looks like all 4 CPU cores on your system are allocated to
    other instances of afl-fuzz (or similar CPU-locked tasks). Starting
    another fuzzer on this machine is probably a bad plan, but if you are
    absolutely sure, you can set AFL_NO_AFFINITY and try again.

[-] PROGRAM ABORT : No more free CPU cores
         Location : bind_to_free_cpu(), afl-fuzz.c:490


[-] Uh-oh, looks like all 4 CPU cores on your system are allocated to
    other instances of afl-fuzz (or similar CPU-locked tasks). Starting
    another fuzzer on this machine is probably a bad plan, but if you are
    absolutely sure, you can set AFL_NO_AFFINITY and try again.

[-] PROGRAM ABORT : No more free CPU cores
         Location : bind_to_free_cpu(), afl-fuzz.c:490

If I don't pass -v -v, then I just wait for a minute to learn that each instance did 0 computation per second.

It looks like there is something wrong with the way spawning multiple afl-fuzz instances interacts with running then. On the other hand, I did manually run multiple -S invokations of afl-fuzz in parallel and it worked fine. Have you seen such a problem before?

[yomimono]

Do you still see this if you don't set AFL_SKIP_CPUFREQ=1? There is indeed a bit of management necessary to keep multiple afl-fuzz launches from interfering with each other's CPU detection, which is probably affected by that choice. (bun should do the right thing regardless of whether this is set and currently doesn't so there's definitely something to do here, but I'd like to know whether you still see this behavior without it.)

Failure to launch any afl-fuzz instance should cause bun to terminate, so I'll look into that as well.

[gasche]

Just a short note: I have done more tests and I now believe that the issue is not bun-specific. I have seen similar (less frequent) failures by running afl-fuzz -S by hand, or in a shell script, and I have observed that running afl-gotcpu repeatedly may intermittently give back results that appear nonsensical (with a subset of cores intermittently marked CAUTION).

There may be improvements to be done on the bun side to work around these (for example, once you get results from afl-gotcpu), but the problem is not bun-specific. Should I close this PR?

(Re. AFL_SKIP_CPUFREQ. After first experimenting with the performance frequency scheduler, I decided that setting and unsetting it on my laptop was not worth the hassle and to take the potential performance hits of ondemand instead. Now it might be that this intermittent afl-gotcpu failure is caused by the cpu scheduling policy, and wouldn't occur on my machine with performance. I will try to make some tests; if that is confirmed, I may go back to setting/unsetting the scheduler.)

[yomimono]

Thanks for the update! I have patches for the other problem (caused by me stupidly using Unix.sleep without really understanding its semantics), so you can close this if you like.