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
[EMAIL PROTECTED] | http://www.synchromedia.co.uk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
