Everything

php

No error output?

php.internals

Marcus Bointon

20 years ago

I'm running a recent snap of 5.1 with apache 2.0.54 (from fink) and
MySQL 5.0.15 on OS X 10.4.2. For the last few days I've noticed that
I'm getting no error messages out at all, neither to the browser nor
to the server log. I have display_errors, log_errors and
log_startup_errors set to On, error_reporting set to E_ALL |
E_STRICT, but I'm seeing nothing on web output - a simple syntax
error results in a blank page, e.g.

<?php
sdfsdf
?>

gives a blank page and nothing in server log. It produces an expected
E_NOTICE error on a CLI version, so the problem is either in apache
or the PHP apache2filter module. My apache setup has not changed
recently whereas PHP has, so I'm looking there.

I've reconstructed my php.ini and httpd.conf files from scratch so
I'm pretty certain the settings in there are all ok. I did have
latest xdebug installed, but I'm still seeing this with it disabled.

As you might imagine, it's making debugging quite difficult. Has
anyone else seen this problem? I can't find a bug report that looks
like this.

Marcus

--
Marcus Bointon
Synchromedia Limited: Putting you in the picture
marcus@synchromedia.co.uk | http://www.synchromedia.co.uk

Mike Hall

20 years ago

Every developer at my company has experience this problem too, at one
point or another.  We get it with Apache 1.3 and PHP 5.x.  We've been
unable to figure it out.  I thought I had it tied down to the gzip
output compression at one stage.  But then it suddenly started working
okay and I couldn't get it to break again.

Mike


On Fri, 28 Oct 2005 13:52:31 +0100
Marcus Bointon <marcus@synchromedia.co.uk> wrote:

> I'm running a recent snap of 5.1 with apache 2.0.54 (from fink) and
> MySQL 5.0.15 on OS X 10.4.2. For the last few days I've noticed that
> I'm getting no error messages out at all, neither to the browser nor
> to the server log. I have display_errors, log_errors and
> log_startup_errors set to On, error_reporting set to E_ALL |
> E_STRICT, but I'm seeing nothing on web output - a simple syntax
> error results in a blank page, e.g.
>
> <?php
> sdfsdf
> ?>
>
> gives a blank page and nothing in server log. It produces an expected
> E_NOTICE error on a CLI version, so the problem is either in apache
> or the PHP apache2filter module. My apache setup has not changed
> recently whereas PHP has, so I'm looking there.
>
> I've reconstructed my php.ini and httpd.conf files from scratch so
> I'm pretty certain the settings in there are all ok. I did have
> latest xdebug installed, but I'm still seeing this with it disabled.
>
> As you might imagine, it's making debugging quite difficult. Has
> anyone else seen this problem? I can't find a bug report that looks
> like this.
>
> Marcus
> --
> Marcus Bointon
> Synchromedia Limited: Putting you in the picture
> marcus@synchromedia.co.uk | http://www.synchromedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

Mike Hall
Twist Digital Media
e. mike.hall@twistdigital.co.uk

D I S C L A I M E R
Statements and opinions expressed in this e-mail may not represent those
of the company.

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please contact the sender immediately and delete
the material from any computer.

Jochem Maas

20 years ago

Mike Hall wrote:

> Every developer at my company has experience this problem too, at one
> point or another.  We get it with Apache 1.3 and PHP 5.x.  We've been
> unable to figure it out.  I thought I had it tied down to the gzip
> output compression at one stage.  But then it suddenly started working
> okay and I couldn't get it to break again.

I have problems like this on a regular basis in big/complex (well by my standards anyway)
codebases that have heavy php5 oo in them. no errors _anywhere_ if I have a parse error
or a require_once statement fails, I havbe had the problem since php5beta3 (when I
started using php5) and have seen it happen on every version of php5 upto 5.0.4 (the highest version
I have used properly) on windows, debian, redhat and gentoo using apache and apache2.

basically AFAIC there is something wrong _deep_ in the engine but given that I have
no idea how to prove this or provide any kind of short reproduce script I'm left to live
with it ... it may of course be a problem with my code, I'm thinking a possible
reference related segfault issue (and/or maybe __autoload() related). Actually IIRC
Derick Rethans has posted before about issues he has had where problems were not easily
(or at all) reproducable in a short script. (excuses to Derick if I misquote/misremember
what he wrote in the past)

