icu icon indicating copy to clipboard operation
icu copied to clipboard

ICU-23239 Limit fuzzer test data size to 64K bytes

Open FrankYFTang opened this issue 1 month ago • 7 comments

Avoid timeout on meaningless test

  • [X] Required: Issue filed: ICU-23239
  • [X] Required: The PR title must be prefixed with a JIRA Issue number. Example: "ICU-1234 Fix xyz"
  • [X] Required: Each commit message must be prefixed with a JIRA Issue number. Example: "ICU-1234 Fix xyz"
  • [ ] Issue accepted (done by Technical Committee after discussion)
  • [ ] Tests included, if applicable
  • [ ] API docs and/or User Guide docs changed or added, if applicable

FrankYFTang avatar Oct 22 '25 20:10 FrankYFTang

sorry, I am not ready for review yet. click on the wrong bug

FrankYFTang avatar Oct 24 '25 23:10 FrankYFTang

Hooray! The files in the branch are the same across the force-push. 😃

~ Your Friendly Jira-GitHub PR Checker Bot

sorry, I am not ready for review yet. click on the wrong bug

OK, I've now marked this PR as draft for you, so that you can click Ready for review when it is.

roubert avatar Oct 27 '25 15:10 roubert

This doesn't look right to me, there must surely be some way to configure the fuzzer to never generate more data than what is wished for, so that all that's needed here is a simple assertion that the data isn't larger than that, instead of having the fuzzer generate too much data and then throwing away the excess.

There is one: use option file *fuzzer.option file with max_len option However, as stated in https://github.com/google/oss-fuzz/blob/master/docs/getting-started/new_project_guide.md#input-size It is recommend to hard code that limit in .cpp file because some fuzzer engine won't hand that (see https://github.com/google/oss-fuzz/issues/1846 )

I change the PR to use the option file and that should work in libfuzz but won't work with other fuzzer. Do you prefer we use this way or rollback to the recommendated way I wrote before?

FrankYFTang avatar Oct 27 '25 20:10 FrankYFTang

I change the PR to use the option file and that should work in libfuzz but won't work with other fuzzer. Do you prefer we use this way or rollback to the recommendated way I wrote before?

This seems like a much better solution to me, but to be safe you might want to combine it with an assertion in the code that verifies that it really doesn't get more data than it should.

roubert avatar Oct 27 '25 21:10 roubert

I change the PR to use the option file and that should work in libfuzz but won't work with other fuzzer. Do you prefer we use this way or rollback to the recommendated way I wrote before?

This seems like a much better solution to me, but to be safe you might want to combine it with an assertion in the code that verifies that it really doesn't get more data than it should.

much better? but the documentation said it won't work!

I don't think it is a good idea to put the limit into two places . It is a known issue that other fuzzer will get more data and trigger the assertion. I do not think it is reasonable to add an assertion for a known issue which we know it will break.

FrankYFTang avatar Oct 27 '25 21:10 FrankYFTang

@roubert ping

FrankYFTang avatar Oct 30 '25 22:10 FrankYFTang