Summary
CIFuzz is in a dead-lock for JavaScript projects. The config validator and the
compile script impose mutually exclusive constraints on SANITIZER, so there is
no value that produces a green fuzzing run.
The contradiction
Side A — infra/cifuzz/config_utils.py (line 32 + lines 153–155)
SANITIZERS = ['address', 'memory', 'undefined', 'coverage']
if self.sanitizer not in SANITIZERS:
logging.error('Invalid SANITIZER: %s. Must be one of: %s.',
self.sanitizer, SANITIZERS)
none is not in the list → ConfigError at config-validation time.
Side B — infra/base-images/base-builder/compile (lines 47–57)
if [ "$FUZZING_LANGUAGE" = "javascript" ]; then
if [ "$SANITIZER" != "coverage" ] && [ "$SANITIZER" != "none" ]; then
echo "ERROR: JavaScript projects cannot be fuzzed with sanitizers."
exit 1
fi
For a JavaScript project, any sanitizer except none or coverage → build
exits 1.
The pincer: coverage passes both checks, but a coverage build is not a
fuzzing run — it is a coverage-instrumented build used for corpus coverage
reporting. There is no sanitizer value that passes Side A and produces a
real fuzzing run for JS projects.
Observed error
Setting sanitizer: address (the only valid fuzzing sanitizer from Side A's
list) produces this error at compile time:
ERROR: JavaScript projects cannot be fuzzed with sanitizers.
Building fuzzers failed.
Setting sanitizer: none produces a ConfigError at config-validation time
(Side A) and the job never reaches compile.
History confirming it is not a project config mistake
In Fmarzochi/EGC:
- PR #377 switched
none →
address trying to fix the ConfigError. That fixed config-validation but
broke compile.
- Neither value has ever produced a green batch run. Five consecutive weekly
failures on main:
Expected behavior
none should be a valid SANITIZER value in config_utils.py for projects
whose language requires it (JavaScript, and potentially others). Alternatively,
the compile script's language-specific check should be relaxed in CIFuzz's
validation path, or CIFuzz should auto-select none for JS projects.
Workaround (applied in EGC)
Disabled the schedule: triggers on all three ClusterFuzzLite workflows (see
EGC#910) so the weekly red run
stops masking real CI failures. workflow_dispatch remains for manual runs.
The scheduled jobs will be re-enabled once this upstream contradiction is
resolved.
Relevant files
infra/cifuzz/config_utils.py — line 32 (SANITIZERS list), lines 153–155
(validation)
infra/base-images/base-builder/compile — lines 47–57 (JS language check)
Summary
CIFuzz is in a dead-lock for JavaScript projects. The config validator and the
compile script impose mutually exclusive constraints on
SANITIZER, so there isno value that produces a green fuzzing run.
The contradiction
Side A —
infra/cifuzz/config_utils.py(line 32 + lines 153–155)noneis not in the list → ConfigError at config-validation time.Side B —
infra/base-images/base-builder/compile(lines 47–57)For a JavaScript project, any sanitizer except
noneorcoverage→ buildexits 1.
The pincer:
coveragepasses both checks, but acoveragebuild is not afuzzing run — it is a coverage-instrumented build used for corpus coverage
reporting. There is no sanitizer value that passes Side A and produces a
real fuzzing run for JS projects.
Observed error
Setting
sanitizer: address(the only valid fuzzing sanitizer from Side A'slist) produces this error at compile time:
ERROR: JavaScript projects cannot be fuzzed with sanitizers.
Building fuzzers failed.
Setting
sanitizer: noneproduces a ConfigError at config-validation time(Side A) and the job never reaches compile.
History confirming it is not a project config mistake
In Fmarzochi/EGC:
none→addresstrying to fix the ConfigError. That fixed config-validation butbroke compile.
failures on
main:Expected behavior
noneshould be a validSANITIZERvalue inconfig_utils.pyfor projectswhose language requires it (JavaScript, and potentially others). Alternatively,
the compile script's language-specific check should be relaxed in CIFuzz's
validation path, or CIFuzz should auto-select
nonefor JS projects.Workaround (applied in EGC)
Disabled the
schedule:triggers on all three ClusterFuzzLite workflows (seeEGC#910) so the weekly red run
stops masking real CI failures.
workflow_dispatchremains for manual runs.The scheduled jobs will be re-enabled once this upstream contradiction is
resolved.
Relevant files
infra/cifuzz/config_utils.py— line 32 (SANITIZERSlist), lines 153–155(validation)
infra/base-images/base-builder/compile— lines 47–57 (JS language check)