|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2001-07-20 14:45 UTC] deets at web dot de
We encouter include() -problems on a large project. It
makes extensive use of classes and due to the fact that
session-vars need to have the class-definitions before
they can be used, some includes are circular. Of course
all include-files are encapsulated into if(defined("C")
{.. } blocks.
The included files before each weppage have a linecount at
a maximum of 6214.
The errors result in classes not known and thus
declaration of classes extended by them fail. Also
function-declarations sometimes are missing. When using a
while(!function_exists("f"))
{ include("f.php"); }
this results in timeouts because of endless loops. Of
course _should_ happen, because the constants mentioned
above are all correctly set.
The errors occur not fully predictabel, and normally
disappear when reloading the webpage.
In the apache-error-log appaer the following lines,
although I'm not sure if they are related to the problem:
[Fri Jul 20 16:01:34 2001] [alert] (14)Bad address:
FastCGI: openf() of fcgi_dynamic_mbox "(null)" failed
[Fri Jul 20 16:01:52 2001] [notice] child pid 13112 exit
signal Segmentation fault (11)
Any suggestions? Or is this project just too large for
PHP4?
./configure --with-apxs=/usr/sbin/apxs --with-gd
--with-curl=/tmp/curl-7.8 --with-oci8=/opt/oracle/OraHome1
--with-gettext=/usr/share --enable-sigchild
--with-dom=/usr/local/lib/
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Mon Dec 08 12:00:01 2025 UTC |
This didn't solve the problem. As I mentioned before, all include-files are encapsulated in if(!defined("C")){define("C")..} statements. I replaced all includes with include_once, and upgradet to 4.0.6, but this didn't help. The problems seems someway related to the process getting the request. Its very often the case that alternating requests result in an error. So every other requets works. This is even reproducable. On our live-system, the problem had been solved by setting display_errors = Off This seems to make things not only invisible, but actually work.