internal/fuzz: revisit use of shared memory-mapped files for marshaled inputs #48163
Currently, the fuzzing coordinator process creates a 100MB temporary file for each worker process. Both the coordinator and worker read and write the file via a shared memory map. The file is currently used for 1) a few "header" fields such as iteration count and PRNG state, and 2) passing marshaled inputs for fuzzing in both directions.
We still need to use shared memory for the header fields. If a worker process terminates unexpectedly, the coordinator needs to be able to reconstruct the input that caused the crash using the initial input (sent from the coordinator), the call count, and the PRNG state.
However, it's not strictly necessary to write marshaled inputs to shared memory. It would be simpler to pass these through the pipes we use for RPCs. If we only supported unmarshaled byte slices, there would be a performance advantage to writing and mutating those directly in shared memory without incurring the cost of marshaling and pipe I/O. Since we need to marshal inputs anyway, it's not clear the extra complexity is worthwhile.
We should investigate the performance difference and pass inputs through pipes if it's not too bad. This would simplify our implementation, and would let us use much smaller shared memory files.
Additionally, for inputs that can be read from files, such as those in testdata or the cache, we can pass file names over pipes instead of reading, and sending that data over pipes. The coordinator doesn't need to hold that data in virtual memory at all.
The text was updated successfully, but these errors were encountered: