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
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:
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.
A count of how often each value is measured, along with an example input that triggers this execution
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.
The text was updated successfully, but these errors were encountered:
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:NopMutator
, but maybe a good start.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 inis_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 theObserver
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 toOnDiskTomlMonitor
.Additional context
I'm just curious if anyone has an opinion on how this could be done in a pretty way.
The text was updated successfully, but these errors were encountered: