AFL-fuzz complain no instrument detected using partial instrumentation

[Nambers]

IMPORTANT

1. You have verified that the issue to be present in the current dev branch.
2. Please supply the command line options and relevant environment variables, e.g., a copy-paste of the contents of out/default/fuzzer_setup.

Thank you for making AFL++ better!

Describe the bug After using partial instrumentation with allow list, afl-fuzz complain about no instrument detected.

To Reproduce My building command: AFL_LLVM_ALLOWLIST='$WORK_DIR/afl-allow-list.txt' make -s altinstall -j$USING_CORE with afl-clang-lto I'd observe there are afl compiler output when I do the make and the content in allow-list are absolute file paths separated by newline.

Expected behavior Fuzzing normally.

Screen output/Screenshots

[+] Enabled environment variable AFL_DEBUG with value 1
[+] Enabled environment variable AFL_DEBUG with value 1
afl-fuzz++4.22a based on afl by Michal Zalewski and a large online community
[+] AFL++ is maintained by Marc "van Hauser" Heuse, Dominik Maier, Andrea Fioraldi and Heiko "hexcoder" Eißfeldt
[+] AFL++ is open source, get it at https://github.com/AFLplusplus/AFLplusplus
[+] NOTE: AFL++ >= v3 has changed defaults and behaviours - see README.md
[+] No -M/-S set, autoconfiguring for "-S default"
[*] Getting to work...
[+] Using exploration-based constant power schedule (EXPLORE)
[+] Enabled testcache with 50 MB
[+] Generating fuzz data with a length of min=1 max=1048576
[*] Checking core_pattern...
[*] Checking CPU scaling governor...
[+] You have 8 CPU cores and 1 runnable tasks (utilization: 12%).
[+] Try parallel jobs - see docs/fuzzing_in_depth.md#c-using-multiple-cores
[*] Setting up output directories...
[+] Output directory exists but deemed OK to reuse.
[*] Deleting old session data...
[+] Output dir cleanup successful.
[*] Checking CPU core loadout...
[+] Found a free CPU core, try binding to #0.
[*] Validating target binary...
[*] Scanning 'seeds_dir'...
[*] Creating hard links for all input files...
[+] Loaded a total of 1 seeds.
[*] Spinning up the fork server...
[__afl_auto_init_globals]
DEBUG: debug enabled
DEBUG: AFL++ afl-compiler-rt++4.22a
DEBUG: (1) id_str 61, __afl_area_ptr 0x555556ef9620, __afl_area_initial 0x555556ef9620, __afl_area_ptr_dummy 0x555556ef9620, __afl_map_addr 0x0, MAP_SIZE 65536, __afl_final_loc 9, __afl_map_size 9
DEBUG: (2) id_str 61, __afl_area_ptr 0x7ffff5800000, __afl_area_initial 0x555556ef9620, __afl_area_ptr_dummy 0x555556ef9620, __afl_map_addr 0x0, MAP_SIZE 65536, __afl_final_loc 9, __afl_map_size 9DEBUG: cmplog id_str <null>
[+] All right - new fork server model v1 is up.
[*] Forkserver options received: (0x00000001)
[*] Target map size: 9
[*] No auto-generated dictionary tokens to reuse.
[*] Attempting dry run with 'id:000000,time:0,execs:0,orig:a.py'...
[D] DEBUG: calibration stage 1/7

[-] PROGRAM ABORT : No instrumentation detected
         Location : perform_dry_run(), src/afl-fuzz-init.c:1284

Additional context Is there anything I can do to check?

[vanhauser-thc]

matching on filenames is difficult because filenames are not always present during compilation, do not ask me why. depends on -g (obviously) but also unknown things, maybe llvm version, current state of the moon etc. so likely in your case no filenames are present when the code is compiled and therefore nothing matches = no instrumentation. What always works is matching on function names.

[Nambers]

matching on filenames is difficult because filenames are not always present during compilation, do not ask me why. depends on -g (obviously) but also unknown things, maybe llvm version, current state of the moon etc. so likely in your case no filenames are present when the code is compiled and therefore nothing matches = no instrumentation. What always works is matching on function names.

hmm gotcha. idk why but seems afl-fuzz can run smoothly under persistent mode