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

Reply via email to