pkg/cover: failed to generate coverage profile, and strange symlink behavior

[Ben Kittner]

`failed to generate coverage profile: 669245 out of 765860 PCs returned by kcov do not have matching coverage callbacks. Check the discoverModules() code. Use ?force=1 to disable this message.`

I've tried updating my compiler to 14.1 per #4447, and now I'm occasionally seeing a few coverage points in a few files every other time I restart the manager, but the files and lines it reports getting coverage on are inconsistent between runs.

I'm not fuzzing in a cross arch environment, and I've gone through the suggested steps in linux/troubleshooting.md: I'm actually getting correct file/line coverage information from the kcov test program, and that's making me wonder whether it could be something other than the compiler bug mentioned in #4447.

The strange part comes when I accidentally pointed at kernel_obj through a symlink: in that case I can see the coverage percentage for all files/functions, and the files/functions listed with their associated coverage percentages seem to be at least a bit accurate. When my pseudo-syzkalls were broken early on I saw low coverage numbers in the entry files, which changed to greater coverage within the module once I fixed them, and so on. Once I fixed the symlink situation I actually lost coverage visibility.

I guess what I'm saying about the paragraph above is that it seems like file/function level coverage information is still available, but for some reason syzkaller doesn't render it except in an edge case.

The last commit I have from master is a9616ff57d4ef2794b54e02c26315c739ca8bc85

/proc/version: Linux version 5.10.219... (@ben-workstation) (gcc (GCC) 14.1.0, GNU ld version 2.30-113.el8) #1 SMP PREEMPT Tue Jul 9 20:59:49 UTC 2024

The first screenshot shows the coverage report with gcc14.1, with kernel_obj pointing directly to the direct directory and the second illustrates that I have file and function coverage visibility, but not line coverage visibility. The text log is the debug log with some identifying information scrubbed

[Dmitry Vyukov]

Hi Ben,

There is no ready answer for this. This needs to be debugged. It can
be lots of things.

I would suggest capturing coverage either from syz-manager /rawcover
endpoint, or by running syz-execprog with -coverfile flag so that it
saves coverage to files. And then use tools/syz-cover that renders
coverage report the same way syz-manager does. With tools/syz-cover
you can add as many debug prints as you need to see what PCs it
expects, which ones don't match, what source files it tries to read,
etc.

[Ben Kittner]

Thanks, I'm going to try this out.