|
|
Posted by comp.lang.php on 08/10/06 15:09
Andy Hassall wrote:
> On 7 Aug 2006 08:01:57 -0700, "comp.lang.php" <phillip.s.powell@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 :: andy@andyh.co.uk :: http://www.andyh.co.uk
> http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
Navigation:
[Reply to this message]
|