Cannot Initialize new GD image stream (101)

Using the browse button to select and attach a local image file results in the error message "Cannot Initialize new GD image stream (101)" when attempting to preview or save an article. Any idea what's going on?

I came across this thread so started playing around with different sized images but - weirdly - small images also give a similar error (Cannot Initialize new GD image stream (102)) while larger images just seem to be ignored (i.e. the article preview works without throwing an error but the image isn't displayed).

If it's relevant, I see this listed under my DF installation's settings page:

GD Version bundled (2.0.34 compatible)

One last note, I've tried increasing the image settings on the config page (10x default values) but that didn't help.

I haven't heard of this problem since about v3.0 of Pro_News.

I have same GD on my dev system with PHP5.3, but this site is still on GD 2.0.28 with PHP4.4 so anything in that range should be good enough.

Are you just running running out of memory? Your default memory in php.ini can be anything from about 16MB up. Most hosts have moved it up to 32 or even 64MB or 128MB (my case for my dev system). [Value is shown in Admin > System Info > PHP Core under memory_limit]

If yours is still small then you should try increasing to say 32MB. But if it is already > 32MB then I wonder if it is related to this bug. It's on coppermine, but the fix is in the common code gd2.inc. Of course Nano's preferred fix from CVS may or may not work on 9.1.2.1, but my quick and dirty comment out the 32MB limit might.

I presume that you have tried with a number of images? There are a few that GD2 does seem to have issues with. You can always grab one from this site from a Pro_News article and try that, as I must have uploaded it once upon a time. Other thing is to look in uploads folder to see if the image file got uploaded there. It will have a different name (for security). While you are there also check permissions?

Finally try with a fresh article and image - just in case something went wrong on the first attempt and left some sort of debris on server or browser cache.

Thank you, layingback.

Memory limit is 24M (which I'm guessing should be sufficient) so I'll look into the coppermine bug and report back.

Commenting out line 22 in gd2.inc doesn't appear to have made any difference, I'll try a fresh image from here and also check the uploads folder as suggested next.

No joy with a .png image grabbed from here (I'd previously tried various jpegs from my own machine) - same error. Nothing in the uploads folder apart from info.txt - can you confirm what the permissions should be on that folder?

Follows DF convention, there should be an info.txt file in the folder. Contents read:

chmod this directory 755 (777 on some systems) to allow image uploads.

I've never need to change it from the initial copy to server, but I guess some hosts may not honour the original setting.

The "coppermine bug" doesn't kick in unless memory_limit is > 32MB, so at 24MB no change is required. 24MB should be enough for most images.

Have you used the user side of Pro_News yet? I.e Submit_News (Pro_News&mode=submit). Could you try creating an article there with an image and see if you get the same/similar error, please? If you are still logged in as an admin then it should approve the article automatically, otherwise you'll have to go into admin side to approve or view it. And if it works there, then retry under admin and it may work.

Reason I think the above might work is that I've found a possible small bug in admin_functions.php. The function admin_img does not have $db and $prefix in globals. This would mean that if pnsettings was not in cache it would not get pulled in. Normally this would never occur, because the user side (run time) part of Pro_News would have already initialised it, but in your case perhaps not ...

- layingback

Follows DF convention, there should be an info.txt file in the folder. Contents read:

chmod this directory 755 (777 on some systems) to allow image uploads.

LOL - so, the answer to my question was actually in front of me already, sorry

I'll check the folder permissions and also run through your other suggestions shortly (need to grab a bite to eat first!) You're correct in assuming that I haven't run anything from the user side yet, though, so perhaps that's it...

Great, got it - the uploads directory required 777 (rather than 755) permissions.

With the permissions set correctly I can now upload images up to around 1MB reliably but something a little screwy seems to be happening over that size. Images over that limit are being uploaded to the uploads directory but frequently what happens is that previewing/saving the article either results in a blank screen with what looks like a few characters of gobbledegook or the article is displayed without the photo. However, sometimes it does seem to work and files over 1MB are being uploaded and associated with an article correctly. I'm guessing this is probably a memory issue - I'll look into it further and let you know what I find.

After some further testing I'm coming to the conclusion that it's not memory related, it seems to be based on image dimensions.

Layingback, are you aware of image dimension limits for uploaded images (either in Pro_News or code which Pro_News uses) which might be coming into play here? I've tried increasing the Max Image Dimension value in Image Settings under Config but it didn't have an effect.

Well I'm glad that's working. Never heard of a need for 777 before but clearly that advice is there for a reason.

I'm aware of no limit on image dimension. Even Max Image Dimension is only a resizing limit, ie the image should still be there, just smaller than the uploaded one.

But what are your Max Thumbnail sizes? If these are set too high, the total memory need while doing the conversion can become an issue. Remember in that 24MB (in your case) you have to get the code, and there is a lot of Pro_News code, the working space, the uploaded image, probable a transfer buffer, a copy of it, a thumbnail and an icon sized image, plus an image sized background and whatever workspace GD needs for the alpha blending!

You may want to try setting to 32MB in php.ini if you can (ie if your host permits). I used to have lots of trouble with clients with small memory sizes in php.ini, but that has diminished now that most hosts are at 64MB or even 128MB.

Couple of other things to consider: as noted in Config page, adjusting max thumbnail size after creating some articles with images can lead to screwy displays (it assumes there is a thumbnail when there isn't and vice versa). Also some articles may expect images which aren't present due to the write errors. I'd be tempted to delete the test articles you have, empty the upload directory manually, up the php.ini limit to 32MB if you can and start over clean ...

(Only way I can think for gobbledygook to be displayed in place of an image is that the image file did not get written completely, ie a memory limit encountered.)

Sorry about the trouble, but this is an area which was originally troublesome and has been reworked 3 times, but has been issue free for a couple of years, so has been a bit of a memory test on this side!

Thanks again for the detailed reply.

I've increased the memory limit to 32M and used fresh articles but still seeing the same problem. Max thumbnail width and height are unchanged from the defaults of 200.

I'll do a little bit of further testing either tonight or tomorrow to see if I can narrow the problem down further.

OK, I know this sounds weird but I've narrowed it down to the following:

- Images with a height up to 2163 pixels upload fine (when I say they upload fine, I mean I'm able to successfully preview or save an article with such an image attached).

- Images with a height of 2164 pixels or more produce a completely blank page with the "text" I'm attaching to this post appearing in the upper left hand corner when I try to preview or save the article. I'm using Firefox 5.0.

I'm certain that it's a pixel height issue rather than a file size issue - can you replicate the above?