0

I run a virtual pet website and we use the PHP GD Library to produce our Avatars and Pets. We have over a thousand users so far, and out of that only 3 users have had this issue. For each user though, it's the exact same issue.

Here is a screenshot of what these users see.

The majority of the images just show the "Broken Link" icon, but every once in awhile it starts to build the image and stops before finishing.

These are my attempts at fixing it:

  • Removed everything from the code other than taking an image and printing it out.
  • Placed the code on an entirely different Server by a different Host
  • Removed the Site from Cloudflare DNS servers to see if Cloudflare was causing it
  • Used JPEG images instead of PNGs

This is the information I have gathered thus far from these users:

  • Viewing our site through a proxy allows the images to load
  • Using a laptop from the same internet connection loaded the images successfully
  • Browsers either just output the broken link or say that the image contains errors and cannot be displayed.

And lastly, here is the code of the simple test image page I am using:

<?
$finalimage = imagecreatetruecolor(500,500);
$file = 'http://www.somesite.com/picture.jpg';
$layers = imagecreatefromjpeg($file);
imagecopy($finalimage, $layers, 0, 0, 0, 0, 500, 500);
imagedestroy($layers);

header("Content-type: image/jpeg");
imagejpeg($finalimage);
imagedestroy($finalimage);
?>
Tony Stark
  • 8,064
  • 8
  • 44
  • 63
Taylor Bryant
  • 1
  • 1
  • Is that really your test script? Because it makes no sense to send the Content-type of image/jpeg and then return an imagepng. – gview Jan 16 '13 at 08:17
  • Sorry, had it mixed up from when switching from png to jpeg. Edited it. – Taylor Bryant Jan 16 '13 at 08:19
  • Is there anything in your logs? Are you sure you aren't hitting memory limits? – gview Jan 16 '13 at 09:00
  • Nothing in the logs. And definitely not hitting the memory limit. – Taylor Bryant Jan 16 '13 at 09:05
  • Are you sure that you area also checking the php error log? If you absolutely can't find something on the serverside then it could be a client or network issue. One thing that is interesting is your comment on proxy servers fixing it. Perhaps you have a dns issue or broken dns for those users although it doesn't make sense why they'd have a broken issue. Could also be routing problems to your host, which might also explain the proxy fix. Somehow you have to get a test case person you can work with, I think. – gview Jan 16 '13 at 23:16
  • Yes. I checked the server's error_log and there was nothing relevant in there regarding the test image. I can't imagine it's a problem with the Host since it failed on two separate servers with two separate Hosts. Also, I had them double check after I edited the code to make sure it isn't a PNG issue, and with the exact code above this is what the user got: [Screenshot](https://dl.dropbox.com/u/102561601/SylS.png) – Taylor Bryant Jan 16 '13 at 23:45
  • Hmm, I just noticed something... the imagecopy is using an http wrapper. Is this an image on your site? Why are you referring to that using $file = 'http://www.somesite.com/picture.jpg'? Isn't this a file on your server? – gview Jan 17 '13 at 01:29
  • @gview Yes. I have tried it both ways to see if that could be it and the http wrapper is just my latest way. My actual image builder pages use direct links as you indicated in your comment. But both ways don't work for them. – Taylor Bryant Jan 17 '13 at 03:43
  • There is no way you want to use a link to a local file. That's simply adding overhead and potential issues. The last screenshot you provided where the image was half drawn lead me to question that aspect, due to the nature of the http wrappers and the fact that a network glitch could result in a half formed image. In short, it's not helpful when debugging to randomly change things without a hypothesis. You should also only change one thing at a time. – gview Jan 17 '13 at 21:13

2 Answers2

0

You have forgot the imagedestroy($finalimage); at the end, but I don't know if it will solve your problem

Epoc
  • 7,208
  • 8
  • 62
  • 66
  • Yes, but to save the server's memory, using `imagedestroy()` must be mandatory. – Epoc Jan 16 '13 at 08:22
  • Not really, when the script ends, the memory is garbage collected. – gview Jan 16 '13 at 08:24
  • @gview Then why imagedestroy exists ? – Epoc Jun 19 '13 at 09:23
  • If you had a script that was creating a number of different images and you wanted to try and save on memory, then imagedestroy() would make sense. It is not essential, and was not ultimately related to the issue which, as Taylor indicated, ultimately was traced to individual users who had Kaspersky AV loaded on their workstations. I'm not saying that imagedestroy() is a bad thing to use... it just wasn't related to the question, nor was it essential, nor was it a solution to the problem. – gview Jun 19 '13 at 19:18
  • Thanks for these precisions :) – Epoc Jun 21 '13 at 06:28
0

The issue for our users was using the Kaspersky anti-virus. They had to add our URL to the list of trusted sites under web security. After doing so, all images loaded fine.

Taylor Bryant
  • 1
  • 1