I feel if you run out of memory the file isn't created. Then drupal runs in a redirect loop.
I can't say if that's is a imageAPI bug or imagecache.

At least an exception should be thrown if running out of memory.


drewish’s picture

Status: Active » Postponed (maintainer needs more info)

can you explain how you'd get this to occur? when i run out of memory i just end up with no generated image and errors in watchdog.

doublejosh’s picture

I'm having the issue with a Redirect Loop as well. Oddly imagecache is able to create one size and not another...


And what's wacky is that both namespaces work with other images... it's just this one namespace with this one image.
But I imagine since I don't know why, it's with other images too.

doublejosh’s picture

Wanted to follow up...

Learned some idiosyncrasies of image resizing. We often think in terms of filesize, but when simple images with large pixel size (as in very few colors) are re-sized, the server side is storing each pixel and translating it during the re-size. So functionally a new "filesize" is established with different parameters regarding establishing your max script memory limit.


RobW’s picture

I'm having the same issue as #2. Doublejosh, can you explain a little further what you meant in your #3 post, and maybe point us in the right direction for avoiding that?

RobW’s picture

Status: Postponed (maintainer needs more info) » Active

I hope no one minds, I'm going to move this to active.

Currently I'm running
Drupal 6.16
Imagecache 6.x-1.6
ImageAPI GD2

My imagecaches use a scale and crop, then an additional crop.
The images coming in are ~1500px wide, variable height jpgs, ranging in size from 100k to 500k.
Resized to 570px, 350px, 300px, or 260px across jpgs.

Hosting on Dreamhost (blegh, for now) with a memory limit of 90mb.

A seemingly random smattering of images will fail / redirect loop, but only on certain imagecaches. The 570px across imagecache always succeeds.

I'm happy to provide any additional information about my setup if you think it will help.

RobW’s picture

Title: Running out of memory produce a loop redirect » Some Imagecaches producing a loop redirect. Memory limit problem?

Looks like there's good information in another issue, starting at this post:


Switching to png's was a workaround that was successful for me.

joeflateau’s picture

I had a problem like this (302 redirect loop for no apparent reason) and noticed this in my Reports > Recent Log Entries:

ImageCache already generating: sites/default/files/imagecache/120x120/imagecache_sample.png, Lock file: C:\Windows\Temp/120x120imagecache_sample.png.

What I did was change my Temp dir (Site Configuration > File System) to C:\inetpub\acquia-drupal\drupal\sites\training\temp, that fixed it for me.
(c:\inetpub\acquia-drupal\drupal is my install root.)

pmonjo’s picture

I had this problem too, some time ago. Remember what Imagecache says about memory limits: you need a lot of RAM memory, over 100MB. My problem was that I was trying to scale a huge image, which needed a lot of memory. My host provider kills any process that requests more memory than the maximum allowed (it is configured with FastCGI). The solution was to scale with GIMP the image previously, so that the size would be acceptable.

y24jds’s picture

Version: 6.x-1.0-alpha2 » 6.x-2.0-beta10
Category: bug » support

I just want to post what I saw on my production website just now and how I found a quick work around in case somebody needs this in the future!

I cleared my image cache's and then tried to hit my initial page. Unfortunately it loaded but with broken images all over the place. I quickly saw in the error log about the redirects and that is how I found this page. I think by this point my server had crashed.

I removed the temporary .jpg files in my case in /tmp and started the server again.

Through some trial and error I figured out that my main page had too many images and was spiking the memory utilization and my provider has a hard cap as well and apparently apache was crashing because it couldn't allocate more memory.

To quickly fix my website (which is basically an e-commerce site that sells a handlful of things) I went to pages with fewer images and let the cache rebuild them. On pages that I couldn't do that with I let it crash, copied the link directly to the cached image. I had to stop apache, remove any stranded temporary jpg files in /tmp, start the server and quickly hit that URL directly to the image that needed rebuilt.

I did this over and over again until I have now rebuild all images (don't forget if you are using ubercart, you will have ones specifically for the shopping cart, product pages, etc..). To do the shopping cart ones, I added a product to my cart one at a time, let the screen transfer to the shopping cart where it needed to display the picture, I let it build it, and then I hit back and added the next.

Basically this way I was able to stay under the simulteanous memory utilization that was crashing me.

I need to read the above info here more later about using GIMP. I'm not sure if that means I need to scale all of my pictures much lower before I even upload them or if GIMP is another plugin that handles image resizeing better with less memory.

Anyways - in the future, I'm not going to clear my caches. And if I do, I might build a script of some sort to just go out and request all URL's to my cached images one at a time to let them rebuild slowly.

ezra-g’s picture

Marked #959770: Bad redirect under certain conditions, which has some code improvement suggestions but no patch, as a duplicate.

ezra-g’s picture

Title: Some Imagecaches producing a loop redirect. Memory limit problem? » Some Imagecaches producing a loop redirect.
enzipher’s picture

I ran into the redirect issue which causes the image to not be created. I applied the code snippet bu BogdanN in #959770: Bad redirect under certain conditions and it fixed the redirect issue. Not sure why this is a support request. I understand this could be a memory issue but when there is a working solution (at least for some cases) I don't see why it can't be implemented. I might very well be overlooking something, but this issue has bothered me for a long time and it would be great to have it corrected.

Snippet: http://drupal.org/node/959770#comment-3969508

In hopes that this can be committed.


fizk’s picture

Category: support » bug
Issue tags: +ImageCache 2.x Todo

Marking as ImageCache 2.x Todo.

Posted by BogdanN on January 31, 2011 at 8:36am
The fix above should do the trick, but sometimes even it is not enough, as the script might simply bail out due to extreme server load. To finally put an end to the never-ending loop problems, modify _imagecache_cache and replace:

if (file_exists($lockfile)) {
watchdog('imagecache', 'ImageCache already generating: %dst, Lock file: %tmp.', array('%dst' => $dst, '%tmp' => $lockfile), WATCHDOG_NOTICE);
// 307 Temporary Redirect, to myself. Lets hope the image is done next time around.
header('Location: '. request_uri(), TRUE, 307);


if (file_exists($lockfile)) {
// prevent the loop for running more than 3 seconds. the pic will be created on the next request anyway, and by that time the server load would have dropped
if (time() - filemtime($lockfile) > 3) {
} else {
watchdog('imagecache', 'ImageCache already generating: %dst, Lock file: %tmp.', array('%dst' => $dst, '%tmp' => $lockfile), WATCHDOG_NOTICE);
// 307 Temporary Redirect, to myself. Lets hope the image is done next time around.
header('Location: '. request_uri(), TRUE, 307);
german.villacreces’s picture

I had this issue and in my case the problem was that an orphan temp file was just sitting there under /tmp, so ImageCache thought a file was already being generated, therefore creating the loop. The solution is simple, delete the file that is giving you the problem on your tmp folder and refresh the page so that ImageCache can generate it again. If the same thing happens, its probably because the image is too big to resize.

Hope it helps.