mupdf: build broken due to clang bug

[titanous]

Flagging this comment by @sebras for visibility:

https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41253

The last 2 builds for mupdf have been failing.
Build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-d4b0a056-d4fa-48d9-b033-efa67a886324.txt
Build type: fuzzing

---

I have checked the log and clang-14 complains like this:
clang-14: error: clang frontend command failed with exit code 70 (use -v to see invocation)

This is due to a bug in the compiler and has nothing to do with mupdf. There is not much I can do
about this besides reporting this upstream.

I don't have clang-14 on hand to build as Debian/testing doesn't carry it.
I'll test using clang-13 from Debian/unstable to try to reproduce this.

[DavidKorczynski]

CC @vanhauser-thc

[vanhauser-thc]

I cannot reproduce this with the random config that is printed in the build log. builds fine for me.

[vanhauser-thc]

is this issue still present? (since the last 2 days?)

[DavidKorczynski]

Does not look like it. The log from 2nd December has the same issues as the original issue: https://oss-fuzz-build-logs.storage.googleapis.com/log-3d110700-a2e3-4757-8925-e0429006ed06.txt

The log from 3rd December is running into the issue described here #6957

[sebras]

@vanhauser-thc

is this issue still present? (since the last 2 days?)

Issue 41253 was closed as building, but today another build issue appeared which seems similar to #6957

By the way did anyone notice the comment I made on the original issue?

Not sure if this helps anyone looking at this, but I sawl this link online saying that there might
be some sort of shared build cache causing problems:
NativeScript/nativescript-cli#5325

Perhaps this means that the cache cannot be shared between runs of different versions of clang?

If that helps you guys nail down the underlaying problem together with clang upstream it might
be worth a minute of your time to take a look at. :)

[DavidKorczynski]

@vanhauser-thc

is this issue still present? (since the last 2 days?)

Issue 41253 was closed as building

Yes, but I think was a wrong conclusion by the bot.

The bot set the build to be valid because of the non-determinism that there is in AFL builds. You can end up in a situation where the builds fails in one AFL setting but not the other, and that is what has happened here. If the bot chooses the good setting it will wrongfully determine the build is successful. If you look at the the log from 2nd December builds, then you will find it has a similar issue to the 24th November one. You can see the build logs here: https://oss-fuzz-build-logs.storage.googleapis.com/index.html#mupdf

The build has failed the last two days (2nd and 3rd December), however, it fails in two different ways: on the 2nd it fails due to the original issue and on the 3rd it fails because of #6957

[DavidKorczynski]

The build issues persist, the builds failed 15th 14th and 11th Dec:

• https://oss-fuzz-build-logs.storage.googleapis.com/log-900a4707-00c4-488a-abbd-845841b05cb4.txt
• https://oss-fuzz-build-logs.storage.googleapis.com/log-18542da7-f30b-4990-bf59-479428e3fad7.txt
• https://oss-fuzz-build-logs.storage.googleapis.com/log-8c01c7fe-47bc-4f7b-bd00-a5b56eb46e8b.txt

[maflcko]

Is this still an issue after ##7039?

[sebras]

This has not been an issue for me for a long while. I should probably have followed up with this, but I simply forgot to do so. Sorry about that. :)