Legacy ImageMagick Discussions Archive

I'm running a Phabricator instance at work, and one of the things it does behind the scenes is handle GIFs and such using Imagemagick. On Ubuntu 14.04, running Imagemagick 6.7.7.10, this all went smoothly. However, after upgrading to 16.04 and with it Imagemagick 6.8.9.9, images that previous were converted fine now fail. For example (this is me manually running an equivalent command to what Phabricator is trying and failing at, to make sure it wasn't just a limitation of my PHP settings):
The server VM in question is 32-bit, and previously was configured to use 2GB of RAM. I have increased this to 4GB, but this has not appeared to change the behaviour. Another Ubuntu 16.04 machine I have on hand, running a 64-bit install and with a full 16GB of RAM, does run this just fine, although on it I definitely don't notice a bump in RAM or swap usage enough to indicate this actually being a memory limitation.

I had checked with folks on the #ubuntu-server IRC channel and they couldn't puzzle it out and suggested I post on the Imagemagick forums, so here I am! I am very willing to provide any more details that might help figure this out and/or try further debugging strategies.

The image failing for me in the example above is http://www.reactiongifs.com/r/but-why.gif

ImageMagick is requesting memory for the color reduction algorithm and your system is denying the request. If you have the source ImageMagick, you can reduce the memory required by the color reduction algorithm by changing one or both of these defines in magick/quantize.c:
First, try a cache shift of 3. If that fails, try nodes in a list of 1024. If that fails, we're not sure what to do. We have not run into this problem before other than on an iPhone. We have a conditional define which bumps the cache shift to 3 for the iPhone.

Well how about that, a cache shift 3 (once I overrode the lintian errors; I was building using "apt-get source" and then debuild to create DEB packages to replace my currently installed versions) seems to have worked! I wonder why it previously hadn't required such intervention. Curiosity aside, it certainly seems to be working now, so thank you very much

As time has gone on, I have noticed this has not universally been resolved, despite escalating to using both a CacheShift of 3 and a NodesInAList of 1024. The changes seem to have made it better---not all GIFs fail---but many still do.

Chances are you have a limited stack size. Check with 'ulimit -a' and try increasing your stack size. Does that help?