GraphicsMagick/libheif/vvdec issues not getting closed due to "Progression task errored out: Build setup failed"

[bobfriesenhahn]

There is a strange issue going on with GraphicsMagick issues related to libheif using the vvdec codec in that oss-fuzz is failing to automatically close issues. In all of these cases, the builds seem fine, and the issues no longer reproduce in builds that I create and test myself. The vvdec maintainers believe that they have addressed all of the issues that oss-fuzz says are still open.

When I look at the testcase detail (e.g. for issue 521915812 I see this error in the logs:

2026-06-09 06:46:42 UTC] oss-fuzz-tworker-1-cnxw: Fuzz task : Fuzzer libFuzzer_graphicsmagick_coder_HEIF_fuzzer generated testcase crashed in 124.0 seconds (r202606080645).
[2026-06-09 06:47:58 UTC] oss-fuzz-tworker-2-s4p7: Minimize task started.
[2026-06-09 07:37:03 UTC] oss-fuzz-tworker-2-3bq2: Minimize task finished.
[2026-06-09 07:37:45 UTC] oss-fuzz-tworker-1-rq1d: Regression task started.
[2026-06-09 07:57:47 UTC] oss-fuzz-tworker-2-38jn: Regression task started.
[2026-06-09 08:17:50 UTC] oss-fuzz-tworker-1-560f: Regression task started.
[2026-06-09 14:35:27 UTC] oss-fuzz-tworker-1-03nd: Regression task errored out: Timed out, current range r202605040702:r202605150600.
[2026-06-09 14:56:38 UTC] oss-fuzz-tworker-1-nmft: Regression task started.
[2026-06-09 15:07:03 UTC] oss-fuzz-tworker-2-5zq6: Regression task started.
[2026-06-09 15:17:04 UTC] oss-fuzz-tworker-2-tzh3: Regression task started.
[2026-06-09 19:54:21 UTC] oss-fuzz-tworker-1-gdx6: Regression task finished: regressed in range 202605040702:202605060640.
[2026-07-13 13:20:33 UTC] oss-fuzz-tworker-1-nbmn: Progression task started.

The 2026-06-09 date is a long time ago, and 2026-07-13 is today.

It seems as if the oss-fuzz infrastructure is not working. The testcase gets started but eventually it fails. I am not allowed to see "GCP Task Logs". If I download "task logs" I get an empty file?

How can this be solved?

[bobfriesenhahn]

I fixed an oss-fuzz issue unrelated to vvdec and oss-fuzz detected that it was fixed immediately. This means that the oss-fuzz mechanisms are working for other parts of the code.

[bobfriesenhahn]

Paging @DavidKorczynski, any ideas regarding this problem? I have no visibility into the oss-fuzz mechanisms which are failing due to an apparent timeout.

[DavidKorczynski]

@vitaliset @javanlacerda @ViniciustCosta can you take a look at this? I suspect this is something in Clusterfuzz

[bobfriesenhahn]

Today it requires almost 3 minutes to open oss-fuzz testcase details on the web. If oss-fuzz internal mechanisms are also suffering from this slowness, perhaps timeouts in the oss-fuzz infrastructure are causing issues to not be automatically closed?

[PauloVLB]

The issue is likely due to the size of the builds. Setting up the build is failing for several tasks within this project's fuzzers, including the progression task, which is required to close the issue.

Based on our logs from the last 30 days, this issue has been occurring since 2026-07-05:

[bobfriesenhahn]

All available advice has been to produce fully-static builds, and that is what my original mentors delivered to me. Since then, I have expended great effort to incorporate many more libraries into a static build. Unfortunately, a separate executable binary needs to be produced for each input format (really just a difference of a character string and the program name), and this multiplies the space requirement and the time to link the software.

A few days ago, I removed vvdec from the build so its symbols should not appear at all, and the build is smaller, but perhaps it can not be flushed out due more space required to verify that the issue is gone than to verify that there is an issue.

How big may a build be and still not exceed the required space?

[bobfriesenhahn]

The flip side of this issue is if 41 GB of free space is required, perhaps something needs to be cleaned up on the validation server to free up space.