Re: libnsgif and memory bombs

That's great, thanks Michael. I'll remove my patch and update from your repo.

On Mon, 5 Apr 2021 at 14:51, Michael Drake
<michael.drake@codethink.co.uk> wrote:
>
> Hi John,
>
> Thanks for the patch. It is an improvement and I've applied it.
> I'm currently considering moving the call to gif_initialise_sprite
> into gif_decode_frame so that the bitmap area is always created
> when a client calls gif_decode_frame. At the moment it will only
> happen for the first frame that is to be displayed, which is a
> change in behavior.
>
> I've fixed decode_gif.c to consult the display flag.
>
> By the way, your patch had tabs for indent, but that file
> (inexplicably) uses spaces. I changed the patch to use
> spaces to match but I plan to convert the whole file to
> tabs soon.
>
> Best regards,
> Michael
>
>
> On 03/04/2021 12:33, jcupitt@gmail.com wrote:
> > Here's a better version of the patch:
> >
> > https://github.com/libvips/libvips/blob/master/libvips/foreign/libnsgif/patches/delay-alloc.patch
> >
> > (removes a stray create_bitmap call)
> >
> >
> > On Fri, 2 Apr 2021 at 11:58, <jcupitt@gmail.com> wrote:
> >>
> >> Hi all,
> >>
> >> I had a thought regarding memory allocation in libnsgif.
> >>
> >> At the moment, calling `gif_initialise()` will parse the GIF file and
> >> allocate memory for rendering. You then call gif_decode_frame() to
> >> decompress and render each frame of the animation.
> >>
> >> However, this means just opening the GIF can trigger very large memory
> >> allocations, with no chance for the caller to intervene, except by
> >> putting a hard pixel limit into the bitmap_create() callback. For
> >> example, a 20 byte GIF can cause a 17gb malloc.
> >>
> >> How about delaying the allocation of the bitmap until the first call
> >> to gif_decode_frame()? This would allow the caller to check the
> >> detected width and height and apply some kind of size policy before
> >> allowing rendering to occur.
> >>
> >> Here's a possible patch that does this. It's very simple and does not
> >> affect the API, just the memory behaviour (I think):
> >>
> >> https://github.com/libvips/libvips/commit/9bdf5e8cda3e0c63584984282b1e36d97c50bb1a
> >>
> >> John
> > _______________________________________________
> > netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
> > To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
> >
>
> --
> Michael Drake https://www.codethink.co.uk/
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org