-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
fuzz test the compiler #1125
Comments
Very similar project CSmith. Some months ago I was running |
I think this should be done in any case. |
I am using libfuzzer (from the llvm project) manually now and it detects quite a lot of crashes. The problem is that it exits for the first crash, not sure if that is intended use. |
Yes that is the intended use. |
I am running an AFL-fuzz now, found it pretty straight-forward to set up. Build and install AFL
Instrument the solidity source:
Create a sample input file, and an output directory, then do fuzzing
It's running, no crashes yet. |
@holiman we do not only want to detect segmentation faults but also InternalCompilerErrors. The problem with the latter is that this is still blocked by #1133 Furthermore, if you want to get better example input, you can use https://github.com/ethereum/solidity/blob/develop/scripts/isolateTests.py to extract the end to end test cases from the .cpp file. |
Closing this as we have the necessary infrastructure in place now. |
Set up a server to continuously fuzz test the compiler with the goal to find crashes.
There are two kinds of crashes:
For the second kind, it is hard to find "unanticipated" crashes because some internal compiler errors correctly signal non-implemented features. We might split this exception class into two different classes in the future to be able to detect "real" errors.
The text was updated successfully, but these errors were encountered: