Address frequent oss-fuzz error: byte index <n> is not a char boundary; it is inside
richkadel opened this issue · comments
json5format is intended to support JSON5 documents with UTF-8 encoding, but oss-fuzz tests indicate there is a problem with unicode characters in some situations. See for example:
@DavidKorczynski - I'm finally getting around to fixing errors produced by oss-fuzz.
The frequency of generated bug reports by oss-fuzz increased significantly in the last month or so, I think.
Now I have over 125 bugs in monorail:
https://bugs.chromium.org/p/oss-fuzz/issues/list?sort=-reported&q=json5format&can=2
I suspect (fingers crossed) that the two PR's I have under review (#20 and #27) will address the majority of them.
Once those PRs land, is there a quick way to close all 125+ of the outstanding json5format oss-fuzz bugs?
On a related note, I added a "samples/fuzz_fails_fixed" directory to the repository. So far, I've only downloaded reproducer sample documents from 5 of the 125 bugs, but I chose different classes of errors, hoping that would address most of the oss-fuzz failures with the same fixes.
It would be nice to have a way to quickly and easily pull all of the reproducers into that directory without having to open up all 125 monorail pages, click the download link, and drag the file into VS Code or whatever. Is there a more automated way to do this in one step for all 125 of them?
Thanks @richkadel - I actually noticed this too and a few days ago I put up a tracker issue on OSS-Fuzz here: google/oss-fuzz#7040
The issue is essentially that deduplication is lacking in Rust atm. These duplicates should not happen.
Ok, thanks for letting me know. Hopefully the json5format fixes will reduce the new issues in the mean time.
The good news is that OSS fuzz is automatically closing the fuzz failure issues that I fixed in the merged PR. So the others should get closed after I can merge the new one as well, I assume.