Memory size limit – works for me, not for client

[yellowled]

So today I got a looot of emails from a client's PW installation containing "out of memory" and "imagesizer". Since unfortunately the site is running on a rather crappy server, I thought "Damn, PHP mem size limit" (server has 90M). Turns out that wasn't it.

My client can not upload images using Safari/Mac or Firefox/Mac (still waiting to hear about the exact version numbers he used), he says the upload process stalls at 100% in Safari or 99% in Firefox. I can upload images just fine, however, using Chrome 18/Ubuntu or Firefox 14/Ubuntu. I also never ran into any memory limit messages building the site.

Any ideas as to why and how this is possible?

[Soma]

Just a random guess, as it can be many things.

He's uploading an .png image but with .jpg ending?

Another idea, can you access your clients computer remotely? Or maybe he's able to open a developer tool in his browser and take a look at if an error occurs on the ajax request (if it's ajax uploaded).

Oh, and there was an issue once where someone tried to upload images from a cloud directory or app, I think it turned out to be the problem. Anything is possible here.

Good luck!

Master of edits:

Isn't he really trying to upload a 10mb jpg ro something very large?

[yellowled]

I have copies of both images he tried to upload. Both are JPEG images:

1. 1281x680, 323 KB
   
2. 1280x854, 414 KB
   

So they're not even that large in dimensions or size.

As of now, the only difference I know of is that the client's working on a Mac, so the cloud directory/app theory might actually be a possibility.

[ryan]

Not really sure how to tell short of trying it myself, as I'm not aware of any issues with uploading, and I use a Mac all day long. It might be helpful to get a better look at those "out of memory" and "imagesizer" errors. Also, if you can take a closer look at the images and see what DPI and color space they are using? For instance, I've occasionally seen some strange things with PHP's GD functions when going into 300 dpi or CMYK images. If you want to send over the images and/or login info, I'll be happy to give it a go on my mac to see what happens.

[yellowled]

Unfortunately, I was "wise" enough to not save those error messages, but I can ask the client to reproduce the errors.

DPI: 72x72, RGB colorspace with sRGB IEC61966-2.1 color profile (Hewlett-Packard), they seem to come from the same digital camera. Due to the image dimensions, I would assume this is either a low-budget consumer camera or even a smartphone, but I don't know exactly. No EXIF data available.

Those look pretty normal to me. Besides, I used the exact same images and the upload went well …

[yellowled]

The error.txt has an older entry for a similar error:

Error Out of memory (allocated 52690944) (tried to allocate 21634200 bytes) (line 135 of /homepages/xx/xxxxxxxxx/htdocs/cms/wire/core/ImageSizer.php)

("x" denotes user data which might be sensible.)

[Soma]

Only reasonable to me seems there must be something client side that gets appended from the computer while uploading the file, on server it is too big or corrupt that will throw a memory (so he could be infected by some strange alien source maybe)

Is client uploading using drag and drop, can he try oldscool and see if it works? Can you send me an image?

[Soma]

The error.txt has an older entry for a similar error:

("x" denotes user data which might be sensible.)

That's the line where it tries to create a png image.

[yellowled]

The images are http://dl.dropbox.co...4/IMG_0067.jpeg and http://dl.dropbox.co...052012 074.jpeg

I don't know if he's using d'n'd or "old school" upload, but I've asked. Might take until tomorrow to get an answer given local time.

That's the line where it tries to create a png image.

But why would it try to create a png image if the uploaded file is a jpg image with jpeg suffix?

Edit: Im my ImageSizer.php, in line 137, it says

case 'jpg': $image = @imagecreatefromjpeg($source); break;

I wouldn't know how this is related to creating a png image …?

[yellowled]

Quoting and translating the client here: It doesn't make a difference whether he uses drag 'n' drop or classic upload, besides the fact that drag 'n' drop is "way cooler".

It's probably related to the particular images. He also stated that he tested it with different images in the meantime, and it worked, so the upload process in general seems to be fine.

[MarionRaven]

Your client might transmit a false mime-type. Can this yield trouble?

And he may lie to you - unconscious. Maybe he tries to upload a link rather than the actual image. Just an example.

Another idea. The real images are really big - to big. And his mail client is nice enough to scale them down if he he send them to you.

[MarionRaven]

I'm nearly sure now, that your client has a 16 Mega-Pixel Digi-Cam.

Search for agile-uploader if you want to mimic the e-mail-client-behaviour.

[ryan]

Another idea. The real images are really big - to big. And his mail client is nice enough to scale them down if he he send them to you.

That's a really good point. This would explain it all.

[yellowled]

That's a really good point. This would explain it all.

Usually, I would say "No", especially since he successfully managed to upload other images up to 2,5 MB in size in huge image dimensions. Then again there's the fact that I could upload images he couldn't upload, so this might indeed be the solution. I'll check that.

I am, however, pretty sure that whatever causes this issue, it's not related to PW, browser or OS. It has to be related to those specific images and/or the way he uploads them.

[Pete]

He's using the mouse left-handed - he should be using his right hand

Where's WillyC with his words of wisdom when you need him?

[yellowled]

Turns out Marions idea was right, the "real" original image dimensions were 4272 × 2848 – oh, and by the way, the forum is missing an animated smiley banging his head to a table.