Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crossover mutators currently don't work with nested MappingMutators #2944

Open
riesentoaster opened this issue Feb 6, 2025 · 0 comments
Open
Labels
enhancement New feature or request

Comments

@riesentoaster
Copy link
Contributor

One may want to use two (or more) nested MappingMutators, one to map from a complex input type to a primitive that can be mutated by built-in mutators such as havoc_mutations, and one to map from a composite input type (such as a list of the complex input type, which would e.g. be a list of network packets) to the complex input type.

This limitation is because one can only pass a single mapper to the mutator which extracts the data to be injected from the corpus. In the future, this mapping should be done in MappingMutator as well (maybe an alternate crossover version). However, for crossover the dependency between the different stages of MappingMutators is the reverse to the mapping of the current input. This makes it somewhat tricky.

I have at some point toyed around with an implementation which would create a new CrossoverMutator trait, which has a default Mutator implementation and just maps the current input and the crossover input and passes those two to the default impl for the actual mutation. With this approach, for the crossover mapping, one needs to create closures at each level of mapping, each owning the next-lower crossover mapper. I've not managed to get past lifetime limitations because the default impl needs to receive both a mut reference to state (because certain mutators need a source of randomness), and a reference to the input, which depends on state as well, so the borrow checker complained.

I may give it another go at some point, for now I just wanted to document this limitation. If anyone wants to work on this though, please do!

@riesentoaster riesentoaster added the enhancement New feature or request label Feb 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant