Hi Salvatore, Yes, you are correct - commit 3191336c0708 fixed the issue. I like to use rebase to squash commits, so I must have squashed away the commit that is logged in oss-fuz. Cheers, Aaron
Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, October 27th, 2021 at 16:36, Salvatore Bonaccorso <car...@debian.org> wrote: > Hi Aaron, > > Thanks for the quick followup. > > On Wed, Oct 27, 2021 at 08:26:11PM +0000, Aaron Boxer wrote: > > > Hi Salvatore, > > > > This bug was fixed in April 2021, as you can see in > > > > https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33544 > > > > if you read the last few comments. It was fixed in commit > > > > 1d9086205a0e91fb6517ebb09b00af354431f468 > > > > Version 9.5 was just released this month, so the fix is there. > > > > Let me know if you have any other questions. > > Yes I have seen that in the oss-fuzz report. But: > > $ git clone https://github.com/GrokImageCompression/grok.git > > $ cd grok > > $ git show 1d9086205a0e91fb6517ebb09b00af354431f468 > > fatal: bad object 1d9086205a0e91fb6517ebb09b00af354431f468 > > There is no such commit in the upstream repository. > > Thus my best guess would be that the refactoring introducing more > > error handling in 3191336c0708 ("palette mapping: convert a few > > asserts to errors") is what possibly is meant to fix the issue? > > Regards, > > Salvatore