imagecreatetruecolor sometimes causes forced-download of index.php for some JPEG images

[comp.lang.php]

index.php:

[PHP]
// STUFF
// STEP 1: imagecreatetruecolor ONLY IF GD 2.0+ SUPPORTED AND FOUND
if ($this->isSuccessful && !$hasMogrified && $image && !$newImage &&
function_exists('imagecreatetruecolor') && preg_match('/2\.0/i',
$this->gd_info_array[0])) {
$newImage = @imagecreatetruecolor($configArray['width'],
$configArray['height']);
if (!$newImage) {
$this->isSuccessful = false;
$this->setErrorArray(array('action' ='Could not seem to create
new image'));
}
}

[/PHP]

This block of code will sometimes, for reasons I just don't understand,
cause a forced-download of the entire index.php script! This is not
even a consistent issue inasmuch as this only happens to certain JPEG
images. I am completely unable to discern a pattern; it happens to
some JPEG images and not to others; furthermore, this behavior does not
occur in GIF or PNG images.

I am using PHP 4.3.9 with GD 2.0.1 in Linux RHEL 4.

Thanx
Phil

[Andy Hassall]

On 4 Aug 2006 09:22:45 -0700, "comp.lang.php" <ph**************@gmail.com>
wrote:

>index.php:

[PHP]
// STUFF
// STEP 1: imagecreatetruecolor ONLY IF GD 2.0+ SUPPORTED AND FOUND
if ($this->isSuccessful && !$hasMogrified && $image && !$newImage &&
function_exists('imagecreatetruecolor') && preg_match('/2\.0/i',
$this->gd_info_array[0])) {
$newImage = @imagecreatetruecolor($configArray['width'],
$configArray['height']);
if (!$newImage) {
$this->isSuccessful = false;
$this->setErrorArray(array('action' ='Could not seem to create
new image'));
}
}

[/PHP]

This block of code will sometimes, for reasons I just don't understand,
cause a forced-download of the entire index.php script! This is not
even a consistent issue inasmuch as this only happens to certain JPEG
images. I am completely unable to discern a pattern; it happens to
some JPEG images and not to others; furthermore, this behavior does not
occur in GIF or PNG images.

I am using PHP 4.3.9 with GD 2.0.1 in Linux RHEL 4.

There was probably an error in the script, so what comes out isn't image data.
Your first thing to do is check the actual output. Either download the data
it's offering and look at it with an editor, or temporarily change the
Content-type.

You also mention that the symptoms occur with specific JPEG images; can you
find some common factor in these images that is not in the other images?

Given the considerably higher compression ratio in JPEG vs. PNG and GIF -
since it's lossy it can reduce much further than the other two lossless formats
- then you have to also bear in mind that JPEGs decompress in memory into far
bigger images. Are you running out of memory (or exceeding the PHP memory_limit
setting?)

--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[comp.lang.php]

Actually I was wrong and found out the problem isn't
imagecreatetruecolor() but it happens to be imagecreatefromjpeg(),
again, only with certain JPEG images. There is nothing I could find
that distinguished one JPEG from another; they're all roughly the same
size, compression, having the same permissions, group and onwership,
all the same amount of color, all from the same CD source.

I thought it was exceeding of memory_limit, however, using
memory_get_usage() I am finding the memory allotted for use in the
script is far below memory_limit, however, it still "dies".

Phil

Andy Hassall wrote:

On 4 Aug 2006 09:22:45 -0700, "comp.lang.php" <ph**************@gmail.com>
wrote:

index.php:

[PHP]
// STUFF
// STEP 1: imagecreatetruecolor ONLY IF GD 2.0+ SUPPORTED AND FOUND
if ($this->isSuccessful && !$hasMogrified && $image && !$newImage &&
function_exists('imagecreatetruecolor') && preg_match('/2\.0/i',
$this->gd_info_array[0])) {
$newImage = @imagecreatetruecolor($configArray['width'],
$configArray['height']);
if (!$newImage) {
$this->isSuccessful = false;
$this->setErrorArray(array('action' ='Could not seem to create
new image'));
}
}

[/PHP]

This block of code will sometimes, for reasons I just don't understand,
cause a forced-download of the entire index.php script! This is not
even a consistent issue inasmuch as this only happens to certain JPEG
images. I am completely unable to discern a pattern; it happens to
some JPEG images and not to others; furthermore, this behavior does not
occur in GIF or PNG images.

I am using PHP 4.3.9 with GD 2.0.1 in Linux RHEL 4.

There was probably an error in the script, so what comes out isn't image data.
Your first thing to do is check the actual output. Either download the data
it's offering and look at it with an editor, or temporarily change the
Content-type.

You also mention that the symptoms occur with specific JPEG images; can you
find some common factor in these images that is not in the other images?

Given the considerably higher compression ratio in JPEG vs. PNG and GIF -
since it's lossy it can reduce much further than the other two lossless formats
- then you have to also bear in mind that JPEGs decompress in memory into far
bigger images. Are you running out of memory (or exceeding the PHP memory_limit
setting?)

--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[Rik]

comp.lang.php wrote:

Actually I was wrong and found out the problem isn't
imagecreatetruecolor() but it happens to be imagecreatefromjpeg(),
again, only with certain JPEG images. There is nothing I could find
that distinguished one JPEG from another; they're all roughly the same
size, compression, having the same permissions, group and onwership,
all the same amount of color, all from the same CD source.

I rather doubt it.
What if you halt the script directly after imagecreatefromjpeg()?

Grtz,
--
Rik Wasmus

[Andy Hassall]

On 4 Aug 2006 14:44:18 -0700, "comp.lang.php" <ph**************@gmail.com>
wrote:

>Actually I was wrong and found out the problem isn't
imagecreatetruecolor() but it happens to be imagecreatefromjpeg(),
again, only with certain JPEG images. There is nothing I could find
that distinguished one JPEG from another; they're all roughly the same
size, compression, having the same permissions, group and onwership,
all the same amount of color, all from the same CD source.

I thought it was exceeding of memory_limit, however, using
memory_get_usage() I am finding the memory allotted for use in the
script is far below memory_limit, however, it still "dies".

If imagecreatefromjpeg() is exhausting the memory you're not going to be able
to see it from memory_get_usage(); you'll be below the limit before the call,
and it'll die during the call - you won't be able to see it exceeding the limit
apart from the error message (you have turned error_reporting back up to E_ALL,
right?)

And next:

(1) What _is_ output by the script when it fails?

(2) Can you reduce it to a _minimal_ test script - sounds like it could go all
the way down to imagecreatefromjpeg() followed by imagejpeg() ?

(3) If you still can't work it out from there can you make available to the
group examples of (a) an image that fails and (b) a similar one that doesn't
fail?

--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[comp.lang.php]

Rik wrote:

comp.lang.php wrote:

Actually I was wrong and found out the problem isn't
imagecreatetruecolor() but it happens to be imagecreatefromjpeg(),
again, only with certain JPEG images. There is nothing I could find
that distinguished one JPEG from another; they're all roughly the same
size, compression, having the same permissions, group and onwership,
all the same amount of color, all from the same CD source.

I rather doubt it.
What if you halt the script directly after imagecreatefromjpeg()?

SImple. You get a prompt asking you to open and same "index.php" to
your browser.

Phil

>
Grtz,
--
Rik Wasmus

[comp.lang.php]

Andy Hassall wrote:

On 4 Aug 2006 14:44:18 -0700, "comp.lang.php" <ph**************@gmail.com>
wrote:

Actually I was wrong and found out the problem isn't
imagecreatetruecolor() but it happens to be imagecreatefromjpeg(),
again, only with certain JPEG images. There is nothing I could find
that distinguished one JPEG from another; they're all roughly the same
size, compression, having the same permissions, group and onwership,
all the same amount of color, all from the same CD source.

I thought it was exceeding of memory_limit, however, using
memory_get_usage() I am finding the memory allotted for use in the
script is far below memory_limit, however, it still "dies".

If imagecreatefromjpeg() is exhausting the memory you're not going to be able
to see it from memory_get_usage(); you'll be below the limit before the call,
and it'll die during the call - you won't be able to see it exceeding the limit
apart from the error message (you have turned error_reporting back up to E_ALL,
right?)

Yes, to no avail. It still forces you to download "index.php". There
is no error, no warning, nothing. PHP doesn't register any kind of
message whatseover; in fact, it sounds more like a segfault, in short,
*there is no PHP anymore*

>
And next:

(1) What _is_ output by the script when it fails?

Nothing. You're forced to download index.php

(2) Can you reduce it to a _minimal_ test script - sounds like it could go all
the way down to imagecreatefromjpeg() followed by imagejpeg() ?

It doesn't. It dies right at imagecreatefromjpeg() every time. Never
gets any further than that.

(3) If you still can't work it out from there can you make available to the
group examples of (a) an image that fails and (b) a similar one that doesn't
fail?

I don't have an immediate way of producing them publically; they're on
a government-protected server that's not open to the general public; I
would have to attach them here, which I don't think Google Groups
allows to do.

--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[Andy Hassall]

On 4 Aug 2006 15:12:05 -0700, "comp.lang.php" <ph**************@gmail.com>
wrote:

>Yes, to no avail. It still forces you to download "index.php". There
is no error, no warning, nothing. PHP doesn't register any kind of
message whatseover; in fact, it sounds more like a segfault, in short,
*there is no PHP anymore*

If there was a segfault there'd be a record of it in the Apache error log - is
there?

> (1) What _is_ output by the script when it fails?

Nothing. You're forced to download index.php

Then at least _something_ was output. Accept the download - how long is the
file you download? Is it zero-length or not?

> (2) Can you reduce it to a _minimal_ test script - sounds like it could go all
the way down to imagecreatefromjpeg() followed by imagejpeg() ?

It doesn't. It dies right at imagecreatefromjpeg() every time. Never
gets any further than that.

So you have reproduced the problem on a new minimal script containing only a
call to imagecreatefromjpeg() and nothing else?

What is memory_limit set to?
What are the properties of the JPEG file?

> (3) If you still can't work it out from there can you make available to the
group examples of (a) an image that fails and (b) a similar one that doesn't
fail?

I don't have an immediate way of producing them publically; they're on
a government-protected server that's not open to the general public; I
would have to attach them here, which I don't think Google Groups
allows to do.

You don't have another website you can put it on? Failing that you could email
one to me if you wanted and I could have a look to see if there's anything
strange about the JPEG, unless you're not allowed to distribute it.

--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[comp.lang.php]

Andy Hassall wrote:

On 4 Aug 2006 15:12:05 -0700, "comp.lang.php" <ph**************@gmail.com>
wrote:

Yes, to no avail. It still forces you to download "index.php". There
is no error, no warning, nothing. PHP doesn't register any kind of
message whatseover; in fact, it sounds more like a segfault, in short,
*there is no PHP anymore*

If there was a segfault there'd be a record of it in the Apache error log - is
there?

I will let you know; I was not given permission to view the Apache
error logs (yes of my own machine, it's the US government, nuff said)

>

(1) What _is_ output by the script when it fails?

Nothing. You're forced to download index.php

Then at least _something_ was output. Accept the download - how long is the
file you download? Is it zero-length or not?

It's the length of the original index.php that I wrote, script intact.
Not very safe.

(2) Can you reduce it to a _minimal_ test script - sounds like it could go all
the way down to imagecreatefromjpeg() followed by imagejpeg() ?

It doesn't. It dies right at imagecreatefromjpeg() every time. Never
gets any further than that.

So you have reproduced the problem on a new minimal script containing only a
call to imagecreatefromjpeg() and nothing else?

Yes, and the download is the script I created with
imagecreatefromjpeg() as well.

What is memory_limit set to?
What are the properties of the JPEG file?

memory_limit set to 8M (8mb)
Properites of the JPEG file are pretty standard AFAIK, I'm sending one
"good one" and one "bad one" to you

(3) If you still can't work it out from there can you make available to the
group examples of (a) an image that fails and (b) a similar one that doesn't
fail?

I don't have an immediate way of producing them publically; they're on
a government-protected server that's not open to the general public; I
would have to attach them here, which I don't think Google Groups
allows to do.

You don't have another website you can put it on? Failing that you could email
one to me if you wanted and I could have a look to see if there's anything
strange about the JPEG, unless you're not allowed to distribute it.

I emailed them to you; these are not private proprietary images they
are my own test images.

--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[Andy Hassall]

On 4 Aug 2006 16:06:19 -0700, "comp.lang.php" <ph**************@gmail.com>
wrote:

>Andy Hassall wrote:

>On 4 Aug 2006 15:12:05 -0700, "comp.lang.php" <ph**************@gmail.com>
wrote:

>>> (1) What _is_ output by the script when it fails?

Nothing. You're forced to download index.php

Then at least _something_ was output. Accept the download - how long is the
file you download? Is it zero-length or not?

It's the length of the original index.php that I wrote, script intact.
Not very safe.

That's worrying; even in fairly catastrophic failures that's not supposed to
happen.

> So you have reproduced the problem on a new minimal script containing only a
call to imagecreatefromjpeg() and nothing else?

Yes, and the download is the script I created with
imagecreatefromjpeg() as well.

> What is memory_limit set to?
What are the properties of the JPEG file?

memory_limit set to 8M (8mb)
Properites of the JPEG file are pretty standard AFAIK, I'm sending one
"good one" and one "bad one" to you

The images you sent appear to confirm that memory limit is at least part of
the issue; the smaller (good) image is quite small, whereas the larger (bad)
image is well over the 8M limit when decompressed. I've just tried it on PHP
5.1.2 with memory_limit set to 32M, and memory_get_usage() says that the memory
used immediately after imagecreatefromjpeg() is:

Memory usage: 9490728

This is a bit higher than I'd expect - the image is 1770x1100 so the
uncompressed image data would be somewhere in the region of 46728000 bytes (24
bit colour), or 62304000 (24 bit plus transparency/alpha channel).

--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[comp.lang.php]

Andy Hassall wrote:

On 4 Aug 2006 16:06:19 -0700, "comp.lang.php" <ph**************@gmail.com>
wrote:

Andy Hassall wrote:

On 4 Aug 2006 15:12:05 -0700, "comp.lang.php" <ph**************@gmail.com>
wrote:

(1) What _is_ output by the script when it fails?

Nothing. You're forced to download index.php

Then at least _something_ was output. Accept the download - how long is the
file you download? Is it zero-length or not?

It's the length of the original index.php that I wrote, script intact.
Not very safe.

That's worrying; even in fairly catastrophic failures that's not supposed to
happen.

I know.. what could be done to prevent that?

>

So you have reproduced the problem on a new minimal script containing only a
call to imagecreatefromjpeg() and nothing else?

Yes, and the download is the script I created with
imagecreatefromjpeg() as well.

What is memory_limit set to?
What are the properties of the JPEG file?

memory_limit set to 8M (8mb)
Properites of the JPEG file are pretty standard AFAIK, I'm sending one
"good one" and one "bad one" to you

The images you sent appear to confirm that memory limit is at least part of
the issue; the smaller (good) image is quite small, whereas the larger (bad)
image is well over the 8M limit when decompressed. I've just tried it on PHP
5.1.2 with memory_limit set to 32M, and memory_get_usage() says that the memory
used immediately after imagecreatefromjpeg() is:

Memory usage: 9490728

This is a bit higher than I'd expect - the image is 1770x1100 so the
uncompressed image data would be somewhere in the region of 46728000 bytes (24
bit colour), or 62304000 (24 bit plus transparency/alpha channel).

When I unfortunately increased memory (via ini_set()) the problem was
alleviated (although in the long run that's a really bad idea).. is
there a way to detect if the uncompressed image file size is over the
memory limit? When it's compressed you can't apparently tell.

Thanx

--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[Andy Hassall]

On 7 Aug 2006 08:01:57 -0700, "comp.lang.php" <ph**************@gmail.com>
wrote:

>Andy Hassall wrote:

> That's worrying; even in fairly catastrophic failures that's not supposed to
happen.

I know.. what could be done to prevent that?

You can't do anything to prevent it because it's not ever supposed to happen -
it is not the normal failure mode of PHP.

You have a severe problem in either the specific version of PHP you are
running, or somewhere else in your setup. I would expect a serious error
message to have appeared in the Apache error log.

You're unlikely to get any support from bugs.php.net either unless you upgrade
to a more recent version. You said earlier you're running 4.3.9, which is quite
old now. If you're running a stock 4.3.9 then that has several known security
problems - although it's possible you are running a patched version.

> The images you sent appear to confirm that memory limit is at least part of
the issue; the smaller (good) image is quite small, whereas the larger (bad)
image is well over the 8M limit when decompressed. I've just tried it on PHP
5.1.2 with memory_limit set to 32M, and memory_get_usage() says that the memory
used immediately after imagecreatefromjpeg() is:

Memory usage: 9490728

This is a bit higher than I'd expect - the image is 1770x1100 so the
uncompressed image data would be somewhere in the region of 46728000 bytes (24
bit colour), or 62304000 (24 bit plus transparency/alpha channel).

When I unfortunately increased memory (via ini_set()) the problem was
alleviated (although in the long run that's a really bad idea).. is
there a way to detect if the uncompressed image file size is over the
memory limit? When it's compressed you can't apparently tell.

You can use getimagesize() to get the height and width, multiply them together
to get number of pixels. It seems you then need to multiply that up by a factor
of 5 (rather than the 3 or 4 you may expect) to get an estimate of memory
usage. YMMV depending on GD version, possibly, since I can't account for the
extra byte per pixel in the first place.

--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[comp.lang.php]

Andy Hassall wrote:

On 7 Aug 2006 08:01:57 -0700, "comp.lang.php" <ph**************@gmail.com>
wrote:

Andy Hassall wrote:

That's worrying; even in fairly catastrophic failures that's not supposed to
happen.

I know.. what could be done to prevent that?

You can't do anything to prevent it because it's not ever supposed to happen -
it is not the normal failure mode of PHP.

You have a severe problem in either the specific version of PHP you are
running, or somewhere else in your setup. I would expect a serious error
message to have appeared in the Apache error log.

You're unlikely to get any support from bugs.php.net either unless you upgrade
to a more recent version. You said earlier you're running 4.3.9, which is quite
old now. If you're running a stock 4.3.9 then that has several known security
problems - although it's possible you are running a patched version.

That would be something to consider, unfortunately as I'm tasked to
design, develop and deploy a portable web application that is
compatible with PHP as early as 4.1.2 I doubt that will be doable.
I'll have to keep an eye on the 4.3.9 "feature" on the one machine,
however, and suggest an upgrade (this is the fed gov't, so expect an
upgrade in about 10,000 years)

>

The images you sent appear to confirm that memory limit is at least part of
the issue; the smaller (good) image is quite small, whereas the larger (bad)
image is well over the 8M limit when decompressed. I've just tried it on PHP
5.1.2 with memory_limit set to 32M, and memory_get_usage() says that the memory
used immediately after imagecreatefromjpeg() is:

Memory usage: 9490728

This is a bit higher than I'd expect - the image is 1770x1100 so the
uncompressed image data would be somewhere in the region of 46728000 bytes (24
bit colour), or 62304000 (24 bit plus transparency/alpha channel).

When I unfortunately increased memory (via ini_set()) the problem was
alleviated (although in the long run that's a really bad idea).. is
there a way to detect if the uncompressed image file size is over the
memory limit? When it's compressed you can't apparently tell.

You can use getimagesize() to get the height and width, multiply them together
to get number of pixels. It seems you then need to multiply that up by a factor
of 5 (rather than the 3 or 4 you may expect) to get an estimate of memory
usage. YMMV depending on GD version, possibly, since I can't account for the
extra byte per pixel in the first place.

Thanx, that did the trick!!

--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool