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

[Chen Zhen]

zerofossilfuel,

  So you used the patch? Please be clear as the language is specific for patching or upgrading and in your initial post you stated that you upgraded. If you used the patch then an existing hook should not be the cause of the issue (although you can try the procedure if you choose since it only involves uninstalling 1 mod).

  Atm the only thing I can suggest is changing an existing memory_limit setting within the php files to 64M or 128M where it tries to set it to 32M (which may be too low in some circumstances). The lower setting may override your current php.ini directive (256M) and may not be enough memory for the task at hand. Specifically in this case at the start of the function within Subs.php that is currently causing an issue you can attempt to change or add a memory limit setting which will override a possible previously triggered lower setting from another function. Imo 256M is not really necessary therefore try 128M.  It's just a suggestion as this would be my first course of action if I were having these issues and if it fails remove the edits & try something else that may be suggested here.

Code Select Expand


// This allows use to do delayed argument binding and bring in the replacement variables for some preg replacements.
function pregReplaceCurry($func, $arity)
{
        @ini_set('memory_limit', '128M');


... or whatever function is throwing the error. I can not be sure of the line number from Subs.php due to not testing it with just that 1 mod installed.

[Arantor]

Actually we've seen very specific (and *rare*) cases where 256M gets exhausted by that function. It originally came from the PHP manual discussions about dealing with the PHP 5.5 deprecation of /e, and has been part of SMF 2.1 for some months so it was assumed to have been safe to backport to 2.0, but apparently not.

[zerofossilfuel]

@Underdog, yes, I used "Patch" and only patch. Sorry if my wording caused any confusion.

I don't see how setting a 128M limit in your software is going to prevent it from exhausting 256M. Seems to me it's ignoring any internal limits. I will be leaving the code alone.

And for the record, I have had all mods removed for days now while I try to provide you clear information to help resolve this issue.

[power505]

Wow.w someone who reads the stickies!



Congrats. You are the first to figure it out without a pointed link.
On to the issue...
Let me guess... Your host is hosting24 or 000webhost....

In which case, they declare that you have a certain amount of memory, but, as far as I can tell, you do not actually have that much. Y only suggestion, if I am correct in my assumption of your host is - get a better host.

Let's get things straight here. I've run into an issue of not being able to install a specific package (on hosting24.com [nofollow]) via Package Manager and receiving the php error claiming that the limit of 32M is exceeded. Well, guess what, after some investigating (.htaccess and ini_set did not help) I came across these lines in the /Sources/Class-Package.php file:

Code Select Expand

// If we're using this try to get some more memory.
@ini_set('memory_limit', '32M');

Changing it to 128M fixed the issue. So, please, kindly do stop blaming the webhost for your own shortcomings and lack of knowledge of your own scripting. This is appalling. Make a master setting in the admin area or Settings.php to supersede all others, instead of re-defining the php memory limit inside your scripts. Hosting24 and 000webhost is not "choking" at 32 MB, get your facts straight. You can always use a test script to make sure that the webhost is providing the memory limit they declare with phpinfo():

Code Select Expand

<?php
// This is only an example, the numbers below will
// differ depending on your system

for ($i=1; $i<100; $i++) {
//echo "used memory is " . memory_get_usage() . "<br/>";
$a = loadmem($i); 
//echo "used memory after allocating ".$i."m is " . memory_get_usage() . "<br/>"; // 57960
//echo "used memory after unsetting allocated memory is " . memory_get_usage() . "<br/>"; // 36744
echo "You have allocated ". $i . "M (". memory_get_usage() . ") memory in this php script" . "<br />";
unset($a);
}

function loadmem($howmuchmeg) {
$a = str_repeat("0", $howmuchmeg * 1024 * 1024); // alocating 10 chars times million chars
return $a;
}

?>


If you're a hosting24 or 000webhost user, you'd see that this script returns a php "Allowed memory size of" error after the last iteration (which would be ~124MB and ~60MB respectively), which means that the limits are exactly what the hosting claims them to be. It would be kind of you to stop spreading disinformation. Thank you, I hope you escalate my findings, so that other users can swiftly resolve any php memory issues with SMF.

I have register here to confirm that this works for me. I'm on Hosting24.

[zerofossilfuel]

@power505 - Thank you for your post. I reverted the 3 scripts Host Gator had tinkered with (Admin.php, Class-Package.php, and Packages.php) back to default 32M memory limits then tried what you suggested. In Package Manager/Download Packages/Browse (/forum/index.php?action=admin;area=packages;get;sa=browse;server=1) if I click the first entry for New Features with 274 mods in that section I still get WSOD. If I click the 2nd entry for Feature Enhancement with 177 mods in that section it now works.

So, slight improvement but still needs work.

And yes, I did try 256M as well with the same result.

[Chen Zhen]

zerofossilfuel,

  What I meant was that where the default SMF files alter the memory for a particular script that is running it overrides the 256M php.ini setting. ( ref. http://ca1.php.net/ini_set )  Therefore I thought at the time this may be why the script crashes with a memory error and perhaps could be altered again at the point where you were getting the error. Of course another option would be to just remove those memory_limit overrides.



  Arantor's comment resulted in my looking more closely at the specific function that is throwing the memory error. You said SMF 2.06 worked fine and the issue is with v2.0.7 where that function that is throwing the error and has been changed (2 more functions also added). A preg_replace has been replaced with a preg_replace_callback function. So perhaps just putting back the previous use of preg_replace will solve your issue? The variables it uses do not seem to have been changed.

/Sources/Subs.php

find:

Code Select Expand


// Replace away!

// TODO: When SMF supports only PHP 5.3+, we can change this to "uses" keyword and simplify this.
$callback = pregReplaceCurry('smielyPregReplaceCallback', 2);
$message = preg_replace_callback($smileyPregSearch, $callback($smileyPregReplacements), $message);


replace with:

Code Select Expand


// Replace away!
$message = preg_replace($smileyPregSearch, 'isset($smileyPregReplacements[\'$1\']) ? $smileyPregReplacements[\'$1\'] : \'\'', $message);



... someone misspelled smiley? (smiely?)

[Arantor]

So perhaps just putting back the previous use of preg_replace will solve your issue?

Not really, no - and not the suggested change, at least not on its own. And certainly not long term.

The changes were made because preg_replace, as of PHP 5.5, deprecates the /e modifier. Even if you reinstate the old code (and you need to do it completely because $smileyPregSearch now doesn't have the /e part defined), that's only any good until the host upgrades to PHP 5.5 which is the current stable branch of PHP.

[Chen Zhen]

Arantor,

  Yes I see..  Atm I am reading the documentation regarding the /e modifier being deprecated in PHP 5.5 and a notice to use the callback function (PHP 4.0.5+) in its stead. For some people the changes to that function seem to be causing a memory issue albeit rare as you say. Is this SMF function (parsesmileys) being reworked to not cause this possible issue?

[Arantor]

If we could come up with a better replacement that fits, we would. The biggest problem is retaining variable scope as the callback function is carried out; in PHP 5.3 this wouldn't be a huge problem (since the (uses) function is available due to late binding) but there's still a lot of users and a lot of hosts on PHP < 5.3 as you've found yourself recently.

For 2.1 (where this code came from, when it was written some months ago), we are investigating a minimum requirement of 5.3+ but because of hosts that aren't current, we are a bit reluctant to enforce that at this time.

[zerofossilfuel]

I suppose I can try to "nudge" HG for a PHP upgrade. 

[JD_LFC]

Just incase this helps anyone.

Myself and users have been getting the intermittent white screen of death over the last couple of months - usually on topicseen pages but also after posting etc.  This error was leaving no trace in either SMF error logs or logs on the server (we use a dedicated server).

We have had APC installed on the server for a number of years.

Ultimately we turned off caching in the SMF settings and the problem went away straight away.  I spent far too much time on trying to identify this problem due to the lack of logging.

I'm actually unsure of what the Level 1, Level 2, Level 3 caching does when APC is already compiled on your server, but there is almost certainly something flaky about it.

[zerofossilfuel]

Here is what I just sent Host Gator. We'll see how they respond....

Okay, so I started posting as ZeroFossilFuel on this thread here....
www.simplemachinesdotorg/community/index.php?topic=502354.msg3661234#msg3661234
The developers would prefer to blame the host any chance they get but they can't dodge this one. The problem seems to center around PHP 5.5.x and certain changes to SMF that they back ported from SMF 2.1.x to 2.0.7 to handle it. Unfortunately that seems to break some things with older versions of PHP.

Having said that, PHP 5.2.17 really is quite old (.17 patch released Jan 6, 2011, 5.2.0 released Nov 2, 2006!) and I probably would not have had any problems if the server had at least 5.3.x. Any chance we can get something more current?

[Arantor]

If only that was what I said, which it wasn't.

Let me reiterate:
* We backported stuff from 2.1 to 2.0.7 for PHP 5.5 compatibility, stuff written months ago by people who have since left the team.
* This code works on all versions of PHP but has bugs where it ends up using far more memory than it should.
* Using 5.2 or 5.3 will make no difference.
* A better fix could be deployed if we were certain that the majority of users were on 5.3+.
* A surprising amount of the time it actually is the host's configuration that causes problems, but it's easy to blame the software, just as it's easy to blame the host. But I'm quite willing to make changes to accommodate things - if I have some idea of what I'm supposed to do. Too many times we've had issues with GoDaddy and HostGator's configuration and they refuse to talk to us about fixing stuff, especially where mod_security is concerned.

[zerofossilfuel]

Thank you for that clarification. To be fair, I found HG to be quite flexible about the mod_security issue. I needed it just to open the admin in SMF and once I demonstrated that they complied with my request. I actually hope I can get them to chime in here to open a meaningful dialogue with you.

[Arantor]

Judging by past experience I wouldn't bet on it. For the record I'm not denying there are issues with 2.0.7 but I can't fix them reliably at this time. I find it very unpleasant that people are being disingenuous about us, it's the one thing I hate most about developing for this community.

[zerofossilfuel]

Can't we all just get along? 

[Arantor]

Not when people are edging towards being slanderous, no. Not when I put in more hours per week to a volunteer project than most people put to their paid job only to get hassle for it.

[Burt]

Judging by past experience I wouldn't bet on it. For the record I'm not denying there are issues with 2.0.7 but I can't fix them reliably at this time. I find it very unpleasant that people are being disingenuous about us, it's the one thing I hate most about developing for this community.

hello Sir Cumber-Patcher (SCP)

I do appreciate the amount of works that most people put in offering "Free Software" such as SMF. I believe, this is one of the greatest asset that we have in Internet today. I always tell my friends that, "if you don't like what this or that software does or the way it is written", just take your business elsewhere, please. Your work SCP, it is appreciated here and I wouldn't take it that personally. 

Now I hope you don't mind but I do have a question.

I am one of those SMF user that has been affected by the latest 2.0.7 version. I got the WSOD in the "Browse Packages" page, some mods have stop working and other little nibble. So I reverted back to 2.0.6 that has no apparent problem to me or for the over 80 mods that I use. Please understand that I'm more than happy to remove or delete a mod if it is a cause of problem or concern. But considering that these mods have been working flawless since version 2.0.4, I doubt. Now, since you just mentioned above that there are "issues" with 2.0.7, do you think it would be wise for me and all other SMF version 2.0.6 user here to wait till 2.0.8 maybe it's release or we must go trough 2.0.7 ?

Please understand, that I'm not questioning the reasons of why, but merely asking an advice or suggestion on what to do next.

Thank You SCP for your time

Burt

[Arantor]

*shrug* I asked to leave the team today, I simply cannot deal with the hassle of trying to contribute to this community. I'd suggest removing 2.0.7 until someone fixes 2.0.7 because quite frankly I don't have the energy to do it.

[Burt]

*shrug* I asked to leave the team today, I simply cannot deal with the hassle of trying to contribute to this community. I'd suggest removing 2.0.7 until someone fixes 2.0.7 because quite frankly I don't have the energy to do it.

Thank you...

I'll wait then... I have full confidence in you...

Burt

PS

For what is worth it, I hope you are joking, regarding quitting the team today....