Picture attachment breaks thread

[jindroush]

When I attach certain valid jpgs to my forum, the thread page with post with pictures stops displaying, silently reporting http error 500.

There is nothing in error log, nothing in php error log. I played also with error reporting statements in index.php, settings in php.ini, settings in httpd.conf. I tried running script using php and/or php-cgi, to no avail. I'm getting 'nothing' instead of displaying of the thread posts. I spent several hours trying to get to the root of the cause, but I failed.

To "remedy" I can go to Attachment management and remove the offending jpgs, then the thread is "sane" again.

The two pictures are here:
https://www.dropbox.com/sh/jj4tfcb26a3ye01/AACy29IzVc4JXuPReWHcChdAa?dl=0
60336-5.jpg is okay, you can attach it. The moment when you attach the other one, IMG_0036a.jpg, the problem arises.
What I know: It's not the user, it's not the thread, it's not exif metadata, it's not filename. When I resize the picture to 4096x3072, the problem vanishes.


Running on Centos 7, PHP 5.4.16, httpd 2.4.6, mariadb 5.5.68, SMF 2.0.19

Forum is set to accept 5MB attachements, totaly 20MB per message. PHP is set to use 128MB. Tried 256, no change.
I'm out of ideas.

[Aleksi "Lex" Kilpinen]

My first guess would be that some PHP limit is reached, but this should also be logged in server error logs.
What are your post_max_size and upload_max_filesize?

[jindroush]

post_max_size = 21M
upload_max_filesize = 21M

But, still, these would (and did in the past) limit the uploads. But uploads are just fine, it's display which does not work and I can't find any 'limit' which would break that.
Could this be some image/GD processing bug? How to find out?

[Aleksi "Lex" Kilpinen]

True, but I wouldn't expect a couple of Mb to break memory limits either - that's why I just thought of other possible limits. In any case a white screen should be a logged error and that's what I would go after - if you can reach out to your host, unless you are self hosting, and ask about the missing log entry it might help.

[jindroush]

It's my own server, I'm root and I have access everywhere through ssh.
It's definitely not logged in error_log. There is 500 logged in access_log though.

[Arantor]

So the issue is that the images get uploaded and then don't have a thumbnail - and SMF is trying to remake the thumbnail and running out of memory.

Resizing down to 4096x3072 as you mention will only take around 60MB of RAM to process but I'm guessing from your comment that the original image will take more.

To work out how much memory resizing takes, you would start with the width times the height of the original, times 4 (because 4 bytes per pixel) times a memory efficiency factor of 1.2 (this is how I arrived at 60MB) and this is the minimum amount depending on what you're doing.

Sounds to me like you have some pretty big images - while developing my gallery years ago I was testing with images that were 6000x9000 pixels and needing to give PHP 300MB to let it work.

[jindroush]

So, I did some experiments:

1) When I create new post and I attach the 'bad' picture, I end up with 'empty' screen and post is not created at all.

2) When I EDIT post (with or without other attachments) and I attach the 'bad' picture, I end up with 'empty' screen, post is updated and when I visit the thread with the offending image in post, I end up always with 'empty' screen.

In this case when I check it, the 'bad' image is visible in attachment browser, but thumbnail is not. (I don't know when it's supposed to be created)

Tried to change php.ini memory limit to 256M, 512M, 1G, to no avail (restarted httpd, and verified it in phpinfo)

BTW: The images are available on Dropbox link in the first post, so anybody feeling adventurous enough...

[Arantor]

I'm on mobile so looking at Dropbox isn't going to help me. What are the dimensions of the images?

Also, I'm not being funny but I thought I explained when the thumbnails would normally get made: when you first upload then (but it fails safely) then on later attempts to view the thread (where it fails less gracefully trying to make then again)

Also do note that SMF will probably ignore your setting the PHP.ini settings - in its attempt to make room it asks for 256M - even if you gave it more in the ini file. Which is why it's important to understand the dimensions so the actual limit can be set.

There is a mod for dynamically allocating memory for this but I don't know if it's still maintained.

[jindroush]

The "good" picture is 5181x3163, 1.7MB
The "bad" picture is 5184x3888, 2MB

I tried to allow 1GB memory limit at the beginning of index.php (and same in php.ini, just in case), no difference. Not sure if I understand your note about the limits.

EDIT: Did some resizing test, it seems that last 'working' resize is 4846x3634. First nonworking is 4847x3636. Ie. limit is around 70MBs (x*y*4)

[Arantor]

The limit you set in PHP.ini is ignored by SMF when it comes to resizing pictures. You can set it to infinite memory and SMF will just reset it anyway.

Try installing https://custom.simplemachines.org/index.php?mod=4111

[jindroush]

I delved into Subs-Graphics.php, found thumb creation, checked resizeImageFile and there was setting of memory_limit to hardcoded 90MB. Tried doubling it, it works now for original image, so thank you for explaining why it happens, now it makes sense. It's bummer this doesn't get logged anywhere, but I assume PHP just dies on not enough memory without any chance of croaking into any log.

I saw in 2.1.x sources it's done differently, so maybe it's just 2.0.x bug (I'd say having hard limit and free input size is a bug, or design deficiency).

[Arantor]

If it's not being logged into the server error log, something is wrong with your setup.

[Oldiesmann]

A 500 error in the server error log should include further details about what specifically is causing that error, such as PHP running out of memory.