Issue with one specific forum thread HTTP Error 500

[DaJMasta]

The strangest thing.... a thread in the projects forum, which a few days I even posted in, loads as a blank page in Firefox and an HTML Error 500 page in edge and on my phone in chrome (even on the cellular network).  This issue has persisted for a couple days, best I can tell.

https://www.eevblog.com/forum/projects/considerations-for-powered-vs-non-powered-microphone/

That's the thread in question, and I haven't noticed it on any others on the forum so far.  I seem no have no trouble viewing or posting in other threads.

Any ideas what could be going wrong?  Didn't see a site feedback/tech support area, but if this should be somewhere else it can certainly go there.

[neil t]

yep it's doin it to me too.

[DaJMasta]

For what it's worth, I know it's working for at least some people as there's been a new reply since yesterday when I first couldn't open it 

[tautech]

Yep, link busted.

[hans]

You could potentially read the thread this way:
https://www.eevblog.com/forum/projects/considerations-for-powered-vs-non-powered-microphone/msg1115499/?action=post;quote=1115499

Went to the last poster profile and 'quoted' his/her post directly from there.

Odd the page is blank. Probably a PHP internal server error which is muted due to security reasons (e.g. exposes server paths etc)

[DaJMasta]

You could potentially read the thread this way:
https://www.eevblog.com/forum/projects/considerations-for-powered-vs-non-powered-microphone/msg1115499/?action=post;quote=1115499

Went to the last poster profile and 'quoted' his/her post directly from there.

Odd the page is blank. Probably a PHP internal server error which is muted due to security reasons (e.g. exposes server paths etc)

Yeah that does seem to work, strange.

[Muttley Snickers]

Out of curiosity I used the above link which takes you to the last post in the thread in preparation for a reply, I replied and posted but then got bumped yet the reply went through and it didn't help at all in relation to access to the thread, I think we need help from above.     

[Brumby]

It's been a problem for me too.

Since the Reply dialogue seems to be working, I would hazard a guess that there is something in the data stream that causes problems when being fully rendered (the normal thread view mode).  I have encountered a couple of such quirks with SMF.

No idea on a fix, though.

[Zero999]

You could potentially read the thread this way:
https://www.eevblog.com/forum/projects/considerations-for-powered-vs-non-powered-microphone/msg1115499/?action=post;quote=1115499

Yes. That's how I managed to reply to it.

[EEVblog]

I presume just a single corrupted database table or something similar, I think that's happened before, in which case no big deal.
Hopefully not something systemic.
Running checks now...
All database tables OK. SMF maintenance found 4 threads with issues, all corrected.
Still doesn't work, so 

[gnif]

It's caused by someone posting huge images again... two images 15284x10284 in size each.

We are dealing with it now, but people need to realize that the server generates thumbnails from images uploaded, the file size on disk might be tiny due to compression, but to re-sample it for a thumbnail requires WxHx3 bytes of RAM just to load the image, in this instance 15284x10284x3 = 471541968B or 450MiB!

Even my local browser was choking on these images.

[Brumby]

It's caused by someone posting huge images again... two images 15284x10284 in size each.

Seriously?!!!

With a pixel size like that the compression to put it within the size limit of the forum has to make you wonder just how much detail has been sacrificed rendering the dimensions pointless.  They are simply unnecessarily obscene.

[Marco]

You blame users, I blame PHP coders.

Neither will change, so these results are inevitable

[Brumby]

I thought there was a limit to the size of attached images? Has that recently changed? Although I can't see changing it to allow hundreds of MB as likely.

There is a limit ... but consider this:

Have your huge ass image - 15284 x 10284 - then save it with very high compression.  Your image now fits within the forum limit - but it still has the 15284 x 10284 pixel dimensions.

To resample for the thumbnail, the forum software sets out a 15284 x 10284 work area and then rebuilds the image from the highly compressed data.  It then runs through this rebuilt image to get a thumbnail.

Jpeg compression will ensure each pixel is populated, but the pixel detail will be abysmal.

[EEVblog]

I thought there was a limit to the size of attached images? Has that recently changed? Although I can't see changing it to allow hundreds of MB as likely.

There is a file size limit, this is an issue with the size of the image in pixels.
I cannot set a maximum for this, only for the image preview under the past.
So I can't see how i can prevent this in the future 
Thanks to gnif for solving this one

[gnif]

Ill see if I can put some limits in there, it is possible to determine the image size before trying to manipulate it (getimagesize).

You blame users, I blame PHP coders.

I blame both, users should know better in this day and age, the image that was uploaded could have been no more then 1000px wide and still be completely legible, and those that do know this and still upload huge dimension images are just lazy. SMF preventing this kind of upload is preventing users from doing dumb things they should know better about in the first place.

SMF programmers should have put a width/height limit to uploaded images, but with the million other things that have to be considered during design, little things like this easily get overlooked and later fixed. And I wouldn't be so fast to blame PHP coders... this in reality is a minor issue in comparison with the issues that come out of other languages such as bufferover/under flows in C/C++, and improperly implemented security (ie, PS3 rand function). Remember that SMF is free open source software with pretty much no funding, if a company like Sony with millions of dollars can't get their flagship product's security correct the first time around, what chance does the average Joe in their spare time have?

[Marco]

So I can't see how i can prevent this in the future 

A couple hours worth of learning enough PHP to create one line of code to invoke imagemagicks to get the dimensions of the image and add it to the existing size rejection would do it. Then another couple of hours of heavy boozing to wipe the PHP knowledge from your mind.

[gnif]

A couple hours worth of learning enough PHP to create one line of code to invoke imagemagick...

Or 1/2 a second using PHP's native getimagesize function in GD, why people try to use imagemagik for this stuff I still dont know, command like shell exec, yuck.

SMF preventing this kind of upload is preventing users from doing dumb things they should know better about in the first place.

Maybe say that out load and see if it still sounds reasonable.

I'd start working on a fix before it isn't unintentional. And maybe stop people quoting images whilst you're at it. Just because duplicating images is unnecessary.

A fix is underway, I am aware of the potential abuse here, but honestly PHP is protecting the server by aborting when it tries to consume too much RAM, worst case is what we saw here, the post was inaccessible.

As for quoting images, that's quite an involved thing to fix, if you want that ask the SMF guys over on their forums for it, parsing text can be quite complex.

[gnif]

It's caused by someone posting huge images again... two images 15284x10284 in size each.

Seriously?!!!

With a pixel size like that the compression to put it within the size limit of the forum has to make you wonder just how much detail has been sacrificed rendering the dimensions pointless.  They are simply unnecessarily obscene.

The compression of a JPEG that is 99% white is extremely efficient, there is near to no quality loss to accomplish this. Honestly you could screw most image processing tools over by just forging the jpeg header width and height values with something obscene. Most if not all tools will try to allocate the buffer to decode into before trying to read the data and verify the image is actually valid, so you in theory could craft a 100 byte file that consumes gigabytes of memory.