128M is default in PHP 5. Did you use an old PHP 4 config file?

I moved the post to feature requests, it's not a bug.

I ran a clean install of Ubunutu 9.10, and then used apt-get to install apache2 and php5. I did not change any defaults on anything -- the default was 16M.

I solved it by overriding the default in my apache2 configuration and restarting the server.

My point is that if the install requires a certain amount of memory then it would be helpful (and pretty easy) to indicate that on one of the install screens prior to crashing, regardless of what the defaults are in PHP5.

I agree, there must be a check for memory and some functions that might be disabled in PHP.

Do you guys want to add those necessary checks at the begining of the install script?

fplanque wrote:

Do you guys want to add those necessary checks at the begining of the install script?

Seems like the reasonable place to put it.

Yep I know, but do you want to implement that and contribute your code? ;)

Where is the CVS (or SVN?) info so that I can connect to the repository?

Is there documentation for the development process somewhere? I assume you don't random people off the street just sticking code into the stream without someone sanity checking it first...

EDIT: Nevermind -- I found the CVS info to connect on sourceforge. I'm finishing up a plugin right now (just needs some more testing and code cleanup). Once that's done I'll I tinker with getting a sourceforge account and connected to CVS. Might be a bit of a delay, though, because work has been busy recently and I've got a couple business trips coming up.

As requested, I've checked out the CVS branch as anonymous and made the change in install.php. The fast version is that I reused the existing function in _system.funcs.php to check the memory and die() if it's below 20M (my testing said that 16M crashes and 20M works), similarly to how the code checks PHP and MySQL versions.

How do I go about getting permissions to check it into CVS? Is there a code review process or something?

Can you post it here for review? As for CVS access you may want to contact fplanque http://sourceforge.net/sendmessage.php?touser=805651

I'll send him a message.

The change consists of two parts:

1. An include statement near the beginning of /install/index.php to pull in the code already existing to check the maximum memory (system_check_memory_limit).

// Include system functions
include("../inc/tools/model/_system.funcs.php");

2. The code to check the memory and die if there isn't enough. I came up with 20M through trial-and-error on a 64bit Ubuntu system. The check and die() statement are modeled after the existing ones for MySQL and PHP version.

I put it immediately after the code to check the PHP version because it makes sense to check the version before the settings.

// Check sufficient memory allocated in PHP
$MAX_MEMORY = system_check_memory_limit();
$REQUIRED_MEMORY = 20480;
$REQUIRED_MEMORY_FRIENDLY = "20M";
if ( $MAX_MEMORY < $REQUIRED_MEMORY )
{
    die ('<div class="error"><p class="error"><strong>' . sprintf(T_('The minimum PHP memory requirement for this version of b2evolution is %d (%s), but you only have %d!'), $REQUIRED_MEMORY, $REQUIRED_MEMORY_FRIENDLY, $MAX_MEMORY) . '</strong></p></div>');
}

spiceygas2, yes please contact me with your sourceforge ID so I can open permissions for you.

http://b2evolution.net/contact/?recipient_id=1

Thanks.

Do you think that 30Mo is OK to run b2evolution 3.x ? and incoming 4.x ?

In my case the function system_check_memory_limit report that php can use 128Mo but the hosting limit it to 30Mo.

http://faq.1and1.com/scripting_languages_supported/php/9.html

I tested the install script on v4.0.0 with 20M and it worked fine, so 30M would be ok.

That said, I didn't do full regression testing on every feature. I can go back and spot check some of the bigger things.

I use 700M in my app to be able to convert huge PNG images into JPEG. It all depends on what you gonna do in your blog ;)

Francois, I've sent you two messages via sourceforge with no response. If you give me CVS access then I'm happy to add this guardrail to the install script, but if I don't get access then there's not a whole lot I can do.

Yes it definitely depends on what you're going to do. Image manipulation and plugins can consume a lot of RAM. But, nevertheless, there is a limit where we should warn users. I'm not sure what that limit is. It basically requires testing in live environments. I believe 32M should be enough for the vast majority of users.

I had to increase memory via my .htaccess file to 256MB after I updated the server to php 5.xxx

The problem only occured with b2's file manager in a large file area.