Presumably ImageMagick is being a little overzealous with the alpha channel...

From the server admin log:

November 6
21:03 Tim: switched GIFs to use Bitmap_ClientOnly (client-side scaling)
17:23 brion: restarting apache on srv47, seem smysteriously stuck
17:15 brion: setting $wgMaxAnimatedGifArea to 1 to prevent animated thumbnailing of GIFs for now, see if that helps
17:10 brion: river complaining of image scaler issues -- load spikes, depooling?

This is bad news and there were no followups in the log. I really hope this will be fixed soon.

Resolved.

Did you resolve it properly, or in a way that will lead to downtime in the near future?

(In reply to comment #4)

Did you resolve it properly, or in a way that will lead to downtime in the near
future?

I resolved it by turning GIF scaling back on, and setting $wgMaxAnimatedGifArea to its original value.

This won't lead to downtime in the near future, because Bitmap.php uses getImageArea() to find the area to compare with $wgMaxImageArea. In GIF.php, getImageArea() now returns width * height * frame count. This should stop long or big GIFs from being thumbnailed.

You mean for GIFs uploaded after r54284 was deployed? What about GIFs uploaded before that time?

(In reply to comment #6)

You mean for GIFs uploaded after r54284 was deployed? What about GIFs uploaded
before that time?

I don't follow – are you saying that the metadata won't have been generated for GIFs uploaded before that time? That's a good point, I hadn't thought of that. I could probably fix it, though.

Yes that's what I was saying, but the facts appear to be even worse than that. None of the 30k GIF files in enwiki have valid metadata.