-
Notifications
You must be signed in to change notification settings - Fork 364
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
[Bug-Candidate]: Echidna multicore produces slower shrinking behavior #1105
Labels
Milestone
Comments
I often encounter the same thing. I think this is because the different workers can overwrite each others "best shrunk" version and kind of work against each other that way. |
Yes, this is a known issue to be fixed |
I think minimization should be restricted to a single worker |
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the issue:
I am running echidna with 8 workers, but I am getting unexpected/unwanted results for the shrinking step when a bug is found:
Instead of shrinking faster, when I add more workers the process is significantly slower.
Sometimes I see the shrink step go down, and then up, then down, and then up. It seems like increasing the number of workers adds a bunch of (duplicate) transactions that do not contribute to the smallest sequence possible.
I did a small 1-min test, reutilizing the corpus, with 1 worker vs 8 workers. You can see below that using more workers makes echidna run much slower when a bug is found.
1 worker
8 workers
Code example to reproduce the issue:
N/A
Version:
Echidna 2.2.1
slither 0.9.2
Relevant log output:
The text was updated successfully, but these errors were encountered: