Do you get the "white screen of death" when accessing Admin or Package Installs?

[Arantor]

The white screen in admin for new category is a misconfiguration of mod_security... OR, something is seriously broken in your install.

[Kindred]

The WSOD in the admin or packages screen is due to bad hosts and memory issues.
We know of Hosting24 and 000webhost causing issues with that.

Issues with the Categories does seem to be mod_security related....
and the only host that we know of with that configuration is GoDaddy (who, so far, has refused to contact us, despite numerous attempts)

If you are using a host other than one of those, then please let us know who...

[margarett]

The memory limit associated for the script is 256M

I'm sorry, but that can't be true, and that is *exactly* what this topic is about... They say you have a certain limit (as you can check with phpinfo) but, in reality, you have far less memory available.

Just think about it for a moment. You have 256M. Those oversold servers are known to host *hundreds* if not thousands of accounts. Just do the math and think on the amount of memory necessary...
Of course not all clients have the same demand so it is possible to share. But that's a really high value. You are able to run SMF perfectly with 64M, if not 32M!

[kateydrop]

Hmm...strange,

This morning at another host I dl SMF just fine, created new boards, downloaded the 2.07 patch which this time had something in it so thats been added. I will ask about this memory.

I am going to write to my other host thats the problem.

Thanks!
K

[zerofossilfuel]

I'm on Host Gator Basic. Just upgraded from 2.0.6 to 2.0.7. Now get WSOD or "Oops, you're out of memory" when trying to browse new packages from the Package Manager / Downloads page. Reverting back to 2.0.6 and all is well again.

[Kindred]

Unlikely, since the 2.0.7 update did not touch anything in the package manager.
However, still,fairly obviously a host problem.

[zerofossilfuel]

You say unlikely. I say 100% repeatable. I have upgraded and regressed twice now. The problem follows the version number. I did find a php.ini file in my home directory and in that file the memory limit is set to 256MB. Clearly this is false. I either get a WSOD or this error...

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 771971 bytes) in /home2/********/public_html/forum/Sources/Class-Package.php on line 335

I have opened a support ticket with Host Gator that basically puts their feet to the fire and says "HEY! It says 256MB! Why am I limited to 32?"

[Kindred]

First... Because you are on shared hosting.scond, I would bet that it happens to you after installing ANY mod, not based on the upgrade package.

[Arantor]

Actually, I could see how the PHP 5.5 compatibility requirements we had to jump through could possibly cause this (there is a one line change in Class-Package)... the problem is, the way we used to do it was by far more efficient in memory terms but it causes errors in 5.5 and won't work at all in 5.6.

To explain... in THEORY it shouldn't be too much more, but it IS a problem. Let me show you the affected part of Class-Package.php:

Code Select Expand

// Turn the CDATAs back to normal text.
protected function _from_cdata($data)
{
// Get the HTML translation table and reverse it.
$trans_tbl = array_flip(get_html_translation_table(HTML_ENTITIES, ENT_QUOTES));

// Translate all the entities out.
$data = strtr(preg_replace_callback('~&#(\d{1,4});~', create_function('$m', 'return chr("$m[1]");'), $data), $trans_tbl);

return $this->trim ? trim($data) : $data;
}

