Issue with one specific forum thread HTTP Error 500 - Page 1
Forum section: electronics / general

author: DaJMasta
author_rank: Super Contributor
timestamp: January 17, 2017, 10:36:48 pm
content: 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.

author: neil t
author_rank: Regular Contributor
timestamp: January 17, 2017, 10:38:12 pm
content: yep it's doin it to me too.

author: DaJMasta
author_rank: Super Contributor
timestamp: January 17, 2017, 10:40:40 pm
content: 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

author: tautech
author_rank: Super Contributor
timestamp: January 17, 2017, 10:43:54 pm
content: Yep, link busted.

author: hans
author_rank: Super Contributor
timestamp: January 17, 2017, 10:44:30 pm
content: 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=1115499Went 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)

author: DaJMasta
author_rank: Super Contributor
timestamp: January 17, 2017, 10:55:00 pm
content: Quote from: hans on January 17, 2017, 10:44:30 pmYeah that does seem to work, strange.

author: Muttley Snickers
author_rank: Unknown
timestamp: January 17, 2017, 11:32:05 pm
content: 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.

author: Brumby
author_rank: Unknown
timestamp: January 18, 2017, 01:25:48 am
content: 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.

author: Zero999
author_rank: Super Contributor
timestamp: January 18, 2017, 06:16:30 pm
content: Quote from: hans on January 17, 2017, 10:44:30 pmYes. That's how I managed to reply to it.

author: EEVblog
author_rank: Unknown
timestamp: January 19, 2017, 10:21:44 pm
content: 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

author: gnif
author_rank: Unknown
timestamp: January 20, 2017, 12:46:31 am
content: 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.

author: Brumby
author_rank: Unknown
timestamp: January 20, 2017, 12:54:25 am
content: Quote from: gnif on January 20, 2017, 12:46:31 amSeriously?!!!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.

author: Marco
author_rank: Super Contributor
timestamp: January 20, 2017, 12:56:27 am
content: You blame users, I blame PHP coders.Neither will change, so these results are inevitable

author: Brumby
author_rank: Unknown
timestamp: January 20, 2017, 01:00:49 am
content: Quote from: wilfred on January 20, 2017, 12:55:17 amThere 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.

author: EEVblog
author_rank: Unknown
timestamp: January 20, 2017, 01:06:53 am
content: Quote from: wilfred on January 20, 2017, 12:55:17 amThere 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 futureThanks to gnif for solving this one

author: gnif
author_rank: Unknown
timestamp: January 20, 2017, 01:15:38 am
content: Ill see if I can put some limits in there, it is possible to determine the image size before trying to manipulate it (getimagesize).QuoteI 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?

author: Marco
author_rank: Super Contributor
timestamp: January 20, 2017, 01:27:26 am
content: Quote from: EEVblog on January 20, 2017, 01:06:53 amA 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.

author: gnif
author_rank: Unknown
timestamp: January 20, 2017, 01:55:24 am
content: QuoteOr 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.Quote from: wilfred on January 20, 2017, 01:28:49 amA 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.

author: gnif
author_rank: Unknown
timestamp: January 20, 2017, 01:59:41 am
content: Quote from: Brumby on January 20, 2017, 12:54:25 amThe 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.