Closed unionsung closed 1 year ago
Hi @SSWena! It's not completely clear to me what the issue is. Could you maybe create a small example (project) that I can try out to see the issue?
While it's possible that the situation could be improved, this is a fundamental limitation of the approach used in Autofuzz. We are actively working on a new mutation engine for Java types that has proper support for recursive data types.
In the meantime, if you happen to achieve "quick wins" by tweaking the heuristics used in Meta#consume
or Meta#consumeArguments
, please let us know or submit a PR.
Ok, thanks!
At 2023-07-05 20:15:20, "Fabian Meumertzheim" @.***> wrote:
While it's possible that the situation could be improved, this is a fundamental limitation of the approach used in Autofuzz. We are actively working on a new mutation engine for Java types that has proper support for recursive data types.
In the meantime, if you happen to achieve "quick wins" by tweaking the heuristics used in Meta#consume or Meta#consumeArguments, please let us know or submit a PR.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
I find that there are many recursive parameter processes, which cause a loop operation such as ConsumeArguments(data, method, visitor)-> ConsumeArguments(data, constructor, visitor); Consume(data, type, visitor) -> Consume(data, type ,visitor). These operation may cause some fuzz cannot further forward. For example, when the parameter in the method and the parameter in the constructor invokes the loop dependency, Jazzer will be stuck in the loop that consumes cpu and memory continuously and cannot perform effective autofuzz action.