Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

I looked at the instructions for backtrace. They do not translate to Win2000. I will install Cygwin and see if the instructions work with Win2000 Cygwin.

Our Unix systems have old releases of PHP and Apache so it might be a while before I can reproduce the test on Unix.

Sorry, I just mistook the platform is *nix.
As I can't reproduce this on my Linux box, this problem is likely to
be Windows specific.

Does Apache segfault when giving a non-existent file name to require_once()
rather than an array?

require_once();
Parse error: parse error, unexpected ')' in C:\webapps\display.php on line 10


require_once('');
Fatal error: main() [function.main]: Failed opening required '' (include_path='.;c:/include;c:/') in C:\webapps\display.php on line 10


require_once('cc');
Warning: main(cc) [function.main]: failed to create stream: No such file or directory in C:\webapps\display.php on line 10

Fatal error: main() [function.main]: Failed opening required 'cc' (include_path='.;c:/include;c:/') in C:\webapps\display.php on line 10



require_once(array('cc'));
Notice: Array to string conversion in C:\webapps\display.php on line 10

Warning: main(Array) [function.main]: failed to create stream: No such file or directory in C:\webapps\display.php on line 10

Fatal error: main() [function.main]: Failed opening required 'Array' (include_path='.;c:/include;c:/') in C:\webapps\display.php on line 10



The error does not occur when require_once() receives a simple non string. The error occured when the non string was an array of varied elements including other arrays and possibly objects. The error occured repeatedly until I found the offending assignment statement.

I tried to reproduce the error on the first require_once in the script but did not succeed. The original error was deep in a script with several requires and some requires including scripts containing requires. I have now changed the script to a less complicated set of requires and may not be able to reproduce the depth.

It is possible the crash was caused by the requires looping on themselves but that type of error usually requires a second or two before Apache runs out of memory (currently over 500 Mb free). The crashes were instant.

php.ini has nothing set to increase available memory or change safe mode or anything else. It runs as a module.

I found a new error causing the same error message from Apache 2. This error is from an XML processing loop. I think the Apache 2 error message must be issued any time Apache runs out of memory. Perhaps PHP is trampling over the end of it's memory allocation or something similar.

I will try a few more tests then increase PHP's memory allocation in php.ini and see if that fixes the problem.

memory_limit = 80M
in php.ini fixed the XML process error. It can now read the full XML file without blowing up Apache.

Has the change on memory_limit entry solved the require_once problem too?

The require_once error has not occurred when using 80Mb.

The original require structure ended up including every component in the system. I added a few if statements to include only those components required for the script. The original mess might have used up the default 8Mb of memory. My clean version probably uses less than 1 Mb for my code.

I am using the PHP binary compiled with all options. I think that comes to about 4 Mb. If that 4 Mb is loaded in to the default 8Mb when running PHP as a module then my original code would have easily used the remaining 4 Mb. Changing the allocation to 80Mb may have, in effect, increased available memory from 4 Mb to 76 Mb.

So what's the bug here? If you run out of memory, how can
that be a PHP bug? :)

When I opened the error report, I did not know the error could be deferred by adding more memory. Now that I know the extra memory defers the problem, I can allocate extra memory.

Allocating extra memory might not be practical for all people especially those with hosted sites where the ISP restricts php.ini changes.

Crashing Apache is also bad form. I know Apache 2 is considered new. Anything newer than Apache release 1.0.1 is too new for some people. A lot of people now use Apache 2 on production servers and PHP 4.3.0 must be bullet proof in that environment by now. 

I will upgrade to Apache 2.0.44 then test using just 8 Mb and see if the problem occurs. If someone out there knows of compatibility and stability issues with Apache 2, they might like to suggest the best release for use with PHP 4.3.0. I have downloads 2.0.39, 2.0.43, and 2.0.44.

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


There was some memorylimit crash fixed recently
so please try the snapshot.

Anyway, about apache2..it's REALLY not ready for 
production at ALL, especially with PHP.
Apache 1.3.27 is the best choice.

http://snaps.php.net/win32/php4-win32-STABLE-latest.zip 20020123 is working with just the default memory under Apache 2.0.44. Including stacks of files, using Expat, XML, and creating gazillions of objects. No errors so far.

Then closing this report...

If the same problem occurs again, please let us know via this page.

Thanks.