This cannot be implemented.
Use PHP memory limit.

I can't just use PHP Limit.. I need to be able to LIMIT the resources on Memory for other things (Perl, FrontPage, and other cgi programs)

I don't think this should be classified as a "bogus" bug. I ran into the same issue when using resource limits in cgiwrap, sbox, and a custom version of suexec that calls setrlimit(RLIMIT_AS, ...).

For some reason I can't determine, PHP refuses to parse POSTed CGI parameters from STDIN when the RLIMIT_AS value is less than 40 MB (on my machine), despite the fact that PHP itself never uses more than about 8 MB. If I raise the RLIMIT_AS value above 40 MB, it works with no trouble.

Perl CGI scripts do not have the same problem.

As with the previous poster, using PHP's built-in memory limit is not an option for me -- I'm allowing customers to run their own PHP scripts on shared servers, and the memory limit must be enforced at the OS level to prevent users from running system calls, etc., that exceed the limit. This issue is unfortunately preventing me from offering PHP to several thousand customers.

I hope that this bug can be reopened and fixed. I have spent several hours trying to figure out the cause of it in the hope that I could send a patch, but alas, I can't see where the problem is.

Please research about the error message
"premature end of script headers" also.

It seems this could be Change Request.

I have done some more investigation and found that the problem only occurs when PHP is compiled "--with-mm" (which is the Red Hat default).

If PHP is compiled without "mm" support, the problem does not happen (which is an acceptable workaround for me, and which should be useful for others who experience this problem).

I still do not quite understand why the original problem happens, though. I suspect that PHP is using mm to allocate a large chunk of shared memory (perhaps around 32 MB?), and that allocation somehow fails in a silent manner. Then PHP tries to use that memory to read the POSTed data on STDIN, which fails.

When this problem happens, I don't receive a "premature end of script headers" message or anything like that. PHP seems to work normally (in my limited testing) -- it is simply unable to see the POSTed data from the form. It acts as though the POSTed data was never sent (data sent by method GET works properly). I suspect if I tried some more extensive testing, I'd find that other parts of PHP that rely on mm memory allocation would fail under these circumstances, too (but I don't know what those are to be able to test specifics).

Anyway, I've found my workaround and am happy, but it does seem that something in the mm code isn't quite right to cause silent failures. It's possible that this problem (apparent silent failure when memory can't be allocated by mm) might also occur in other low-memory situations, too, and that the artificially imposed RLimit limitation perhaps just makes it extremely visible and repeatable.

If it helps others to test, this problem is easily duplicated by:

1. Set up Apache with the directive "RLimitMEM 20000000" (for example -- anything above 10 MB and below 40 MB shows the problem on my machine).

2. Compile PHP as a CGI "--with-mm" (I'm also using the rest of the default build options from the Red Hat 7.2 package; I suppose it's theoretically possible that those are affecting it, too -- if you can't duplicate, use the full-blown Red Hat build options).

3. Create a trivial test page that uses method POST to send data to any PHP script.

4. The PHP script will incorrectly act as if no parameters were POSTed.

5. Recompile PHP without the "--with-mm" line and the problem goes away.

Hope this is useful.

Since upgrading to the RedHat standard php-4.1.2-7.2.6 RPM version, I have found a much simpler test case demonstrating the problem.

From the command line:

-----

$ php -v
4.1.2
$ ulimit -v 30000
$ php -v
Content-type: text/html

PHP Fatal error:  Unable to start session mm module in Unknown on line 0

-----

This shows that PHP doesn't work properly when the memory RLIMIT is ~30 MB. This is a problem for people who use PHP in CGI mode in hosting environments with memory limits.

Again, this is related to the use of "--with-mm" when compiling. If PHP is compiled *without* the "--with-mm" line, the problem does not occur.

Hope this helps.

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".