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

Count Executions With Same Observer Value #2720

Open
riesentoaster opened this issue Nov 23, 2024 · 0 comments
Open

Count Executions With Same Observer Value #2720

riesentoaster opened this issue Nov 23, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@riesentoaster
Copy link
Contributor

Is your feature request related to a problem? Please describe.
I have a target that is unstable, i.e. for the same input I don't always get the same observation.

Describe the solution you'd like
I would like to have a way to count how often a certain Observer observes the same value to get a frequency distribution and figure out how bad things are. This could be implemented in three levels:

  1. A pure count of how often each observed value is measured — this would only really be useful with a single corpus entry and a NopMutator, but maybe a good start.
  2. A count of how often each value is measured, along with an example input that triggers this execution
  3. A count of how often each value is measured, along with a list of all inputs that triggered this execution — this would be really inefficient, but maybe useful for debugging.

Describe alternatives you've considered
Right now, in a very hacky way, I just hash the observer value in the executor and append that hash to a file. It also gets put in some metadata in the corpus, so I can correlate them after the fact. This is wildly inefficient. And I'm using the single corpus entry/NopMutator strategy.

I've also attempted to implement this as a feedback that updates a count field in some metadata entry on each is_interesting call, but I could not get those updated metadata values to be written to disk. It's also a bit hacky, because in is_interesting, I only have the input, and not the testcase, so I have to manually extract that from state -> corpus -> testcase. If this were to work, it would basically provide solution 2. But I'm not sure it's possible, I don't know the internals well enough.

Lastly, one could write a feedback that keeps an internal representation of input-outcome values (e.g. HashMap with the Observer value as the key and a tuple of (count, example_input) as the value, to get solution level 2. These values could then be written to disk at a certain interval, similar to OnDiskTomlMonitor.

Additional context
I'm just curious if anyone has an opinion on how this could be done in a pretty way.

@riesentoaster riesentoaster added the enhancement New feature or request label Nov 23, 2024
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