Add the first fuzz target for Qt

[rlohning]

This builds Qt and a first fuzz target for it. Qt's sources contain further fuzz targets already, but I'd like to start with one to see if and how this all works. If it does, I'll add the others one by one.

Improvements I'd like to do soon, i.e. not in this change:

• further fuzz targets
• dictionaries
• add proper parameters to Qt's configure instead of editing the mkspec files in build.sh

In case I made any mistakes, please let me know and I'll happily fix them.

A healthy, happy new year to all of you. :-)

[rlohning]

Can you please give me a hint how I could fix the afl-build in the CI?

It fails because the "binary is not instrumented" and points me to docs/README. That again tells me to use AFL's compiler wrappers, but Travis uses "CC=clang" and "CXX=clang++".

What am I missing? What can I do to fix this?

Thanks in advance for your help, see you next year. :-)

[jonathanmetzman]

That usually happens when your AFL target is actually built for use with libFuzzer (-fsanitize=fuzzer) instead of AFL (LIB_FUZZING_ENGINE).
I can't tell that you are doing this for sure, since your build.sh doesn't seem to be using -fsanitize=fuzzer or LIB_FUZZING_ENGINE, but that itself is a sign that you aren't building AFL targets correctly.

[rlohning]

Happy new year! :-)

Thank you for that hint. I have "-fsanitize=fuzzer" hardcoded in the fuzz target's project file. Now I added a workaround which removes that line using sed. I'll provide a better fix in Qt's sources but this will take a bit of time for the review- and merging-process, so for now, continuing with the workaround seems fine to me.

Please let me know if there's anything else I should change.

[jonathanmetzman]

2020 resolution: Find Qt bugs!

[rlohning]

We will, I'm afraid. ;-)

Thank you!

[kcc]

Does this fuzz target actually run?
I've tried running it locally and it complains

build/out/qt/readnext: error while loading shared libraries: libQt6Core.so.6: cannot open shared object file: No such file or directory

Adding LD_LIBRARY_PATH=build/out/qt/lib makes it work, but will ClusterFuzz do it?

[jonathanmetzman]

Good call. You can see this happening on ClusterFuzz as well: https://console.cloud.google.com/storage/browser/_details/qt-logs.clusterfuzz-external.appspot.com/libFuzzer_qt_readnext/libfuzzer_asan_qt/2020-01-03/00:14:59:619094.log?project=clusterfuzz-external

I wonder how this passed travis.

[jonathanmetzman]

You can't use absolute paths to dynamic libraries. In fact it's better not to use them at all. But if you must, then you need to use $ORIGIN.

I wonder how this passed travis.

Because /out exists on the runner and the builder but not on ClusterFuzz :-(

[rlohning]

/out does not exist? So where am I supposed to put the binaries instead?

[rlohning]

Does this fuzz target actually run?
I've tried running it locally and it complains

This looks like you tried running the fuzz target directly from outside the docker image. Then, of course, it cannot find the lib inside the docker image.

When I start the fuzz target using
python infra/helper.py run_fuzzer qt readnext
it seems to work fine.

Is running the fuzz target from outside the docker image expected to work?

[rlohning]

If it is meant to work, #3188 will do it.

[jonathanmetzman]

Is running the fuzz target from outside the docker image expected to work?

It isn't mean to work.

When I start the fuzz target using
python infra/helper.py run_fuzzer qt readnext
it seems to work fine.

Sorry this should have failed. It only passed due to a bug that made run_fuzzer run the fuzzer in an environment that resembled (in one important respect) the builder instead of ClusterFuzz

[rlohning]

Today, my build failed with:

Step #13: BAD BUILD: fuzzing /tmp/not-out/readnext with afl-fuzz failed.

Just like a number of other projects did. Running check_build locally passes.

Is this something I could fix or may I hope that the next build will pass?

[jonathanmetzman]

Sorry I think that was a hiccup (see #3194) I caused when trying to ensure that the mistake you initially made gets caught by CI.
I apologize for the confusion. I've fixed the issue. The latest builds for qt seem to pass.

[rlohning]

They do. Thank you for fixing it.

[rlohning]

Oh, no they don't, see https://oss-fuzz-build-logs.storage.googleapis.com/log-cd589d68-203a-4e05-af65-efb95abe3484.txt

Step #5: [/corpus/readnext.zip]
Step #5: End-of-central-directory signature not found. Either this file is not
Step #5: a zipfile, or it constitutes one disk of a multi-part archive. In the
Step #5: latter case the central directory and zipfile comment will be found on
Step #5: the last disk(s) of this archive.
Step #5: unzip: cannot find zipfile directory in one of /corpus/readnext.zip or
Step #5: /corpus/readnext.zip.zip, and cannot find /corpus/readnext.zip.ZIP, period.
Finished Step #5
ERROR
ERROR: build step 5 "gcr.io/oss-fuzz-base/base-runner" failed: exit status 9

The file was zipped a couple of lines higher and that seems to have succeeded. Does anything go wrong when copying the file?

[Dor1s]

@rlohning This last error is from the coverage build. The missing corpus in not seed corpus provided with the build, it's minimized corpus backup created by ClusterFuzz.

I have added an auxiliary message to such failures in cfe13cb#diff-40efeb3947f1f992a35c2c73c6992689R180

[rlohning]

Sorry, I don't quite get it. Is there anything I can do about that issue?

[rlohning]

Now, without any changes from my side, a build succeed and I get coverage statistics. This seems to answer the question above. :-)

[Dor1s]

Awesome! Sorry for the trouble.

[rlohning]

All fine. Thank you for your patience. :-)