Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upImproved array generation using generic mutations #357
Conversation
|
Might be good to actually use vector, there is a lot of random access going on. |
|
at merge point, can we squash all the |
|
can we fix these before i look at the changes more holistically |
| mutateAbiValue (AbiUInt n x) = getRandomR (0, 9 :: Int) >>= -- 10% of chance of mutation | ||
| \case | ||
| 0 -> (AbiUInt n <$> mutateNum x) | ||
| _ -> return $ AbiUInt n x | ||
| mutateAbiValue (AbiInt n x) = getRandomR (0, 9 :: Int) >>= -- 10% of chance of mutation | ||
| \case | ||
| 0 -> (AbiInt n <$> mutateNum x) | ||
| _ -> return $ AbiInt n x |
incertia
Feb 26, 2020
Member
can we make these 10 percents tunable config parameters. if you want to go the Rational route the JSON for that is { "numerator" : 1, "denominator" : 10 }. otherwise choose something like Double.
can we make these 10 percents tunable config parameters. if you want to go the Rational route the JSON for that is { "numerator" : 1, "denominator" : 10 }. otherwise choose something like Double.
ggrieco-tob
Mar 9, 2020
Author
Member
Increasing these values will make the tests to fail, because magic numbers are going to be (likely) corrupted. I think the user should be allowed to modify these.
Increasing these values will make the tests to fail, because magic numbers are going to be (likely) corrupted. I think the user should be allowed to modify these.
| import EVM.ABI (AbiValue(..)) | ||
|
|
||
| listMutators :: MonadRandom m => m ([a] -> m [a]) | ||
| listMutators = fromList [(return, 1), (expandRandList, 10), (deleteRandList, 10), (swapRandList, 10)] |
incertia
Feb 26, 2020
Member
can we config these weights as well?
can we config these weights as well?
ggrieco-tob
Mar 9, 2020
Author
Member
I need to experiment with these parameters (with the exception of the return one, which should be small), in order to understand which mutations are more useful. Probably @agroce will be interested on this as well.
I need to experiment with these parameters (with the exception of the return one, which should be small), in order to understand which mutations are more useful. Probably @agroce will be interested on this as well.
| xs <- f vs | ||
| return $ maybe xs (`take` (xs ++ fs)) mn | ||
|
|
||
| mutateBS :: MonadRandom m => Maybe Int -> [Word8] -> ByteString -> m ByteString |
incertia
Feb 26, 2020
Member
document
document
| listMutators :: MonadRandom m => m ([a] -> m [a]) | ||
| listMutators = fromList [(return, 1), (expandRandList, 10), (deleteRandList, 10), (swapRandList, 10)] | ||
|
|
||
| mutateV :: MonadRandom m => Maybe Int -> [AbiValue] -> [AbiValue] -> m [AbiValue] |
incertia
Feb 26, 2020
Member
can we document the new parameters
can we document the new parameters
| @@ -285,7 +294,7 @@ genAbiValueM = genWithDict (fmap toList . view constants) $ \case | |||
|
|
|||
| -- | Given a 'SolSignature', generate a random 'SolCalls' with that signature, possibly with a dictionary. | |||
| genAbiCallM :: (MonadState x m, Has GenDict x, MonadRandom m) => SolSignature -> m SolCall | |||
| genAbiCallM = genWithDict (fmap toList . view wholeCalls) (traverse $ traverse genAbiValueM) | |||
| genAbiCallM abi = genWithDict (fmap toList . view wholeCalls) (traverse $ traverse genAbiValueM) abi >>= mutateAbiCall | |||
incertia
Feb 26, 2020
Member
why are we doing a mutateAbiCall right after we gen?
why are we doing a mutateAbiCall right after we gen?
ggrieco-tob
Mar 9, 2020
Author
Member
This is an interesting question. I couldn't find an easy way to mutate only the results of the values generated by the dictionaries, but mutating the generated values will perform the same effect. If you have a better way to do it, please let me know.
This is an interesting question. I couldn't find an easy way to mutate only the results of the values generated by the dictionaries, but mutating the generated values will perform the same effect. If you have a better way to do it, please let me know.
This PR implements better mutations for arrays (e.g. strings, dynamic arrays, etc). It will allow Echidna to test complex code more effectively, in particular when a contract parses something on-chain. This PR is needed in order to eventually merge #305.