#38353 [NEW]: pipe char in index of SESSION variables should lead to error in session_encode
From: wf at bitplan dot com Operating system: All PHP version: 5.1.4 PHP Bug Type: Session related Bug description: pipe char in index of SESSION variables should lead to error in session_encode Description: Please read carefully before rating i already had to reenter and rephrase since two existing bugreport where rated "bogus" which is the reason this bugreport is places in the first place. The rating is not o.k. Telling users "Read the fine manual" is not enough in this case because the cause is just a minor think the effect is devastating - that should not be. So please rate as "serious" to make sure the bug gets fixed. I'm sure it is a simple thing to add. The bugreports http://bugs.php.net/bug.php?id=33786 and http://bugs.php.net/bug.php?id=38346 have just the Status "bogus". That rating is not o.k. It's true that using pipe chars as part of an array index is not allowed - but the system should react better on this at least it should give a proper error message. With the current buggy behaviour of the system as an answer to the programming error session_encode will fail badly and a whole web - app will suffer (I've seen one report that someone lost his job due to sessions not being restored properly ...) A simple programming error that is hard to find and the whole system will be unusuable. PHP can do better than that and simply given an error message. Reproduce code: --- "; } // for ?> Expected result: A (fatal) error message on using | within the array index name for $_SESSION Actual result: -- when varname is v|ar session has 2 entries that are encoded with 0 bytes ' -- Edit bug report at http://bugs.php.net/?id=38353&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38353&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38353&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38353&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38353&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38353&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38353&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38353&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38353&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38353&r=support Expected behavior:http://bugs.php.net/fix.php?id=38353&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38353&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38353&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38353&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38353&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38353&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38353&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38353&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38353&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38353&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38353&r=mysqlcfg
#38346 [NEW]: pipe char in index of SESSION variables should lead to error in session_encode
From: wf at bitplan dot com Operating system: all PHP version: 5.1.4 PHP Bug Type: Session related Bug description: pipe char in index of SESSION variables should lead to error in session_encode Description: The bugreport http://bugs.php.net/bug.php?id=33786 has just the status "bogus". That is a bug, because session_encode will fail badly and a whole web - app will suffer (I've seen one report that someone lost his job due to sessions not being restored properly ...) Reproduce code: --- "; } // for ?> Expected result: A (fatal) error message on using | within the array index name for $_SESSION Actual result: -- when varname is v|ar session has 2 entries that are encoded with 0 bytes ' -- Edit bug report at http://bugs.php.net/?id=38346&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38346&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38346&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38346&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38346&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38346&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38346&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38346&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38346&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38346&r=support Expected behavior:http://bugs.php.net/fix.php?id=38346&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38346&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38346&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38346&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38346&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38346&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38346&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38346&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38346&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38346&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38346&r=mysqlcfg
#38213 [NEW]: Wddx serializer and umlaute in $_SESSION variables don't work together
From: wf at bitplan dot com Operating system: Windows XP PHP version: 5.1.4 PHP Bug Type: Reproducible crash Bug description: Wddx serializer and umlaute in $_SESSION variables don't work together Description: When setting the serialize handler to wddx in php.in: session.serialize_handler = wddx using any Umlaut in a $_SESSION variable will lead to misbehaviour of the system e.g. Apache crashing or the session file content to be destroyed Reproduce code: --- sesstest1.php: = "; ?> Page 2 sesstest2.php: = "; unset ($_SESSION['sess_var']); session_write_close(); ?> Page 1 Expected result: there are several ways to do this properly, one is to set the encoding: in the first line of the wddx file, another one is to use utf-8 encoding on encoding and decoding Actual result: -- äöüßÄÖÜßé And the system might throw-up on decoding when e.g. using french, spanish, swedish or other accented characters. -- Edit bug report at http://bugs.php.net/?id=38213&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38213&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38213&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38213&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38213&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38213&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38213&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38213&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38213&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38213&r=support Expected behavior:http://bugs.php.net/fix.php?id=38213&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38213&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38213&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38213&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38213&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38213&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38213&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38213&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38213&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38213&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38213&r=mysqlcfg
#34671 [Opn]: strange exec behaviour on multiple quotes
ID: 34671
User updated by: wf at bitplan dot com
Reported By: wf at bitplan dot com
Status: Open
Bug Type: Unknown/Other Function
Operating System: Windows XP
PHP Version: 5.0.5
New Comment:
it's not a PHP but a cmd.exe problem:
""C:/Programme/MySQL/MySQL Server 4.1/bin/mysql.exe" --user=smartrqm
--password=6y-app% --database=smartRQM --execute="status""
works. This is due to the way cmd /c works which is obviously used
internally. See cmd /help on how cmd.exe handles quotes
Previous Comments:
--------
[2005-09-28 14:39:10] wf at bitplan dot com
Description:
in the code below
$cmd='"C:/Programme/MySQL/MySQL Server 4.1/bin/mysql.exe"
--execute=status';
works, but
$cmd='"C:/Programme/MySQL/MySQL Server 4.1/bin/mysql.exe"
--execute="status"';
does not. The error message is:
failed with return-code: 1
Der Befehl "C:/Programme/MySQL/MySQL" ist entweder falsch geschrieben
oder konnte nicht gefunden werden.
This is very strange, since running the command in a cmd box in Windows
works in both cases.
Reproduce code:
---
$_output=array();
$cmd='"C:/Programme/MySQL/MySQL Server 4.1/bin/mysql.exe"
--execute="status"';
exec($cmd,$_output,$_retval);
if ($_retval==0) {
echo 'and done !';
} else {
echo " failed with return-code: ".$_retval;
foreach($_output as $_outputline){
echo("$_outputline");
}
Expected result:
exec should work in both cases
Actual result:
--
failed with return-code: 1
Der Befehl "C:/Programme/MySQL/MySQL" ist entweder falsch geschrieben
oder konnte nicht gefunden werden.
--
Edit this bug report at http://bugs.php.net/?id=34671&edit=1
#34671 [NEW]: strange exec behaviour on multiple quotes
From: wf at bitplan dot com
Operating system: Windows XP
PHP version: 5.0.5
PHP Bug Type: Unknown/Other Function
Bug description: strange exec behaviour on multiple quotes
Description:
in the code below
$cmd='"C:/Programme/MySQL/MySQL Server 4.1/bin/mysql.exe"
--execute=status';
works, but
$cmd='"C:/Programme/MySQL/MySQL Server 4.1/bin/mysql.exe"
--execute="status"';
does not. The error message is:
failed with return-code: 1
Der Befehl "C:/Programme/MySQL/MySQL" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
This is very strange, since running the command in a cmd box in Windows
works in both cases.
Reproduce code:
---
$_output=array();
$cmd='"C:/Programme/MySQL/MySQL Server 4.1/bin/mysql.exe"
--execute="status"';
exec($cmd,$_output,$_retval);
if ($_retval==0) {
echo 'and done !';
} else {
echo " failed with return-code: ".$_retval;
foreach($_output as $_outputline){
echo("$_outputline");
}
Expected result:
exec should work in both cases
Actual result:
--
failed with return-code: 1
Der Befehl "C:/Programme/MySQL/MySQL" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
--
Edit bug report at http://bugs.php.net/?id=34671&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34671&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34671&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34671&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34671&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34671&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34671&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34671&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34671&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34671&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34671&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34671&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34671&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34671&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34671&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34671&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34671&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34671&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34671&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34671&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34671&r=mysqlcfg
#31690 [NEW]: user specific additions to php.ini
From: wf at bitplan dot com Operating system: all PHP version: 5.0.3 PHP Bug Type: Feature/Change Request Bug description: user specific additions to php.ini Description: a) When adding user specific entries to php.ini these are not returned. b) the location of php.ini is not available via a standard function The combination of a + b makes it almost impossible to have user specific additions to php.ini So ini_get() should allow to read user specific entries and/or the php.ini location should be available as a variable or via ini_get Reproduce code: --- a) php.ini contains: uml2phphome = "c:/Programme/BITPlan/UML2PHP" b) echo PHP_INI_PATH; Expected result: a) c:/Programme/BITPlan/UML2PHP b) c:/Windows/PHP.INI on my windows machine /usr/local/lib/php5.0.3/php.ini on my linux machine Actual result: -- nothing -- Edit bug report at http://bugs.php.net/?id=31690&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31690&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31690&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31690&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31690&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31690&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31690&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31690&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31690&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31690&r=support Expected behavior: http://bugs.php.net/fix.php?id=31690&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31690&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31690&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31690&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31690&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31690&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31690&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31690&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31690&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31690&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31690&r=mysqlcfg
#27815 [NoF->Opn]: SourceForge XPath.class.php 3.4 Testsuite crashes Apache 2.0.49
ID: 27815 User updated by: wf at bitplan dot com Reported By: wf at bitplan dot com -Status: No Feedback +Status: Open Bug Type: DOM XML related Operating System: WindowsXP PHP Version: 5.0.0RC1 New Comment: I'm not using XClass.path any more due to the Apache crashes this used to cause Previous Comments: [2005-01-18 01:00:08] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, 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". [2005-01-10 15:19:16] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2004-03-31 15:09:54] wf at bitplan dot com Description: We are using PHP5.0RC1 with Apache 2.0.49 and are heavily relying to XPath.Class.php which you'll find on sourceforge.net. We now tried to use the testsuite for XPath.Class.php to trace down the problem and it reproducibly crashes Apache any time you run it. The environment is 1 GByte MainMemory machine with a 64 MByte limit for PHP Scripts. max_execution_time = 90 ; Maximum execution time of memory_limit = 64M ; Maximum amount of memory a script may consume (8MB) extension=php_mysql.dll The apache error log shows: [Wed Mar 31 22:15:16 2004] [notice] Parent: child process exited with status 128 -- Restarting. Reproduce code: --- Download XClass.path.php and Testsuite from http://sourceforge.net/projects/phpxpath/ change line 4614 in XPatch.class.php to avoid a PHP5 fatal error: //$this = FALSE; // PHP5 incompatible !!! unset($this); run testsuite with http://localhost/XPath/testBench/validationTests/index.php and click on "Run XPath tests" Expected result: testsuite should run without crash Actual result: -- Apache crashes immediately -- Edit this bug report at http://bugs.php.net/?id=27815&edit=1
#28337 [Bgs]: endless recursion crashes Apache
ID: 28337 User updated by: wf at bitplan dot com Reported By: wf at bitplan dot com Status: Bogus Bug Type: Reproducible crash Operating System: Windows XP SP1 PHP Version: 5.0.0RC2 New Comment: Endless recursion is detected in any decent programming language. I'd consider PHP a decent programming language if it does detect endless recursion. A simple stack overflow message will do. Not detecting endless recursion is an inacceptable design decision for PHP since an apache crash is not acceptable result for such a simple problem. Previous Comments: [2004-05-09 17:58:41] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Don't do that. [2004-05-09 17:33:14] wf at bitplan dot com Description: Endless recursion crashes Apache PHP should simply report a stack-overflow exception and die This was called non repairable in 2002 but I'd seem its not acceptable for the object oriented PHP 5 version anymore Reproduce code: --- loop(); } // loop } $endless=new recurse(); $endless->loop(); ?> Expected result: stack-overflow message Actual result: -- Apache crashes -- Edit this bug report at http://bugs.php.net/?id=28337&edit=1
#28337 [NEW]: endless recursion crashes Apache
From: wf at bitplan dot com Operating system: Windows XP SP1 PHP version: 5.0.0RC2 PHP Bug Type: Reproducible crash Bug description: endless recursion crashes Apache Description: Endless recursion crashes Apache PHP should simply report a stack-overflow exception and die This was called non repairable in 2002 but I'd seem its not acceptable for the object oriented PHP 5 version anymore Reproduce code: --- loop(); } // loop } $endless=new recurse(); $endless->loop(); ?> Expected result: stack-overflow message Actual result: -- Apache crashes -- Edit bug report at http://bugs.php.net/?id=28337&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28337&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28337&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28337&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28337&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28337&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28337&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28337&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28337&r=support Expected behavior: http://bugs.php.net/fix.php?id=28337&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28337&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28337&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28337&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28337&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28337&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28337&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28337&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28337&r=float
#28213 [Com]: debug_print_backtrace() crash PHP when including a file that doesn't exist
ID: 28213
Comment by: wf at bitplan dot com
Reported By: [EMAIL PROTECTED]
Status: Assigned
Bug Type: Zend Engine 2 problem
Operating System: Linux
PHP Version: 5CVS-2004-04-29 (dev)
Assigned To: Andi
New Comment:
Spurious crashes happen also if used like this:
function internal_error($msg) {
global $testmode_errordisplay;
if (isset($testmode_errordisplay)) {
display_error($msg,"ERROR");
if ($testmode_errordisplay=="stacktrace")
printStackTrace();
}
user_error($msg);
}
Previous Comments:
[2004-04-29 05:38:46] [EMAIL PROTECTED]
Description:
debug_print_backtrace() will crash PHP when called from inside a static
function used as custom error handler function.
Reproduce code:
---
Actual result:
--
magnus:crash > php crash.php
#0 FooBar::error() called at
[/home/magnus/Projects/base/tests/crash/crash.php:6]
#1 FooBarSegmentation fault
(gdb) bt
#0 0x40d4cb53 in strlen () from /lib/libc.so.6
#1 0x0839a0a9 in zif_debug_print_backtrace (ht=0,
return_value=0x40e24720, this_ptr=0x0, return_value_used=0)
at /mnt/data1/Apps/CVS/PHP/php5/Zend/zend_builtin_functions.c:1549
#2 0x083b53a8 in zend_do_fcall_common_helper (execute_data=0xbfffc9d0,
opline=0x40e25584, op_array=0x40e2691c)
at /mnt/data1/Apps/CVS/PHP/php5/Zend/zend_execute.c:2699
#3 0x083b5bbb in zend_do_fcall_handler (execute_data=0xbfffc9d0,
opline=0x40e25584, op_array=0x40e2691c)
at /mnt/data1/Apps/CVS/PHP/php5/Zend/zend_execute.c:2828
#1 0x0839a0a9 in zif_debug_print_backtrace (ht=0,
return_value=0x40e24720, this_ptr=0x0, return_value_used=0)
at /mnt/data1/Apps/CVS/PHP/php5/Zend/zend_builtin_functions.c:1549
ptr = (zend_execute_data *) 0xbfffd060
lineno = 4
function_name = 0x848cf97 "include"
filename = 0x40e23c08
"/home/magnus/Projects/base/tests/crash/crash.php"
class_name = 0x40e25070 "FooBar"
call_type = 0x0
include_filename = 0x40e23c08
"/home/magnus/Projects/base/tests/crash/crash.php"
arg_array = (zval *) 0x40e2481c
cur_arg_pos = (void **) 0x40e13c90
args = (void **) 0x40e13c74
arg_stack_consistent = 1
frames_on_stack = 1
indent = 1
#2 0x083b53a8 in zend_do_fcall_common_helper (execute_data=0xbfffc9d0,
opline=0x40e25584, op_array=0x40e2691c)
at /mnt/data1/Apps/CVS/PHP/php5/Zend/zend_execute.c:2699
original_return_value = (zval **) 0x3f7
current_scope = (zend_class_entry *) 0x853e4d8
current_this = (zval *) 0x0
return_value_used = 0
should_change_scope = 0 '\0'
#3 0x083b5bbb in zend_do_fcall_handler (execute_data=0xbfffc9d0,
opline=0x40e25584, op_array=0x40e2691c)
at /mnt/data1/Apps/CVS/PHP/php5/Zend/zend_execute.c:2828
fname = (zval *) 0x40e255a0
--
Edit this bug report at http://bugs.php.net/?id=28213&edit=1
#28145 [Bgs]: $this / instanceof issue with static calls of instance functions
ID: 28145
User updated by: wf at bitplan dot com
Reported By: wf at bitplan dot com
Status: Bogus
Bug Type: Class/Object related
Operating System: *
PHP Version: 5*
New Comment:
thanks for the feedback.
$this=null sounds ok for me
instanceof null should be false though and not null ... that was the
main point of my bug report
Previous Comments:
[2004-04-25 18:11:36] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
In a statically called method $this is NULL and NULL representation is
the empty string.
Regarding #20089: In a stattically called method there cannot be a
$this because it is a local variable generated by the engine. the
behavior of PHP 4 is wrong and is there only because there simply was
no way to implement it correct. One of the reasons it could not be done
correct is the lack of real static methods.
[2004-04-25 17:26:01] wf at bitplan dot com
Description:
I am using PHP5 RC2 (couldn't yet select it - have downloaded it a few
minutes ago ...) on Windows XP Professional with Apache2.0.49.
This bug is similar to #20089 but I'm complaining more about the
instanceof issue. The true fix is of course fixing #20089 first. Saying
"This is not a bug" is not a good thing with the goal of better object
orientation for PHP5 ...
When calling an instance function ("->" needed) as a class function
("::") this should either be an error or instanceof for the given class
should fail - it looks like
a) instanceof returns "" instead of FALSE/0 when
this is not the correct instance
b) when calling an instance function of another class in a static way
this should be an error
Reproduce code:
---
'; }
function getInstance () { return new Foo(); }
function operation() { echo "Foo operation this is a
".get_Class($this)."";
echo "This is a Foo: ".$this instanceof
Foo.""; }
function baroperation () { Bar::operation(); }
}
class Bar
{
function __construct () { echo 'Generating a Bar object '; }
function getInstance () { return new Bar(); }
function operation() { echo "Bar operation this is a
".get_Class($this)."";
echo "This is a Bar: ".$this instanceof
Bar.""; }
function fooOperation () { Foo::operation(); }
}
$foo = Foo::getInstance();
$bar = Bar::getInstance();
$foo->operation();
$bar->operation();
$foo->baroperation();
$bar->foooperation();
Foo::operation();
Bar::operation();
?>
Expected result:
Generating a Foo object
Generating a Bar object
Foo operation this is a Foo
This is a Foo: 1
Bar operation this is a Bar
This is a Bar: 1
error Bar operation but this is a Foo
This is a Bar: 0
error Foo operation but this is a Bar
This is a Foo: 0
Foo operation this is a nil
This is a Foo: 0
Bar operation this is a nil
This is a Bar: 0
Actual result:
--
Generating a Foo object
Generating a Bar object
Foo operation this is a Foo
This is a Foo: 1
Bar operation this is a Bar
This is a Bar: 1
Bar operation this is a Foo
This is a Bar:
Foo operation this is a Bar
This is a Foo:
Foo operation this is a
This is a Foo:
Bar operation this is a
This is a Bar:
--
Edit this bug report at http://bugs.php.net/?id=28145&edit=1
#28145 [NEW]: $this / instanceof issue with static calls of instance functions
From: wf at bitplan dot com
Operating system: WindowsXP
PHP version: 5.0.0RC1
PHP Bug Type: Class/Object related
Bug description: $this / instanceof issue with static calls of instance functions
Description:
I am using PHP5 RC2 (couldn't yet select it - have downloaded it a few
minutes ago ...) on Windows XP Professional with Apache2.0.49.
This bug is similar to #20089 but I'm complaining more about the
instanceof issue. The true fix is of course fixing #20089 first. Saying
"This is not a bug" is not a good thing with the goal of better object
orientation for PHP5 ...
When calling an instance function ("->" needed) as a class function ("::")
this should either be an error or instanceof for the given class should
fail - it looks like
a) instanceof returns "" instead of FALSE/0 when
this is not the correct instance
b) when calling an instance function of another class in a static way this
should be an error
Reproduce code:
---
'; }
function getInstance () { return new Foo(); }
function operation() { echo "Foo operation this is a
".get_Class($this)."";
echo "This is a Foo: ".$this instanceof
Foo.""; }
function baroperation () { Bar::operation(); }
}
class Bar
{
function __construct () { echo 'Generating a Bar object '; }
function getInstance () { return new Bar(); }
function operation() { echo "Bar operation this is a
".get_Class($this)."";
echo "This is a Bar: ".$this instanceof
Bar.""; }
function fooOperation () { Foo::operation(); }
}
$foo = Foo::getInstance();
$bar = Bar::getInstance();
$foo->operation();
$bar->operation();
$foo->baroperation();
$bar->foooperation();
Foo::operation();
Bar::operation();
?>
Expected result:
Generating a Foo object
Generating a Bar object
Foo operation this is a Foo
This is a Foo: 1
Bar operation this is a Bar
This is a Bar: 1
error Bar operation but this is a Foo
This is a Bar: 0
error Foo operation but this is a Bar
This is a Foo: 0
Foo operation this is a nil
This is a Foo: 0
Bar operation this is a nil
This is a Bar: 0
Actual result:
--
Generating a Foo object
Generating a Bar object
Foo operation this is a Foo
This is a Foo: 1
Bar operation this is a Bar
This is a Bar: 1
Bar operation this is a Foo
This is a Bar:
Foo operation this is a Bar
This is a Foo:
Foo operation this is a
This is a Foo:
Bar operation this is a
This is a Bar:
--
Edit bug report at http://bugs.php.net/?id=28145&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28145&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28145&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28145&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28145&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28145&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28145&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28145&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28145&r=support
Expected behavior: http://bugs.php.net/fix.php?id=28145&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28145&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28145&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28145&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28145&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28145&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28145&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28145&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28145&r=float
#27815 [Fbk->Opn]: SourceForge XPath.class.php 3.4 Testsuite crashes Apache 2.0.49
ID: 27815 User updated by: wf at bitplan dot com Reported By: wf at bitplan dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: WindowsXP PHP Version: 5.0.0RC1 New Comment: If used the latest snapshot as recommended and the problem persists - still a crash! Previous Comments: [2004-04-13 13:05:12] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2004-03-31 15:09:54] wf at bitplan dot com Description: We are using PHP5.0RC1 with Apache 2.0.49 and are heavily relying to XPath.Class.php which you'll find on sourceforge.net. We now tried to use the testsuite for XPath.Class.php to trace down the problem and it reproducibly crashes Apache any time you run it. The environment is 1 GByte MainMemory machine with a 64 MByte limit for PHP Scripts. max_execution_time = 90 ; Maximum execution time of memory_limit = 64M ; Maximum amount of memory a script may consume (8MB) extension=php_mysql.dll The apache error log shows: [Wed Mar 31 22:15:16 2004] [notice] Parent: child process exited with status 128 -- Restarting. Reproduce code: --- Download XClass.path.php and Testsuite from http://sourceforge.net/projects/phpxpath/ change line 4614 in XPatch.class.php to avoid a PHP5 fatal error: //$this = FALSE; // PHP5 incompatible !!! unset($this); run testsuite with http://localhost/XPath/testBench/validationTests/index.php and click on "Run XPath tests" Expected result: testsuite should run without crash Actual result: -- Apache crashes immediately -- Edit this bug report at http://bugs.php.net/?id=27815&edit=1
#27815 [Fbk->Opn]: SourceForge XPath.class.php 3.4 Testsuite crashes Apache 2.0.49
ID: 27815 User updated by: wf at bitplan dot com Reported By: wf at bitplan dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: WindowsXP PHP Version: 5.0.0RC1 New Comment: I'll happily supply a backtrace if'd get information how to do this on Windows XP. The URL supplied is obviously for Linux boxes. I'm using the Windows standard distribution and do not compile the PHP code myself. What can I do to help? Previous Comments: [2004-03-31 15:23:11] [EMAIL PROTECTED] 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. ---- [2004-03-31 15:09:54] wf at bitplan dot com Description: We are using PHP5.0RC1 with Apache 2.0.49 and are heavily relying to XPath.Class.php which you'll find on sourceforge.net. We now tried to use the testsuite for XPath.Class.php to trace down the problem and it reproducibly crashes Apache any time you run it. The environment is 1 GByte MainMemory machine with a 64 MByte limit for PHP Scripts. max_execution_time = 90 ; Maximum execution time of memory_limit = 64M ; Maximum amount of memory a script may consume (8MB) extension=php_mysql.dll The apache error log shows: [Wed Mar 31 22:15:16 2004] [notice] Parent: child process exited with status 128 -- Restarting. Reproduce code: --- Download XClass.path.php and Testsuite from http://sourceforge.net/projects/phpxpath/ change line 4614 in XPatch.class.php to avoid a PHP5 fatal error: //$this = FALSE; // PHP5 incompatible !!! unset($this); run testsuite with http://localhost/XPath/testBench/validationTests/index.php and click on "Run XPath tests" Expected result: testsuite should run without crash Actual result: -- Apache crashes immediately -- Edit this bug report at http://bugs.php.net/?id=27815&edit=1
#27815 [NEW]: SourceForge XPath.class.php 3.4 Testsuite crashes Apache 2.0.49
From: wf at bitplan dot com Operating system: WindowsXP PHP version: 5.0.0RC1 PHP Bug Type: Reproducible crash Bug description: SourceForge XPath.class.php 3.4 Testsuite crashes Apache 2.0.49 Description: We are using PHP5.0RC1 with Apache 2.0.49 and are heavily relying to XPath.Class.php which you'll find on sourceforge.net. We now tried to use the testsuite for XPath.Class.php to trace down the problem and it reproducibly crashes Apache any time you run it. The environment is 1 GByte MainMemory machine with a 64 MByte limit for PHP Scripts. max_execution_time = 90 ; Maximum execution time of memory_limit = 64M ; Maximum amount of memory a script may consume (8MB) extension=php_mysql.dll The apache error log shows: [Wed Mar 31 22:15:16 2004] [notice] Parent: child process exited with status 128 -- Restarting. Reproduce code: --- Download XClass.path.php and Testsuite from http://sourceforge.net/projects/phpxpath/ change line 4614 in XPatch.class.php to avoid a PHP5 fatal error: //$this = FALSE; // PHP5 incompatible !!! unset($this); run testsuite with http://localhost/XPath/testBench/validationTests/index.php and click on "Run XPath tests" Expected result: testsuite should run without crash Actual result: -- Apache crashes immediately -- Edit bug report at http://bugs.php.net/?id=27815&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27815&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27815&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27815&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27815&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27815&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27815&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27815&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27815&r=support Expected behavior: http://bugs.php.net/fix.php?id=27815&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27815&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27815&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27815&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27815&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27815&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27815&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27815&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27815&r=float
#27761 [NEW]: Long list of require_once first slows down PHP than crashes Apache
From: wf at bitplan dot com
Operating system: Windows XP
PHP version: 5.0.0RC1
PHP Bug Type: Reproducible crash
Bug description: Long list of require_once first slows down PHP than crashes Apache
Description:
With the script below I generated some 200 PHP classes.
The profiling result for loading all these classes with some 25.000 lines
of code is:
start:00:04:50.999346
stop :00:04:51.432091
The loading takes some 432 Milliseconds that ok for so many classes.
Doing the same with 60 classes in real code environment takes
from 3 to 25 secs before Apache crashes ...
awk '
BEGIN {
for (i=1;i<200;i++) {
class=sprintf("class%03d",i);
fname=class".php";
print " fname
printf("class %s {\n",class) >>fname
printf(" public $somevar;\n") >> fname
for (j=1;j<60;j++) {
printf(" public function somefunction"j"() {\n") >> fname
printf(" }\n") >>fname
}
printf("} // %s\n",class) >>fname
print "?>" >> fname
close(fname);
}
fname="test.php";
print " fname
print "include(\"profile.php\");" >> fname
print "profile(\"start\");" >> fname
for (i=1;i<200;i++) {
class=sprintf("class%03d",i);
classfname=class".php";
printf("require_once(\"%s\");\n",classfname) >> fname
}
print "displayProfile();" >> fname
print "?>" >> fname
close(fname);
}
'
profile.php has the following content:
";
global $profile_times;
foreach ($profile_times as $_step=>$_time) {
echo $_step.":".$_time."";
} // foreach
} // displayProfile
?>
Reproduce code:
---
It said:
Please do not post more than 20 lines of source code.
If the code is longer then 20 lines, provide an URL to the source code
that will reproduce the bug.
Sorry - If I'd provide the URL I'd have to provide a server that may crash
any time.
A Zip File with the code can be made available by us
XPath.Class.php loading took up to 1.9 secs in our enviroment alone when
using the __Autoload feature:
be/estro/genepi/classUserManager.php:23:42:12.556828
com/bitplan/common/XPath.class.php:23:42:14.405958
Expected result:
Performance should be acceptable that is class loading should take less
than 300 millisecs.
Actual result:
--
Loading of a single class with 5600 lines of code takes 1.9 secs:
be/estro/genepi/classSession.php:23:42:12.422696
be/estro/genepi/classUserManager.php:23:42:12.556828 (250 lines of code
take approx 130 Millisecs ...)
com/bitplan/common/XPath.class.php:23:42:14.405958
5600 lines take 1.9 secs ...
--
Edit bug report at http://bugs.php.net/?id=27761&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27761&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27761&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27761&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27761&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27761&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27761&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27761&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27761&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27761&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27761&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27761&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27761&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27761&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27761&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27761&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27761&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27761&r=float
#27215 [Com]: include in php5 is very slow
ID: 27215 Comment by: wf at bitplan dot com Reported By: waboring at 3gstech dot com Status: Open Bug Type: Performance problem Operating System: Redhat 9 PHP Version: 5CVS-2004-02-10 (dev) New Comment: We get Apache crashes with this issue. We are loading some 100 PHP classes that are generated from an UML model. The total number of lines is some 23.000. Initially the require_once calls for all classes take a few millisecs. After a while the time rises to 3, 7, 15, 25 or more seconds until Apache crashes. Using __AUTOLOAD does not help much. have a look at this profile: needed 4765 msecs start:23:42:07.662623 after GenepiArchitecture include:23:42:07.670712 after GenepiContent include:23:42:10.656884 be/estro/genepi/classNameValueList.php:23:42:10.742749 after session_start:23:42:10.772402 be/estro/genepi/classWebFrameManager.php:23:42:10.977352 be/estro/genepi/classWebFrame.php:23:42:11.376788 be/estro/genepi/classTimer.php:23:42:11.483785 be/estro/genepi/classSystemConfiguration.php:23:42:11.636121 be/estro/genepi/classDatabaseManager.php:23:42:11.807113 be/estro/genepi/classDatabase.php:23:42:12.21742 be/estro/genepi/classSessionManager.php:23:42:12.288590 be/estro/genepi/classSession.php:23:42:12.422696 be/estro/genepi/classUserManager.php:23:42:12.556828 com/bitplan/common/XPath.class.php:23:42:14.405958 be/estro/genepi/classUser.php:23:42:14.745952 be/estro/genepi/classUserRoleManager.php:23:42:14.866260 be/estro/genepi/classUserRole.php:23:42:14.941703 be/estro/genepi/classMenuManager.php:23:42:14.990230 be/estro/genepi/classMenu.php:23:42:15.512703 be/estro/genepi/classMenuItemManager.php:23:42:15.580588 be/estro/genepi/classMenuItem.php:23:42:15.586010 be/estro/genepi/classFunctionCallManager.php:23:42:15.591146 be/estro/genepi/classFunctionCall.php:23:42:15.596076 stop:23:42:16.251670 1.9 secs for XPath.class.php alone ... Previous Comments: [2004-03-23 17:44:26] waboring at 3gstech dot com Some more data points. I used apache bench to run the test.php script in my last post. I tested against php 4.3.2 and today's cvs php5. Here are the results. php4: Server Software:Apache/1.3.26 Server Hostname:phphtmllib.hemna.corp.qualys.com Server Port:80 Document Path: /test.php Document Length:34 bytes Concurrency Level: 1 Time taken for tests: 9.748 seconds Complete requests: 100 Failed requests:0 Broken pipe errors: 0 Total transferred: 22900 bytes HTML transferred: 3400 bytes Requests per second:10.26 [#/sec] (mean) Time per request: 97.48 [ms] (mean) php5: Server Software:Apache/1.3.26 Server Hostname:phphtmllib.hemna.corp.qualys.com Server Port:80 Document Path: /test.php Document Length:34 bytes Concurrency Level: 1 Time taken for tests: 39.551 seconds Complete requests: 100 Failed requests:0 Broken pipe errors: 0 Total transferred: 24300 bytes HTML transferred: 3400 bytes Requests per second:2.53 [#/sec] (mean) Time per request: 395.51 [ms] (mean) [2004-03-23 17:06:45] waboring at 3gstech dot com ok with further testing, I have trimmed my configure line down to the following. ./configure \ -with-apxs=/usr/local/apache/bin/apxs I then restart apache. First hit to the test script .097 s Second hit .187 s third .264 s .332 s .346 s .392 s (peaked out here) In each test, I wait a few seconds to make sure there is no load on the machine. I'm using a seperate machine to run the browser as to not polute the server response times. The entire php script. elapsed time: ".$elapsed." s \n"; ?> [2004-03-23 16:40:14] waboring at 3gstech dot com finally bugs.php.net is accessable again. I wasn't able to hit it since last friday! bleh. Anyway, I have tested w/ an up to date (as of now) cvs tree of php-src and have re-run the test and am still seeing significant slowdowns just by doing includes. I am running the sample script that I have listed in the original post. php4 = .075 ms php5 = .372 ms php5 is acting strangely. I do a restart of apache. First time I hit the test script (php5) I get a time of about .100ms. I then wait about 2 seconds and make sure there is no load on the box. Then I hit reload in the browser. That takes .237ms. I do the same thing again, and the next time the script takes even longer to execute at .372ms. Here is my configure line. ./configure \ --with-oci8=/u01/app/oracle/product/8.1.7 \ --enable-sigchild \ --with-mcrypt \ --with-gd \ --with-png-dir=/usr \ --with
#27595 [Com]: throw new Exception() crash
ID: 27595 Comment by: wf at bitplan dot com Reported By: tom at webcrumb dot com Status: No Feedback Bug Type: Zend Engine 2 problem Operating System: Windows XP PHP Version: 5.0.0b4 (beta4) New Comment: You need to use Netscape to test this - IE will not ask the server to reexecute the code Previous Comments: [2004-03-29 07:11:26] wf at bitplan dot com 5.0.0RC1 still has this bug - my mileage is "6" [2004-03-15 13:59:59] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2004-03-14 08:47:25] tom at webcrumb dot com Description: The following test code runs fine the first 29 (your mileage may vary) times the page is viewed. On the 30th time, CPU usage shoots to 100% briefly and Apache 2 crashes hard. '30' is the magic number for my system, I imagine your mileage may vary if this is - as I suspect - some sort of memory corruption bug. The problem appears to be with the exception handling mechanism, since I can comment all the code out, or attempt to refresh the page 50+ times with a class declaration / simple method call. Reproduce code: --- getMessage(); } ?> Expected result: 'Testing' should appear on screen. Actual result: -- For the first 29 times the page is viewed, 'Testing' appears. On the 30th time, Apache 2 crashes hard. -- Edit this bug report at http://bugs.php.net/?id=27595&edit=1
#27595 [Com]: throw new Exception() crash
ID: 27595 Comment by: wf at bitplan dot com Reported By: tom at webcrumb dot com Status: No Feedback Bug Type: Zend Engine 2 problem Operating System: Windows XP PHP Version: 5.0.0b4 (beta4) New Comment: 5.0.0RC1 still has this bug - my mileage is "6" Previous Comments: [2004-03-15 13:59:59] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2004-03-14 08:47:25] tom at webcrumb dot com Description: The following test code runs fine the first 29 (your mileage may vary) times the page is viewed. On the 30th time, CPU usage shoots to 100% briefly and Apache 2 crashes hard. '30' is the magic number for my system, I imagine your mileage may vary if this is - as I suspect - some sort of memory corruption bug. The problem appears to be with the exception handling mechanism, since I can comment all the code out, or attempt to refresh the page 50+ times with a class declaration / simple method call. Reproduce code: --- getMessage(); } ?> Expected result: 'Testing' should appear on screen. Actual result: -- For the first 29 times the page is viewed, 'Testing' appears. On the 30th time, Apache 2 crashes hard. -- Edit this bug report at http://bugs.php.net/?id=27595&edit=1
