imlib2 gif support is now mostly broken, as of giflib 5.1.2

likytau · 2016-02-13 12:08:10

I've verified this with multiple Imlib2 based apps, including sxiv, feh, and imlib2's own imlib2_view.
As imlib2 is no longer maintained, the imlib2 package for Arch will probably need to include a patch for this.

To that end I've posted this topic, to help figure out exactly what is the problem. I did a bit of testing and posted results
here. A quick summary of my findings: "Loading a gif fails. Loading one or more gifs after that gif succeeds. Loading a non-gif causes the next gif load to fail".

To me, this seems to point to an 'initialization' type bug: something in giflib now requires initialization where it didn't before.

Posters:
* Can you verify this experience (general gif brokenness with sxiv / feh / other imlib2 based programs)?
* Any idea what exactly is happening inside of giflib here? 'inexpensive sanity check in DGifSlurp' is the only thing that catches my eye in the NEWS file.

x33a · 2016-02-13 12:35:47

I don't have access to my Arch machine right now, I'll try to verify it in a couple of days.

Moving to "Applications and Desktop Environments".

pauper · 2016-02-13 15:46:00

That's pretty much in line with some odd behaviour I've seen in sxiv the last week or so. I have a script where sxiv displays some animated gif weather radars and a couple of jpeg webcam images in a slideshow. First time through one of the animated gifs fails and one works, from then on only the jpeg webcam images are displayed.

Vain · 2016-02-13 16:56:39

Have you tried building giflib's current git HEAD? From what I can tell, this appears to be fixed since giflib ef0cb9. The commit that broke stuff seems to be giflib b1ca661.

Note that the breaking commit checks for `Private->RunningBits > 32` and commit ef0cb9 initializes that memory to 0 after malloc'ing it. I've only read fragments of giflib's code, but this makes sense to me. I'd speculate that the bug only affects some GIF files.

likytau · 2016-02-13 23:17:07

@Vain:

Yep, looks like that fixes it (tested with sxiv, feh, imlib2_view).. So giflib's the basic problem -- are non-imlib2 apps affected? (I got some weird gif load results with GIMP the other day which suggest to me it's also affected, but that's just IIRC)

(since we don't have a giflib-git AUR package or similar that facilitates easy fixing here, I won't mark this as SOLVED until the next release of giflib comes out)

Last edited by likytau (2016-02-13 23:20:33)

ber_t · 2016-02-14 10:47:54

Maybe it's best to apply that patch to the ABS giflib package until the next release comes out.

Head_on_a_Stick · 2016-02-14 12:17:27

How about using the asp instead?

See https://bbs.archlinux.org/viewtopic.php?id=185075

Sounds_About · 2016-02-22 06:12:42

likytau wrote:

"Loading a gif fails. Loading one or more gifs after that gif succeeds. Loading a non-gif causes the next gif load to fail".

Not sure if you still need verification(s), but this has been happening to me in ranger file manager.

Arch Linux

#1 2016-02-13 12:08:10

imlib2 gif support is now mostly broken, as of giflib 5.1.2

#2 2016-02-13 12:35:47

Re: imlib2 gif support is now mostly broken, as of giflib 5.1.2

#3 2016-02-13 15:46:00

Re: imlib2 gif support is now mostly broken, as of giflib 5.1.2

#4 2016-02-13 16:56:39

Re: imlib2 gif support is now mostly broken, as of giflib 5.1.2

#5 2016-02-13 23:17:07

Re: imlib2 gif support is now mostly broken, as of giflib 5.1.2

#6 2016-02-14 10:47:54

Re: imlib2 gif support is now mostly broken, as of giflib 5.1.2

#7 2016-02-14 12:17:27

Re: imlib2 gif support is now mostly broken, as of giflib 5.1.2

#8 2016-02-22 06:12:42

Re: imlib2 gif support is now mostly broken, as of giflib 5.1.2

Board footer