You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Assertion failure in scheduleCorpusImport with --jobs>=2 #551
Using --jobs=2 (or higher) with the v8Sandbox profile causes a crash due to an assertion failure at Fuzzer.swift:703:
assert(state == .uninitialized)
The child worker calls scheduleCorpusImport after the main fuzzer has already transitioned from .uninitialized to .corpusGeneration, violating the precondition.
Fuzzilli starts, completes corpus generation on the main instance, then crashes with:
Fuzzilli/Fuzzer.swift:703: Assertion failed
*** Signal 4: Backtracing from 0x7ee9132e2a30...
This occurs consistently within a few minutes of startup. --jobs=1 works fine. --jobs=2 and --jobs=4 both trigger the crash.
Expected Behavior
Multi-worker mode should work without assertion failures. The assertion at line 703 could be relaxed to allow corpus import during states other than .uninitialized, or the state transition should be synchronized so child workers don't race with the main fuzzer's initialization.
Target: V8 d8 (built with v8_fuzzilli=true, v8_enable_sandbox=true, is_asan=true, sanitizer_coverage_flags="trace-pc-guard")
OS: Ubuntu 22.04, 4 cores, 8GB RAM
Swift: 6.1
Analysis
The comment at line 701-702 acknowledges this limitation:
// Currently we only allow corpus import when the fuzzer is still uninitialized.
// If necessary, this can be changed, but we'd need to be able to correctly handle
// the .waiting -> .corpusImport state transition.
In multi-worker mode, the main fuzzer transitions to .corpusGeneration before child workers have finished initializing. When a child worker then tries to synchronize its corpus with the main instance via scheduleCorpusImport, the assertion fails because the fuzzer is no longer in .uninitialized state.
A possible fix would be to either:
Allow scheduleCorpusImport during .corpusGeneration / .fuzzing states
Delay the main fuzzer's state transition until all workers have completed initialization
Use a different synchronization path for child workers that doesn't go through scheduleCorpusImport
The fix should preserve a clear state transition rather than only relaxing the assertion, because corpus import after generation starts may be ordering-dependent. A regression with --jobs=2 and --jobs=3 could assert that every worker receives the initial corpus exactly once. Empty storage and a pre-populated corpus would be useful boundary cases.
Activity
hiSandog commentedon Jul 11, 2026
The fix should preserve a clear state transition rather than only relaxing the assertion, because corpus import after generation starts may be ordering-dependent. A regression with
--jobs=2and--jobs=3could assert that every worker receives the initial corpus exactly once. Empty storage and a pre-populated corpus would be useful boundary cases.