If you're not familiar with what's going, let me explain. (It's only the callback line that was changed. Previously this was a preg_replace with /e which is forbidden in PHP 5.5+)

SMF needs reliable XML handling and it's never assumed SimpleXML or similar is available, so it's always done its own XML parsing, which is fine. Which is what the Class-Package file does.

_from_cdata is a method to grab the contents of a tag. Specifically, if you have a <search> or an <add> or anything like that, _from_cdata is what's going to process the innards. It's a bit complicated to explain how it's going to work but it does work.

The problem is, _from_cdata is going to create a new lambda function every time it's called. For suitably complex mods that could be a lot of times. Now, in theory, the memory use shouldn't be insane because it should only be a few KB at most per tag which shouldn't climb into the multiple MBs except with truly enormous mods. In other words, if you already had memory issues, or were very close to having memory issues, this will probably push you over the edge, so you'll just be marginally more likely than before. If you didn't have problems, the odds are still on your side that you won't have further issues.

[Kindred]

Interesting....

[zerofossilfuel]

Here is Host Gator's response to my issue.

Hello,

The memory setting on the server is correct. The problem is that the software for SMF is trying to set the value itself. Here is a list of all instances of it setting the memory (and overwriting the system settings):

[root@gator3119 /home2/mbrasche/public_html/forum/Sources]# grep -Rn "memory_limit" *
Admin.php:644: @ini_set('memory_limit', '32M');
Admin.php:729: @ini_set('memory_limit', '32');
Admin.php~:626: @ini_set('memory_limit', '32M');
Admin.php~:711: @ini_set('memory_limit', '128M');
Class-Package.php:72: @ini_set('memory_limit', '32M');
Class-Package.php~:72: @ini_set('memory_limit', '32M');
DumpDatabase.php:50: if (@ini_get('memory_limit') < 256)
DumpDatabase.php:51: @ini_set('memory_limit', '256M');
Packages.php:1550: @ini_set('memory_limit', '32M');
RepairBoards.php:52: @ini_set('memory_limit', '128M');
Reports.php:293: @ini_set('memory_limit', '256M');
Subs-Graphics.php:326: @ini_set('memory_limit', '90M');
Subs-Members.php:90: if (@ini_get('memory_limit') < 128)
Subs-Members.php:91: @ini_set('memory_limit', '128M');
Subs-Members.php~:90: if (@ini_get('memory_limit') < 128)
Subs-Members.php~:91: @ini_set('memory_limit', '128M');
Subs-Package.php:2445: // Windows doesn't seem to care about the memory_limit.
Subs-Package.php:2446: if (!empty($modSettings['package_disable_cache']) || ini_set('memory_limit', '128M') !== false || strpos(strtolower(PHP_OS), 'win') !== false)
Subs-Package.php:2466: if (!empty($modSettings['package_disable_cache']) || ini_set('memory_limit', '128M') !== false || strpos(strtolower(PHP_OS), 'win') !== false)

The first part is the file that the code is in, followed by the line number it is on, and then the code. Many of the code files have checks to only raise the limit if it is lower than the amount it will set to, but some do not. I've changed the limit in Admin.php, Class-Package.php, and Packages.php to 256M to match the system memory.

This has allowed the site to no longer give an error, but now it shows a blank white page. When checking the actual server log, though, I am seeing:

[26-Jan-2014 15:51:37] PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 7680 bytes) in /home2/********/public_html/forum/Sources/Subs.php(2533) : runtime-created function(11) : runtime-created function on line 1
[26-Jan-2014 15:52:16] PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 7680 bytes) in /home2/********/public_html/forum/Sources/Subs.php(2533) : runtime-created function(11) : runtime-created function on line 1

This indicates that the script is still going over even the 256 M limit that I've set in the code (to avoid it from overwriting the system limit). From that information, it does appear that this is an issue with the software. If the prior version does not use that amount of memory when it checks the repo, then the newer version looks to have a flaw where it can use too much memory. I recommend contacting the software developers to see if this is a known issue with this version [2.0.7] of SMF, or perhaps any addon that you've installed.

I wish we could help further, but unfortunately as the script is going over the 256 M limit (most likely erroneously), there is not much else that we can do; shared and reseller servers have that limit in place to protect the stability of the server as a whole and it is usually hard to hit unless something is malfunctioning.

Thank you very much for choosing HostGator.com [nofollow]! If you have any other questions or issues, please let us know and we will be happy to help. Have a great day!

Sincerely,

David M.
Linux Systems Administrator
HostGator.com LLC
http://support.hostgator.com/ [nofollow]


And for the record,  the ONLY addon I have installed not even being utilized yet is SMFAds.

[zerofossilfuel]

Well this thread certainly became quiet. Do we acknowledge a regression problem?

[kat]

Hostgator seem to be pulling your plonker, to some extent...

They claim that these files are setting memory.