actually this is one of the main reasons I read internals@  - in the hope
someone might offer information that will help me either fix this issue in my code,
expose a real engine problem or possibly give some inspiration as to how to track down
the problem.

... I just wish I had the skills to work this problem :-)

seeing as I don't I live with it and whenever I am faced with a blank page I know
exactly what to do ...  find the parse error and if there is none check every require
statement in the files I have just changed... a process that alweays starts with this one liner:

find . -name \*.php \! -exec php -l {} \;

Marcus Bointon

20 years ago

On 28 Oct 2005, at 14:37, Jochem Maas wrote:

> I have problems like this on a regular basis in big/complex (well
> by my standards anyway)
> codebases that have heavy php5 oo in them. no errors _anywhere_ if
> I have a parse error
> or a require_once statement fails, I havbe had the problem since
> php5beta3 (when I
> started using php5) and have seen it happen on every version of
> php5 upto 5.0.4 (the highest version
> I have used properly) on windows, debian, redhat and gentoo using
> apache and apache2.
>
> basically AFAIC there is something wrong _deep_ in the engine but
> given that I have
> no idea how to prove this or provide any kind of short reproduce
> script I'm left to live
> with it ... it may of course be a problem with my code, I'm
> thinking a possible
> reference related segfault issue (and/or maybe __autoload()
> related). Actually IIRC
> Derick Rethans has posted before about issues he has had where
> problems were not easily
> (or at all) reproducable in a short script. (excuses to Derick if I
> misquote/misremember
> what he wrote in the past)

Glad to know I'm not alone! Well, this seems to be a constant state
for me - even the very simplest script (as in my first post) fails to
generate errors. It's not specific to my scripts - if I turn E_STRICT
on and run anything that uses PEAR, there's not a glimmer of an
error, when I know full well it should look like the tide coming in
in warning-land.

I've been using 5.1 for several months for the new SOAP stuff. On the
whole it's been great - and I've been very pleased with the rapid
attention my bug reports have received (thanks Ilia!) - but this
error problem is a new thing.

I often resort to using php -l for checking syntax, but at the moment
I'm having runtime troubles that syntax checks won't help with.

The only way I've been able to deliberately cause this kind of
behaviour in the past is to store an object (pretty much any class)
in a session - on restoring the session it will crash apache with no
errors logged. The only way to recover is to restart apache and
delete the cookie that relates to that session. However, I'm not
doing that at present.

FWIW, xdebug's HTML conversion of var_dump and stack traces works
very nicely and is an indispensable error tracking tool - for
example, errors in __autoload (which I keep liking and disliking) are
a pain to fix without it as you don't know where the call came from
otherwise.

Overall this seems (unfortunately) very likely to be a config
dependent thing and I don't have a good idea of the cause (hence my
config file rebuild), so I'm not keen on submitting a bug report as
yet. Should I anyway?

Marcus

--
Marcus Bointon
Synchromedia Limited: Putting you in the picture
marcus@synchromedia.co.uk | http://www.synchromedia.co.uk

Marcus Bointon

20 years ago

I'm still having trouble with PHP 5.1.0RC4 giving no error output at
all, either to browser or to logs. In my php.ini I have:

error_reporting  =  E_ALL
display_errors = On
display_startup_errors = On
log_errors = On
log_errors_max_len = 1024
ignore_repeated_errors = Off
ignore_repeated_source = Off
report_memleaks = On
track_errors = Off
html_errors = On
error_log = "/var/log/httpd/php_errors" (which exists and has same
ownership and permissions as other httpd logs which are working)

and I've also tried not setting error_log and having it set to syslog.

in my httpd.conf (apache 2.0.54-12 from Fink) I have:

ErrorLog "/private/var/log/httpd/error_log"
LogLevel info
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i
\"" combined
CustomLog "/private/var/log/httpd/access_log" combined

(On OS X, /var is a pointer to /private/var). I really can't see
anything wrong with these settings and I can't think how else error
output could be blocked. If I run scripts from CLI, I do get errors
displayed in the terminal, but it's not much use for testing web stuff.

I'm getting the same behaviour on both OS X and RHEL4.

Are there any configure options that relate to error output?

Marcus

--
Marcus Bointon
Synchromedia Limited: Putting you in the picture
marcus@synchromedia.co.uk | http://www.synchromedia.co.uk