Panic on txn with value > 21mill in ChannelMonitor::block_connected, Clean up fuzz targets a bit #454
Conversation
Previously, in each of our fuzz tests we had a dummy test which had a hard-coded hex string which it passed into the fuzz target so that when a failing test case was found, its hex could be copied into the test and you could run cargo test to analyze the failure. However, this was somewhat unwieldy as converting large tests back and forth between hex and raw files is quite annoying. Instead, we replace each of those tests with a test in each target that looks for files in fuzz/test_cases and runs each file it finds. Since we're editing every bin target anyway, we also automate adding no_main to libfuzzer builds with #![cfg_attr].
full_stack_target found a crash where we may overflow ruring fee calculation if a transaction appears on-chain with massive value available for us to claim. Since these transactions are clearly bogus, we shouldn't allow full_stack_target to connect them, but we also improve the error generated by explicitly panicing on them.
Does someone running the test need to copy the hex into a file?
Or will a failing fuzz test case produce such a file which then just needs to be copied? |
|
Right, previously if you found a failing test, you had to hexdump it and copy the (often huge) hex into the fuzz file's test case. Now you can just cp the file. |
Could you add documentation for this? Or -- if documentation for fuzzing currently doesn't exist -- open an issue? |
|
Done. #475 |
One cleanup to fuzz target infrastructure to make it easier to work with, one fix for a failing test.