Admin.php~:626: @ini_set('memory_limit', '32M');
Admin.php~:711: @ini_set('memory_limit', '128M');
Class-Package.php~:72: @ini_set('memory_limit', '32M');
Subs-Members.php~:90: if (@ini_get('memory_limit') < 128)
Subs-Members.php~:91: @ini_set('memory_limit', '128M');

Trust me, they're not. They don't do anything, if truth be known. They're backups.

DumpDatabase.php only ever gets used, when you try to backup the database. So, normally, that file's not even in use. Similar, with Reports.php.

Subs.php doesn't even call for any memory, from what I can tell. So, to me, it looks like Hostgator are spinning you a bit of a yarn.

'course, I could be wrong. But, it sure looks that way, to me.

[zerofossilfuel]

Well, perhaps they don't entirely understand the workings of the script and I am not qualified to dispute one way or the other. But, the fact remains that the log files do show attempts to exceed 256mb which is most definitely being called for by SMF.

[kat]

Well, you can see, for yourself, from that list you posted. The only file that seems to call for that much, is the database backup.

I have to confess that I'm not terribly au fait, with this stuff. But, that much seems pretty clear, to me. But, I could certainly be either missing something, or barking up a lamp-post, rather than a tree.

Sir Cumber will know infinitely more than I do, about this, though. So, probably best to wait for him to comment.

[Chen Zhen]

zerofossilfuel,

  I realize your host stated that the memory limit is set to 256M but imo why not run a check yourself to be sure.
Put the attached file in your main directory & access it by http://yoursite.com/php_info.php

Look under Core where it says memory_limit & make sure it is set to 256M as your host claims.

  Also I should mention someone else was recently having these same issues that was resolved by using the repair_settings tool to clear all hooks. I suggest uninstalling all your mods and then use the tool to remove all hooks. If you upgraded (as opposed to using the patch) the files from mods you had installed on v2.0.6 will still be in their place and hooks from any of those mods can still be triggered, loading their files & functions.  One of these functions could somehow cause an endless loop (for whatever reason) which will exhaust memory & crash.



Btw devs - why does the upgrade package not omit all hooks since it renders all mods uninstalled? Shouldn't that settings column be cleared of all data when using the upgrade package?

[kat]

Btw devs - why does the upgrade package not omit all hooks since it renders all mods uninstalled? Shouldn't that settings column be cleared of all data when using the upgrade package?

Out of curiosity, why would anyone going from v2.0.6 to v2.0.7 upgrade, rather than patch? Surely, that's the entire point of patching? When you upgrade, from an earlier version, you effectively uninstall all mods, anyway. So, I don't see a problem, unless I'm misunderstanding...

[Chen Zhen]

K@,

  zerofossilfuel stated that they upgraded. People in general have either option where upgrading may be necessary for reasons such as being overwhelmed with log errors due to improper manual parsing or perhaps they're forum was not functioning for the same reasons. You will have to ask an individual their reasoning for using the upgrade package as opposed to the patch if you are that curious and imo you will get various answers.

Regards.

[kat]

Yeah. But, there's often confusion about upgrading/updating/patching. In our documentation, now, we only use "upgrading" and "patching". But, of course, our members don't know that.

Maybe, by "Upgrading", he meant "Patching"?

Another thing, that REALLY doesn't help, is that when you want to go from 2.0.6 to 2.0.7 and don't do it via package manager, you might go to this page:

http://download.simplemachines.org

Is the patch there?

Curiously enough, no. It's not. You have to click on "Package Manager Updates". So, it's not terribly obvious, sadly (I've asked for that to be changed, but it's still what it is, unfortunately).

So, the term "Upgrading", in this context, COULD be misleading.

[zerofossilfuel]

My answer to the upgrade vs patch question is I'm a noob to running SMF behind the scenes. Upgrade is what I was made aware of as I poked through the forum package admin screens so that's what I used. If that's not the recommended method then, IMHO, it should not be offered as an option.

See the attached screen cap. I do indeed have 256MB memory limit.

Correction: I "applied the patch" from within package manager. And, "They" meaning Host Gator did not "upgrade" my install. Their "quick install" is still at 2.0.4. I applied all of the patches myself, 2.0.5, 2.0.6 and then 2.0.7.