#34079 [Opn->Bgs]: using __toString with . causes the object id to be printed
ID: 34079
Updated by: [EMAIL PROTECTED]
Reported By: mbneto at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: Linux
PHP Version: 5.1.0b3
New Comment:
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
.
Previous Comments:
[2005-08-11 04:50:01] mbneto at gmail dot com
Description:
When using a echo/print with an object that has a __toString method
defined it behaves strange depending on the usage.
echo $obj is fine
echo $obj."\n" is not
Reproduce code:
---
class TestClass
{
public $foo;
public function __construct($foo) {
$this->foo = $foo;
}
public function __toString() {
return $this->foo;
}
}
$n = new TestClass("test") ;
echo $n ; // works - shows test
echo $n."\n" ; // does not - show Object id #1
Expected result:
Test
Actual result:
--
Object id #1
--
Edit this bug report at http://bugs.php.net/?id=34079&edit=1
#34079 [NEW]: using __toString with . causes the object id to be printed
From: mbneto at gmail dot com
Operating system: Linux
PHP version: 5.1.0b3
PHP Bug Type: Class/Object related
Bug description: using __toString with . causes the object id to be printed
Description:
When using a echo/print with an object that has a __toString method
defined it behaves strange depending on the usage.
echo $obj is fine
echo $obj."\n" is not
Reproduce code:
---
class TestClass
{
public $foo;
public function __construct($foo) {
$this->foo = $foo;
}
public function __toString() {
return $this->foo;
}
}
$n = new TestClass("test") ;
echo $n ; // works - shows test
echo $n."\n" ; // does not - show Object id #1
Expected result:
Test
Actual result:
--
Object id #1
--
Edit bug report at http://bugs.php.net/?id=34079&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34079&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34079&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34079&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34079&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34079&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34079&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34079&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34079&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34079&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34079&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34079&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34079&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34079&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34079&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34079&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34079&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34079&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34079&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34079&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34079&r=mysqlcfg
#34058 [Com]: get_headers() retrieve a particular respons
ID: 34058 Comment by: arnar at 8 dot is Reported By: [EMAIL PROTECTED] Status: Open Bug Type:Feature/Change Request PHP Version: 5CVS-2005-08-10 (dev) New Comment: Patch has been submitted to php.internals http://news.php.net/php.internals/17815 Arnar Mar Sig Previous Comments: [2005-08-10 02:42:22] [EMAIL PROTECTED] Description: Any change we can make get_headers() to act like parse_url(), i.e. retrive a particular respons (see: http://news.php.net/php.cvs/33239)? Reproduce code: --- http://example.com";, 1, "Last-Modified"); echo $last_modified; ?> Expected result: Wed, 08 Jan 2003 23:11:55 GMT -- Edit this bug report at http://bugs.php.net/?id=34058&edit=1
#34078 [NEW]: Reflection API problems in methods with boolean or null default values
From: leon at lost dot co dot nz
Operating system: Debian Sarge (2.6.12 kernel)
PHP version: 5CVS-2005-08-11 (dev)
PHP Bug Type: Scripting Engine problem
Bug description: Reflection API problems in methods with boolean or null
default values
Description:
This problem came up when moving our homebrew 'PHPDoc' type class to
PHP5.1. When built with --enable-debug PHP throws up warnings up when the
class to be documented ('A' below) contains methods with default values
that are either NULL or boolean
In the code snippet below we get two warnings, one for each default
parameter. Changing the default values to a string or number (even zero)
eliminates the warnings.
This is a serious problem for us. When documenting some of our bigger
classes we have seen lots of 'odd' behaviour, including permanent 100% CPU
usage by Apache! It has taken *days* to track down the problem to the
snippet below. If there is anything elso I can do to help fix it please
let me know...
Reproduce code:
---
$r = new ReflectionClass('A');
$methods = $r->getMethods();
foreach($methods as $method)
{
$parameters = $method->getParameters();
foreach($parameters as $p)
{
if($p->isDefaultValueAvailable())
$p->getDefaultValue();
}
}
class A
{
function foo($p=null, $q=false)
{
}
}
Expected result:
No output at all -- I've trimed all the output code out.
Actual result:
--
$ php bug2.php
Warning: String is not zero-terminated (ZÌ*) (source:
/tmp/php5-200508110030/Zend/zend_variables.h:35) in Unknown on line 0
[Thu Aug 11 13:18:58 2005] Script: 'bug2.php'
---
/tmp/php5-200508110030/Zend/zend_variables.h(35) : Block 0x08514F30
status:
/tmp/php5-200508110030/Zend/zend_variables.c(36) : Actual location
(location was relayed)
Beginning: Cached (allocated on Zend/zend_language_scanner.c:4689, 5
bytes)
End: OK
---
Warning: String is not zero-terminated (ZZÌ*) (source:
/tmp/php5-200508110030/Zend/zend_variables.h:35) in Unknown on line 0
[Thu Aug 11 13:18:58 2005] Script: 'bug2.php'
---
/tmp/php5-200508110030/Zend/zend_variables.h(35) : Block 0x085150C8
status:
/tmp/php5-200508110030/Zend/zend_variables.c(36) : Actual location
(location was relayed)
Beginning: Cached (allocated on Zend/zend_language_scanner.c:4689, 6
bytes)
End: OK
---
--
Edit bug report at http://bugs.php.net/?id=34078&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34078&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34078&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34078&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34078&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34078&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34078&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34078&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34078&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34078&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34078&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34078&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34078&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34078&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34078&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34078&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34078&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34078&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34078&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34078&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34078&r=mysqlcfg
#31618 [Fbk->Opn]: is_readable() results based on ownership of calling script, not file
ID: 31618 User updated by: kibab at icehouse dot net Reported By: kibab at icehouse dot net -Status: Feedback +Status: Open Bug Type: Filesystem function related Operating System: redhat enterprise PHP Version: 5CVS-2005-03-14 New Comment: Ok. It says (see http://www.ewu.edu/web/tools/bug31618_3.php): Warning: fopen() [function.fopen]: SAFE MODE Restriction in effect. The script whose uid/gid is 687/694 is not allowed to access /usr/share/pear/commonfile.php owned by uid/gid 0/0 in /var/www/sites/web/tools/bug31618_3.php on line 3 Warning: fopen(/usr/share/pear/commonfile.php) [function.fopen]: failed to open stream: Resource temporarily unavailable in /var/www/sites/web/tools/bug31618_3.php on line 3 Previous Comments: [2005-08-10 20:44:05] [EMAIL PROTECTED] Of course, I meant this: [2005-08-10 20:36:39] [EMAIL PROTECTED] Could you plz also try this: And post the error message here. Thanks. [2005-08-10 20:24:48] kibab at icehouse dot net Ok, here's a new "complete" example for you. First, we need to do some setup as this is based on permissions, ownership, and safe mode: cd # note, I used cd /usr/share/pear echo "TESTING" > commonfile.php chmod a+r commonfile.php Then: $ ls -l commonfile* -rw-rw-r--1 root root8 Aug 10 10:54 commonfile.php And, permissions on the source PHP file in use: $ ls -l bug31618.php -rw-rw-r--1 kpederson financialaid 576 Aug 10 10:50 bug31618.php I used the following relevant settings: $ grep -iE "safe|include" /etc/php.ini | grep -v "^;" safe_mode = On safe_mode_gid = On safe_mode_include_dir = /usr/share/pear safe_mode_exec_dir = "/usr/local/php_exe/bin" safe_mode_allowed_env_vars = PHP_ safe_mode_protected_env_vars = LD_LIBRARY_PATH include_path = ".:/usr/share/pear/:/usr/share/pear/ewu_lib:/var/lib/php_secure" sql.safe_mode = Off Now, grab my PHP script from the following URL: http://www.ewu.edu/web/tools/bug31618.php.txt It's output looks like the following (as can be seen from http://www.ewu.edu/web/tools/bug31618.php): is_readable: /usr/share/pear/commonfile.php (false) TESTING Now, if I change the ownership to root:root (as I did for bug31618_2.php, eg. as seen by http://www.ewu.edu/web/tools/bug31618_2.php): is_readable: /usr/share/pear/commonfile.php (true) TESTING Thus, the results are based on ownership of the calling php script, not the file attempting to be read, despite being in safe_mode_include_dir. [2005-08-08 19:56:08] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2005-05-19 06:14:33] kibab at icehouse dot net >From memory, all files were mode 664 and all directories had permissions of 775 being owned by root:root. However, I no longer have that same structure to prove that. If you like, I can setup an almost identical test case using the code that I included below (but using my new structure). The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/31618 -- Edit this bug report at http://bugs.php.net/?id=31618&edit=1
#34075 [Fbk->Opn]: The ext/standard/tests/file/bug22414.phpt script fails
ID: 34075 User updated by: RVaughn at pheedo dot com Reported By: RVaughn at pheedo dot com -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: RHEL 3.0 PHP Version: 4.4.0 New Comment: I have run this test with 'make test' as part of the whole suite, and also directly with: # ./sapi/cli/php -c /etc/php.ini ext/standard/tests/file/bug22414.phpt and # ./sapi/cli/php ext/standard/tests/file/bug22414.phpt Fails in all three cases for PHP 4.4, 4.3.11, and 4.3.8. The first test works, the second one which uses md5_file() to create a hash over the php executable itself, fails with the errors I reported. I suspect it's something particular to RHEL 3.0 but have not had a chance to test on a Fedora Core 2 system yet. Previous Comments: [2005-08-10 23:34:21] [EMAIL PROTECTED] How do you run this test? [2005-08-10 23:22:20] RVaughn at pheedo dot com Description: The ext/standard/tests/file/bug22414.phpt script in the test suite always fails on Red Hat Enterprise 3.0. I didn't report this originally as I thought it was a configuration or installation problem with our system when working on PHP 4.4 but I'm trying to run it under PHP 4.3.8 and 4.3.11 and it also fails in the same manner, which leads me to believe it's either got a bug or isn't written correctly to work on RHEL 3.0. I've read Bug #22582: Problem with bug22414.phpt and while those changes are incorporated they do not address the problem on RHEL 3.0. Other bug reports also do not address the problem. I tried making a link from /usr/local/php/bin/php to the new executable but that didn't solve the problem. Reproduce code: --- Please see the ext/standard/tests/file/bug22414.phpt from the PHP 4.4, 4.3.8, or 4.3.11 distributions, it fails on all three. Expected result: EXPECTED OUTPUT HELLO Works Actual result: -- ACTUAL OUTPUT HELLO sh: line 1: /usr/local/php/bin/php: No such file or directory Does not work This fails exactly this way under PHP 4.3.8, 4.3.11 and 4.4 on RHEL 3.0 which is why I believe it's a bug with the script. The script is identical in all three PHP source code distributions. I tried to fix the problem by copying the new php executable # mkdir -p /usr/local/php/bin # cp sapi/cli/php /usr/local/php/bin/php This causes this error on RHEL 3.0 for PHP 4.4, 4.3.11 and 4.3.8: --FILE-- sh: line 1: -n: command not found sh: line 1: -n: command not found Warning: md5_file(): Unable to open file in /usr/src/redhat/SOURCES/php-4.3.8/ext/standard/tests/file/bug22414.phpt on line 24 Does not work Please don't yell at me, I'm just trying to report what I'm guessing is a potential bug particular to RHEL 3.0 and have written my own passthru() function tests which seem to work just fine. Cheers, Rob V. -- Edit this bug report at http://bugs.php.net/?id=34075&edit=1
#34068 [Opn->Csd]: Numeric string as array key not cast to integer in wddx_deserialize()
ID: 34068
Updated by: [EMAIL PROTECTED]
Reported By: clemens at gutweiler dot net
-Status: Open
+Status: Closed
Bug Type: WDDX related
Operating System: *
PHP Version: 5CVS-2005-08-10
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2005-08-10 15:46:42] [EMAIL PROTECTED]
Nevermind that, we have it documented as expected behaviour.
WDDX should really be consistent with how PHP handles this..
[2005-08-10 15:39:29] [EMAIL PROTECTED]
Actually it's not WDDX issue, but general issue with numeric array
index not staying as string but getting silently changed to integer:
'abc', 'abc' => '123');
var_dump($a);
?>
Outputs:
array(2) {
[123]=>
string(3) "abc"
["abc"]=>
string(3) "123"
}
Although this is pretty old issue, Dmitry, can you check?
[2005-08-10 13:58:47] clemens at gutweiler dot net
Description:
The vartype of the 123 key changed after serialization, it should be
consistent.
Reproduce code:
---
'zahl',
'Foo' => 'bar',
);
var_dump( $data );
var_dump( wddx_deserialize( wddx_serialize_value( $data ) ) );
highlight_file( __FILE__ );
?>
Expected result:
array(2) {
["123"]=>
string(4) "zahl"
["Foo"]=>
string(3) "bar"
}
array(2) {
["123"]=>
string(4) "zahl"
["Foo"]=>
string(3) "bar"
}
Actual result:
--
array(2) {
[123]=>
string(4) "zahl"
["Foo"]=>
string(3) "bar"
}
array(2) {
["123"]=>
string(4) "zahl"
["Foo"]=>
string(3) "bar"
}
--
Edit this bug report at http://bugs.php.net/?id=34068&edit=1
#33468 [Com]: preg_match on long strings fails
ID: 33468
Comment by: bugs dot php dot net at chsc dot dk
Reported By: mjsherman at chartermi dot net
Status: Assigned
Bug Type: PCRE related
Operating System: *
PHP Version: 5CVS, 4CVS (2005-08-09)
Assigned To: andrei
New Comment:
An even simpler testcase:
$data = str_repeat('a', );
preg_match('/(?:[a])*/', $data, $reg);
Notice that the parenthesis is non-capturing, i.e. we don't even put a
lot of elements in the $reg array.
Previous Comments:
[2005-08-09 10:36:28] [EMAIL PROTECTED]
Happens also with the new PCRE 6.2 lib which was bundled in PHP CVS
today.
[2005-06-24 19:30:06] [EMAIL PROTECTED]
Andrei, could you check it plz.
As far as I understand, this is something not related to PHP, but just
another PCRE limitation.
[2005-06-24 19:21:22] mjsherman at chartermi dot net
Just tested with 5.1.0beta2
Same problem.
[2005-06-24 18:28:01] [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
[2005-06-24 18:24:34] mjsherman at chartermi dot net
Description:
preg_match, if passed a long subject string, fails unexpectedly.
I have read through the PCRE limitations, and can't see that this is
one of them. I have tried increasing memory limit (to increase the
stack) with the same results.
Cutoff and examples are below:
Reproduce code:
---
$subject = str_repeat('a',100);
$subject .= str_repeat('b', 4370);
$subject .= str_repeat('a', 100);
if (preg_match('/(.*).*?\1/',$subject)) {
echo "OK\n";
}
Expected result:
"OK" to be printed after matching 100 "a"s.
If 4370 is changed to 4369, then "OK" is printed.
Actual result:
--
With 4370 'b's, nothing is printed (failed preg_match)
With 4369 'b's, "OK" is printed (worked).
--
Edit this bug report at http://bugs.php.net/?id=33468&edit=1
#34075 [Opn->Fbk]: The ext/standard/tests/file/bug22414.phpt script fails
ID: 34075 Updated by: [EMAIL PROTECTED] Reported By: RVaughn at pheedo dot com -Status: Open +Status: Feedback Bug Type: Unknown/Other Function Operating System: RHEL 3.0 PHP Version: 4.4.0 New Comment: How do you run this test? Previous Comments: [2005-08-10 23:22:20] RVaughn at pheedo dot com Description: The ext/standard/tests/file/bug22414.phpt script in the test suite always fails on Red Hat Enterprise 3.0. I didn't report this originally as I thought it was a configuration or installation problem with our system when working on PHP 4.4 but I'm trying to run it under PHP 4.3.8 and 4.3.11 and it also fails in the same manner, which leads me to believe it's either got a bug or isn't written correctly to work on RHEL 3.0. I've read Bug #22582: Problem with bug22414.phpt and while those changes are incorporated they do not address the problem on RHEL 3.0. Other bug reports also do not address the problem. I tried making a link from /usr/local/php/bin/php to the new executable but that didn't solve the problem. Reproduce code: --- Please see the ext/standard/tests/file/bug22414.phpt from the PHP 4.4, 4.3.8, or 4.3.11 distributions, it fails on all three. Expected result: EXPECTED OUTPUT HELLO Works Actual result: -- ACTUAL OUTPUT HELLO sh: line 1: /usr/local/php/bin/php: No such file or directory Does not work This fails exactly this way under PHP 4.3.8, 4.3.11 and 4.4 on RHEL 3.0 which is why I believe it's a bug with the script. The script is identical in all three PHP source code distributions. I tried to fix the problem by copying the new php executable # mkdir -p /usr/local/php/bin # cp sapi/cli/php /usr/local/php/bin/php This causes this error on RHEL 3.0 for PHP 4.4, 4.3.11 and 4.3.8: --FILE-- sh: line 1: -n: command not found sh: line 1: -n: command not found Warning: md5_file(): Unable to open file in /usr/src/redhat/SOURCES/php-4.3.8/ext/standard/tests/file/bug22414.phpt on line 24 Does not work Please don't yell at me, I'm just trying to report what I'm guessing is a potential bug particular to RHEL 3.0 and have written my own passthru() function tests which seem to work just fine. Cheers, Rob V. -- Edit this bug report at http://bugs.php.net/?id=34075&edit=1
#34075 [NEW]: The ext/standard/tests/file/bug22414.phpt script fails
From: RVaughn at pheedo dot com Operating system: RHEL 3.0 PHP version: 4.4.0 PHP Bug Type: Unknown/Other Function Bug description: The ext/standard/tests/file/bug22414.phpt script fails Description: The ext/standard/tests/file/bug22414.phpt script in the test suite always fails on Red Hat Enterprise 3.0. I didn't report this originally as I thought it was a configuration or installation problem with our system when working on PHP 4.4 but I'm trying to run it under PHP 4.3.8 and 4.3.11 and it also fails in the same manner, which leads me to believe it's either got a bug or isn't written correctly to work on RHEL 3.0. I've read Bug #22582: Problem with bug22414.phpt and while those changes are incorporated they do not address the problem on RHEL 3.0. Other bug reports also do not address the problem. I tried making a link from /usr/local/php/bin/php to the new executable but that didn't solve the problem. Reproduce code: --- Please see the ext/standard/tests/file/bug22414.phpt from the PHP 4.4, 4.3.8, or 4.3.11 distributions, it fails on all three. Expected result: EXPECTED OUTPUT HELLO Works Actual result: -- ACTUAL OUTPUT HELLO sh: line 1: /usr/local/php/bin/php: No such file or directory Does not work This fails exactly this way under PHP 4.3.8, 4.3.11 and 4.4 on RHEL 3.0 which is why I believe it's a bug with the script. The script is identical in all three PHP source code distributions. I tried to fix the problem by copying the new php executable # mkdir -p /usr/local/php/bin # cp sapi/cli/php /usr/local/php/bin/php This causes this error on RHEL 3.0 for PHP 4.4, 4.3.11 and 4.3.8: --FILE-- sh: line 1: -n: command not found sh: line 1: -n: command not found Warning: md5_file(): Unable to open file in /usr/src/redhat/SOURCES/php-4.3.8/ext/standard/tests/file/bug22414.phpt on line 24 Does not work Please don't yell at me, I'm just trying to report what I'm guessing is a potential bug particular to RHEL 3.0 and have written my own passthru() function tests which seem to work just fine. Cheers, Rob V. -- Edit bug report at http://bugs.php.net/?id=34075&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34075&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34075&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34075&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34075&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34075&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34075&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34075&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34075&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34075&r=support Expected behavior: http://bugs.php.net/fix.php?id=34075&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34075&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34075&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34075&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34075&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34075&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34075&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34075&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34075&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34075&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34075&r=mysqlcfg
#31618 [Fbk]: is_readable() results based on ownership of calling script, not file
ID: 31618 Updated by: [EMAIL PROTECTED] Reported By: kibab at icehouse dot net Status: Feedback Bug Type: Filesystem function related Operating System: redhat enterprise PHP Version: 5CVS-2005-03-14 New Comment: Of course, I meant this: Previous Comments: [2005-08-10 20:36:39] [EMAIL PROTECTED] Could you plz also try this: And post the error message here. Thanks. [2005-08-10 20:24:48] kibab at icehouse dot net Ok, here's a new "complete" example for you. First, we need to do some setup as this is based on permissions, ownership, and safe mode: cd # note, I used cd /usr/share/pear echo "TESTING" > commonfile.php chmod a+r commonfile.php Then: $ ls -l commonfile* -rw-rw-r--1 root root8 Aug 10 10:54 commonfile.php And, permissions on the source PHP file in use: $ ls -l bug31618.php -rw-rw-r--1 kpederson financialaid 576 Aug 10 10:50 bug31618.php I used the following relevant settings: $ grep -iE "safe|include" /etc/php.ini | grep -v "^;" safe_mode = On safe_mode_gid = On safe_mode_include_dir = /usr/share/pear safe_mode_exec_dir = "/usr/local/php_exe/bin" safe_mode_allowed_env_vars = PHP_ safe_mode_protected_env_vars = LD_LIBRARY_PATH include_path = ".:/usr/share/pear/:/usr/share/pear/ewu_lib:/var/lib/php_secure" sql.safe_mode = Off Now, grab my PHP script from the following URL: http://www.ewu.edu/web/tools/bug31618.php.txt It's output looks like the following (as can be seen from http://www.ewu.edu/web/tools/bug31618.php): is_readable: /usr/share/pear/commonfile.php (false) TESTING Now, if I change the ownership to root:root (as I did for bug31618_2.php, eg. as seen by http://www.ewu.edu/web/tools/bug31618_2.php): is_readable: /usr/share/pear/commonfile.php (true) TESTING Thus, the results are based on ownership of the calling php script, not the file attempting to be read, despite being in safe_mode_include_dir. [2005-08-08 19:56:08] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2005-05-19 06:14:33] kibab at icehouse dot net >From memory, all files were mode 664 and all directories had permissions of 775 being owned by root:root. However, I no longer have that same structure to prove that. If you like, I can setup an almost identical test case using the code that I included below (but using my new structure). [2005-05-17 17:18:48] [EMAIL PROTECTED] What are the permissions of all the directories in that path? (/var/lib/php_packages/) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/31618 -- Edit this bug report at http://bugs.php.net/?id=31618&edit=1
#31618 [Opn->Fbk]: is_readable() results based on ownership of calling script, not file
ID: 31618 Updated by: [EMAIL PROTECTED] Reported By: kibab at icehouse dot net -Status: Open +Status: Feedback Bug Type: Filesystem function related Operating System: redhat enterprise PHP Version: 5CVS-2005-03-14 New Comment: Could you plz also try this: And post the error message here. Thanks. Previous Comments: [2005-08-10 20:24:48] kibab at icehouse dot net Ok, here's a new "complete" example for you. First, we need to do some setup as this is based on permissions, ownership, and safe mode: cd # note, I used cd /usr/share/pear echo "TESTING" > commonfile.php chmod a+r commonfile.php Then: $ ls -l commonfile* -rw-rw-r--1 root root8 Aug 10 10:54 commonfile.php And, permissions on the source PHP file in use: $ ls -l bug31618.php -rw-rw-r--1 kpederson financialaid 576 Aug 10 10:50 bug31618.php I used the following relevant settings: $ grep -iE "safe|include" /etc/php.ini | grep -v "^;" safe_mode = On safe_mode_gid = On safe_mode_include_dir = /usr/share/pear safe_mode_exec_dir = "/usr/local/php_exe/bin" safe_mode_allowed_env_vars = PHP_ safe_mode_protected_env_vars = LD_LIBRARY_PATH include_path = ".:/usr/share/pear/:/usr/share/pear/ewu_lib:/var/lib/php_secure" sql.safe_mode = Off Now, grab my PHP script from the following URL: http://www.ewu.edu/web/tools/bug31618.php.txt It's output looks like the following (as can be seen from http://www.ewu.edu/web/tools/bug31618.php): is_readable: /usr/share/pear/commonfile.php (false) TESTING Now, if I change the ownership to root:root (as I did for bug31618_2.php, eg. as seen by http://www.ewu.edu/web/tools/bug31618_2.php): is_readable: /usr/share/pear/commonfile.php (true) TESTING Thus, the results are based on ownership of the calling php script, not the file attempting to be read, despite being in safe_mode_include_dir. [2005-08-08 19:56:08] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2005-05-19 06:14:33] kibab at icehouse dot net >From memory, all files were mode 664 and all directories had permissions of 775 being owned by root:root. However, I no longer have that same structure to prove that. If you like, I can setup an almost identical test case using the code that I included below (but using my new structure). [2005-05-17 17:18:48] [EMAIL PROTECTED] What are the permissions of all the directories in that path? (/var/lib/php_packages/) [2005-01-20 22:32:24] kibab at icehouse dot net Maybe this isn't directly related, but fopen($myfilename,"r") also fails, even though include($myfilename) works. Again, $myfilename is in the safe_mode_include_dir, so fopen should be able to open it. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/31618 -- Edit this bug report at http://bugs.php.net/?id=31618&edit=1
#31618 [Fbk->Opn]: is_readable() results based on ownership of calling script, not file
ID: 31618
User updated by: kibab at icehouse dot net
Reported By: kibab at icehouse dot net
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: redhat enterprise
PHP Version: 5CVS-2005-03-14
New Comment:
Ok, here's a new "complete" example for you.
First, we need to do some setup as this is based on
permissions, ownership, and safe mode:
cd
# note, I used cd /usr/share/pear
echo "TESTING" > commonfile.php
chmod a+r commonfile.php
Then: $ ls -l commonfile*
-rw-rw-r--1 root root8 Aug 10 10:54
commonfile.php
And, permissions on the source PHP file in use:
$ ls -l bug31618.php
-rw-rw-r--1 kpederson financialaid 576 Aug 10
10:50 bug31618.php
I used the following relevant settings:
$ grep -iE "safe|include" /etc/php.ini | grep -v "^;"
safe_mode = On
safe_mode_gid = On
safe_mode_include_dir = /usr/share/pear
safe_mode_exec_dir = "/usr/local/php_exe/bin"
safe_mode_allowed_env_vars = PHP_
safe_mode_protected_env_vars = LD_LIBRARY_PATH
include_path =
".:/usr/share/pear/:/usr/share/pear/ewu_lib:/var/lib/php_secure"
sql.safe_mode = Off
Now, grab my PHP script from the following URL:
http://www.ewu.edu/web/tools/bug31618.php.txt
It's output looks like the following (as can be seen from
http://www.ewu.edu/web/tools/bug31618.php):
is_readable: /usr/share/pear/commonfile.php (false)
TESTING
Now, if I change the ownership to root:root (as I did for
bug31618_2.php, eg. as seen by
http://www.ewu.edu/web/tools/bug31618_2.php):
is_readable: /usr/share/pear/commonfile.php (true)
TESTING
Thus, the results are based on ownership of the calling
php script, not the file attempting to be read, despite
being in safe_mode_include_dir.
Previous Comments:
[2005-08-08 19:56:08] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-05-19 06:14:33] kibab at icehouse dot net
>From memory, all files were mode 664 and all directories
had permissions of 775 being owned by root:root. However,
I no longer have that same structure to prove that. If
you like, I can setup an almost identical test case using
the code that I included below (but using my new
structure).
[2005-05-17 17:18:48] [EMAIL PROTECTED]
What are the permissions of all the directories in that path?
(/var/lib/php_packages/)
[2005-01-20 22:32:24] kibab at icehouse dot net
Maybe this isn't directly related, but
fopen($myfilename,"r") also fails, even though
include($myfilename) works. Again, $myfilename is in the
safe_mode_include_dir, so fopen should be able to open it.
[2005-01-19 23:05:35] kibab at icehouse dot net
Description:
is_readable($myfilename) in the repro code returns true if
the script calling it is owned by root, but false if it is
owned by someone else.
Permissions are:
-rw-r--r--1 root root 5452 Jan 13
13:02 /var/lib/php_packages/test_templ2.php
drwxr-xr-x4 root root 4096 Jan 19
08:19 /var/lib/php_packages
drwxr-xr-x 27 root root 4096 Jan 12
09:27 /var/lib
drwxr-xr-x 24 root root 4096 Sep 22
13:06 /var
drwxr-xr-x 20 root root 4096 Oct 29 09:48 /
Relevant Settings:
include_path =
".:/var/lib/php_packages:/var/lib/php_packages/pear"
safe_mode = On
safe_mode_gid = On
safe_mode_include_dir = /var/lib/php_packages
Reproduce code:
---
test.php ###
$myfilename = '/var/lib/php_packages/test_templ2.php';
if (is_readable($myfilename)) {
echo "is_readable: $myfilename (true)";
} else {
echo "is_readable: $myfilename (false)";
}
include($myfilename);
### test_templ2.php ###
TESTING!
Expected result:
I would expect is_readable() to return true in both
instances. The uid/gid check shouldn't matter despite
safe mode, as the file is in safe_mode_include_dir, and
even if it wasn't, the is_readable documentation says that
it does NOT take into account safe_mode restrictions.
Actual result:
-
#34071 [Opn->Fbk]: buffering is destroyed when using ob_gzhandler and ob_clean
ID: 34071 Updated by: [EMAIL PROTECTED] Reported By: dennis at nocertainty dot com -Status: Open +Status: Feedback Bug Type: Output Control Operating System: Windows XP SP2 PHP Version: 5CVS-2005-08-10 (dev) New Comment: Then provide more info about it; look into the apache logs; try on another server and with another PHP version etc etc. As I've already said, it works perfectly here. Previous Comments: [2005-08-10 19:47:05] dennis at nocertainty dot com Also, I disabled PHP4 in my http.conf file, and it still doesn't work properly in PHP5Dev. So I still believe there's a bug in PHP5. [2005-08-10 19:44:50] dennis at nocertainty dot com Rasmus is right. The telnet thing works because ob_gzhandler doesn't do anything. As soon as a specify a Content-Encoding: gzip header, nothing gets displayed again. So it's not my browser that's causing the problem. [2005-08-10 19:21:08] [EMAIL PROTECTED] Not PHP problem then. [2005-08-10 19:20:43] [EMAIL PROTECTED] That's not a very good test since ob_gzhandler checks the request's accept-encoding and since your telnet test didn't specify that you could accept gzip or deflate, then the gzhandler simply didn't do anything. [2005-08-10 19:03:27] dennis at nocertainty dot com You're right, that works, and I get the correct result. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/34071 -- Edit this bug report at http://bugs.php.net/?id=34071&edit=1
#26771 [Ver->Sus]: register_tick_funtions crashes apache2 child process
ID: 26771 Updated by: [EMAIL PROTECTED] Reported By: info at tphnet dot com -Status: Verified +Status: Suspended Bug Type: Apache2 related Operating System: * (ZTS only!) PHP Version: 5CVS, 4CVS (2005-06-17) New Comment: You are probably right that the tick stuff is broken in ZTS mode. But I doubt anybody is all that interested in fixing it as it is a very fringe feature in a very fringe environment. You can always hope, but chances are you will need to dig into the code yourself and send us a patch to get any movement on this. Previous Comments: [2005-08-10 19:54:15] fredrik at demomusic dot nu Final comments from apache.org: --- Additional Comment #2 From Fredrik Wollsén 2005-08-10 14:56 [reply] --- Correct me from wrong, but is not Apache 1.3 NOT a MPM? At least it isn't threaded, is this not required by the definition of MPM? Not too into the subject of MPM's. ... --- Additional Comment #4 From Will Rowe 2005-08-10 16:03 [reply] --- FYI, we forgive your confusion; "Application error Apache.exe at address x" might look like Apache, but notice the address. Yes; it's php itself jumping into nowhere. PHP has platform bugs just like Apache, please don't blame us because there is a Windows-specific bug, any more than you would waste Microsoft's time with this. --- Additional Comment #5 From Fredrik Wollsén 2005-08-10 19:51 [reply] --- That explains it well enough for me to aim this bug-report wholly to the php-side. Thank you! [2005-08-10 14:46:57] fredrik at demomusic dot nu It is no longer an Apache-bug: Comment From jorton at redhat dot com 2005-08-10 14:19 It's a PHP thread-safety issue, it's not Windows-specific, it breaks on Unixes with threaded MPMs too. [2005-08-10 14:10:20] fredrik at demomusic dot nu I also reported this to Apache (as it most likely is a bug in the phpXapacheX.dll binaries that are bundled with Apache): http://issues.apache.org/bugzilla/show_bug.cgi?id=36118. This can also be voted upon: http://issues.apache.org/bugzilla/votes.cgi?action=show_user&bug_id=36118, in order to get the Apache-delevopers attention. [2005-08-10 13:24:23] fredrik at demomusic dot nu Some last information: solace at ezmail dot ru (http://bugs.php.net/bug.php?id=28567) has made an excellent php-profiler class, available on www.phpclasses.org. I have rewritten that profiler to side-kick as a debug-logger, an invaluable tool that I use a lot in my dev work. As soon as I am finished, it will be available for everyone, as solace's stuff is GPL. Both uses ticks. My point here is that the use of ticks on Windows is of great value, and therefore this matter should not preferably only lead to a change in the documentation (as some have suggested), but to the state where ticks work when running php as a module under apache! solace's makes an important comment in his own bugreport on this matter (marked as bogus for some reason): ""How to generate a backtrace" page is for *nix platforms, but this bug appears ONLY on Windows. All I have is event in system log "Application error Apache.exe at address x". Even Apache doesn't report it in error.log or access.log, like bug script wasn't accessed at all (Apache 1.3.27). But Windows wants to send report to Microsoft twice. And I'm not alone with this bug..." Also, this bug-report's name should preferable be "Ticks crashed Apache when running php as a module". More accurate, I believe. That's all for now... [2005-08-10 13:03:38] fredrik at demomusic dot nu Unless Zend is automatically disabled when running as cgi? I couldn't find any Zend-configurations in httpd.conf, and so I presumed that this was not the case. If I am mistaken, and this is solely a Zend-problem, please inform me and I will be posting a bug report to the Zend-team. Thank you! The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/26771 -- Edit this bug report at http://bugs.php.net/?id=26771&edit=1
#26771 [Com]: register_tick_funtions crashes apache2 child process
ID: 26771 Comment by: fredrik at demomusic dot nu Reported By: info at tphnet dot com Status: Verified Bug Type: Apache2 related Operating System: * (ZTS only!) PHP Version: 5CVS, 4CVS (2005-06-17) New Comment: Final comments from apache.org: --- Additional Comment #2 From Fredrik Wollsén 2005-08-10 14:56 [reply] --- Correct me from wrong, but is not Apache 1.3 NOT a MPM? At least it isn't threaded, is this not required by the definition of MPM? Not too into the subject of MPM's. ... --- Additional Comment #4 From Will Rowe 2005-08-10 16:03 [reply] --- FYI, we forgive your confusion; "Application error Apache.exe at address x" might look like Apache, but notice the address. Yes; it's php itself jumping into nowhere. PHP has platform bugs just like Apache, please don't blame us because there is a Windows-specific bug, any more than you would waste Microsoft's time with this. --- Additional Comment #5 From Fredrik Wollsén 2005-08-10 19:51 [reply] --- That explains it well enough for me to aim this bug-report wholly to the php-side. Thank you! Previous Comments: [2005-08-10 14:46:57] fredrik at demomusic dot nu It is no longer an Apache-bug: Comment From jorton at redhat dot com 2005-08-10 14:19 It's a PHP thread-safety issue, it's not Windows-specific, it breaks on Unixes with threaded MPMs too. [2005-08-10 14:10:20] fredrik at demomusic dot nu I also reported this to Apache (as it most likely is a bug in the phpXapacheX.dll binaries that are bundled with Apache): http://issues.apache.org/bugzilla/show_bug.cgi?id=36118. This can also be voted upon: http://issues.apache.org/bugzilla/votes.cgi?action=show_user&bug_id=36118, in order to get the Apache-delevopers attention. [2005-08-10 13:24:23] fredrik at demomusic dot nu Some last information: solace at ezmail dot ru (http://bugs.php.net/bug.php?id=28567) has made an excellent php-profiler class, available on www.phpclasses.org. I have rewritten that profiler to side-kick as a debug-logger, an invaluable tool that I use a lot in my dev work. As soon as I am finished, it will be available for everyone, as solace's stuff is GPL. Both uses ticks. My point here is that the use of ticks on Windows is of great value, and therefore this matter should not preferably only lead to a change in the documentation (as some have suggested), but to the state where ticks work when running php as a module under apache! solace's makes an important comment in his own bugreport on this matter (marked as bogus for some reason): ""How to generate a backtrace" page is for *nix platforms, but this bug appears ONLY on Windows. All I have is event in system log "Application error Apache.exe at address x". Even Apache doesn't report it in error.log or access.log, like bug script wasn't accessed at all (Apache 1.3.27). But Windows wants to send report to Microsoft twice. And I'm not alone with this bug..." Also, this bug-report's name should preferable be "Ticks crashed Apache when running php as a module". More accurate, I believe. That's all for now... [2005-08-10 13:03:38] fredrik at demomusic dot nu Unless Zend is automatically disabled when running as cgi? I couldn't find any Zend-configurations in httpd.conf, and so I presumed that this was not the case. If I am mistaken, and this is solely a Zend-problem, please inform me and I will be posting a bug report to the Zend-team. Thank you! [2005-08-10 13:01:39] fredrik at demomusic dot nu What is with the "* (ZTS only!)"? Does it stand for Zend Thread Safety?? I am not familiar with ZTS, but shouldn't this be marked as an Windows-issue? It certainly should, is my opinion. As it works nicely when running PHP as CGI, same compile-options, same php.ini, I don't see how this could be a Zend Engine-problem... It is clearly a Windows Apache+PHP as module combination problem. Please update this report. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/26771 -- Edit this bug report at http://bugs.php.net/?id=26771&edit=1
#34071 [Bgs->Opn]: buffering is destroyed when using ob_gzhandler and ob_clean
ID: 34071 User updated by: dennis at nocertainty dot com Reported By: dennis at nocertainty dot com -Status: Bogus +Status: Open Bug Type: Output Control Operating System: Windows XP SP2 PHP Version: 5CVS-2005-08-10 (dev) New Comment: Also, I disabled PHP4 in my http.conf file, and it still doesn't work properly in PHP5Dev. So I still believe there's a bug in PHP5. Previous Comments: [2005-08-10 19:44:50] dennis at nocertainty dot com Rasmus is right. The telnet thing works because ob_gzhandler doesn't do anything. As soon as a specify a Content-Encoding: gzip header, nothing gets displayed again. So it's not my browser that's causing the problem. [2005-08-10 19:21:08] [EMAIL PROTECTED] Not PHP problem then. [2005-08-10 19:20:43] [EMAIL PROTECTED] That's not a very good test since ob_gzhandler checks the request's accept-encoding and since your telnet test didn't specify that you could accept gzip or deflate, then the gzhandler simply didn't do anything. [2005-08-10 19:03:27] dennis at nocertainty dot com You're right, that works, and I get the correct result. [2005-08-10 18:56:29] [EMAIL PROTECTED] Are you sure there is nothing shown in the "View Source" tab? I'm almost sure your browser just hides binary output from you. So try this: telnet localhost 80 GET /script.php HTTP/1.0 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/34071 -- Edit this bug report at http://bugs.php.net/?id=34071&edit=1
#34071 [Bgs]: buffering is destroyed when using ob_gzhandler and ob_clean
ID: 34071 User updated by: dennis at nocertainty dot com Reported By: dennis at nocertainty dot com Status: Bogus Bug Type: Output Control Operating System: Windows XP SP2 PHP Version: 5CVS-2005-08-10 (dev) New Comment: Rasmus is right. The telnet thing works because ob_gzhandler doesn't do anything. As soon as a specify a Content-Encoding: gzip header, nothing gets displayed again. So it's not my browser that's causing the problem. Previous Comments: [2005-08-10 19:21:08] [EMAIL PROTECTED] Not PHP problem then. [2005-08-10 19:20:43] [EMAIL PROTECTED] That's not a very good test since ob_gzhandler checks the request's accept-encoding and since your telnet test didn't specify that you could accept gzip or deflate, then the gzhandler simply didn't do anything. [2005-08-10 19:03:27] dennis at nocertainty dot com You're right, that works, and I get the correct result. [2005-08-10 18:56:29] [EMAIL PROTECTED] Are you sure there is nothing shown in the "View Source" tab? I'm almost sure your browser just hides binary output from you. So try this: telnet localhost 80 GET /script.php HTTP/1.0 [2005-08-10 18:50:14] dennis at nocertainty dot com Yes, that works. But as soon as I use ob_gzhandler, instead of foo, nothing is displayed. I run PHP4 and PHP5 at the same time (port 80 is PHP4.3.4, port 83 is PHP5Dev). Could it be that the bug is caused by my PHP4 installation? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/34071 -- Edit this bug report at http://bugs.php.net/?id=34071&edit=1
#34071 [Opn->Bgs]: buffering is destroyed when using ob_gzhandler and ob_clean
ID: 34071 Updated by: [EMAIL PROTECTED] Reported By: dennis at nocertainty dot com -Status: Open +Status: Bogus Bug Type: Output Control Operating System: Windows XP SP2 PHP Version: 5CVS-2005-08-10 (dev) New Comment: Not PHP problem then. Previous Comments: [2005-08-10 19:20:43] [EMAIL PROTECTED] That's not a very good test since ob_gzhandler checks the request's accept-encoding and since your telnet test didn't specify that you could accept gzip or deflate, then the gzhandler simply didn't do anything. [2005-08-10 19:03:27] dennis at nocertainty dot com You're right, that works, and I get the correct result. [2005-08-10 18:56:29] [EMAIL PROTECTED] Are you sure there is nothing shown in the "View Source" tab? I'm almost sure your browser just hides binary output from you. So try this: telnet localhost 80 GET /script.php HTTP/1.0 [2005-08-10 18:50:14] dennis at nocertainty dot com Yes, that works. But as soon as I use ob_gzhandler, instead of foo, nothing is displayed. I run PHP4 and PHP5 at the same time (port 80 is PHP4.3.4, port 83 is PHP5Dev). Could it be that the bug is caused by my PHP4 installation? [2005-08-10 18:39:16] [EMAIL PROTECTED] Still can't reproduce, even with FCGI. Does this work for you: ? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/34071 -- Edit this bug report at http://bugs.php.net/?id=34071&edit=1
#34071 [Opn]: buffering is destroyed when using ob_gzhandler and ob_clean
ID: 34071 Updated by: [EMAIL PROTECTED] Reported By: dennis at nocertainty dot com Status: Open Bug Type: Output Control Operating System: Windows XP SP2 PHP Version: 5CVS-2005-08-10 (dev) New Comment: That's not a very good test since ob_gzhandler checks the request's accept-encoding and since your telnet test didn't specify that you could accept gzip or deflate, then the gzhandler simply didn't do anything. Previous Comments: [2005-08-10 19:03:27] dennis at nocertainty dot com You're right, that works, and I get the correct result. [2005-08-10 18:56:29] [EMAIL PROTECTED] Are you sure there is nothing shown in the "View Source" tab? I'm almost sure your browser just hides binary output from you. So try this: telnet localhost 80 GET /script.php HTTP/1.0 [2005-08-10 18:50:14] dennis at nocertainty dot com Yes, that works. But as soon as I use ob_gzhandler, instead of foo, nothing is displayed. I run PHP4 and PHP5 at the same time (port 80 is PHP4.3.4, port 83 is PHP5Dev). Could it be that the bug is caused by my PHP4 installation? [2005-08-10 18:39:16] [EMAIL PROTECTED] Still can't reproduce, even with FCGI. Does this work for you: ? [2005-08-10 18:19:53] dennis at nocertainty dot com It works with PHP CLI. SAPI: cgi-fcgi The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/34071 -- Edit this bug report at http://bugs.php.net/?id=34071&edit=1
#34071 [Fbk->Opn]: buffering is destroyed when using ob_gzhandler and ob_clean
ID: 34071 User updated by: dennis at nocertainty dot com Reported By: dennis at nocertainty dot com -Status: Feedback +Status: Open Bug Type: Output Control Operating System: Windows XP SP2 PHP Version: 5CVS-2005-08-10 (dev) New Comment: You're right, that works, and I get the correct result. Previous Comments: [2005-08-10 18:56:29] [EMAIL PROTECTED] Are you sure there is nothing shown in the "View Source" tab? I'm almost sure your browser just hides binary output from you. So try this: telnet localhost 80 GET /script.php HTTP/1.0 [2005-08-10 18:50:14] dennis at nocertainty dot com Yes, that works. But as soon as I use ob_gzhandler, instead of foo, nothing is displayed. I run PHP4 and PHP5 at the same time (port 80 is PHP4.3.4, port 83 is PHP5Dev). Could it be that the bug is caused by my PHP4 installation? [2005-08-10 18:39:16] [EMAIL PROTECTED] Still can't reproduce, even with FCGI. Does this work for you: ? [2005-08-10 18:19:53] dennis at nocertainty dot com It works with PHP CLI. SAPI: cgi-fcgi [2005-08-10 18:14:58] [EMAIL PROTECTED] Can't reproduce. Please try with PHP CLI and tell what SAPI you're using. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/34071 -- Edit this bug report at http://bugs.php.net/?id=34071&edit=1
#34071 [Opn->Fbk]: buffering is destroyed when using ob_gzhandler and ob_clean
ID: 34071
Updated by: [EMAIL PROTECTED]
Reported By: dennis at nocertainty dot com
-Status: Open
+Status: Feedback
Bug Type: Output Control
Operating System: Windows XP SP2
PHP Version: 5CVS-2005-08-10 (dev)
New Comment:
Are you sure there is nothing shown in the "View Source" tab?
I'm almost sure your browser just hides binary output from you. So try
this:
telnet localhost 80
GET /script.php HTTP/1.0
Previous Comments:
[2005-08-10 18:50:14] dennis at nocertainty dot com
Yes, that works. But as soon as I use ob_gzhandler, instead of foo,
nothing is displayed.
I run PHP4 and PHP5 at the same time (port 80 is PHP4.3.4, port 83 is
PHP5Dev). Could it be that the bug is caused by my PHP4 installation?
[2005-08-10 18:39:16] [EMAIL PROTECTED]
Still can't reproduce, even with FCGI.
Does this work for you:
?
[2005-08-10 18:19:53] dennis at nocertainty dot com
It works with PHP CLI.
SAPI: cgi-fcgi
[2005-08-10 18:14:58] [EMAIL PROTECTED]
Can't reproduce.
Please try with PHP CLI and tell what SAPI you're using.
[2005-08-10 18:08:20] dennis at nocertainty dot com
Description:
When using ob_start('ob_gzhandler') and ob_clean() the output buffer is
destroyed, and no ob_* function works anymore. It seems that PHP4 had
this problem as well (http://bugs.php.net/bug.php?id=29125)
Reproduce code:
---
Expected result:
"Should be shown" should've been printed, instead nothing is returned,
and nothing displays anymore.
--
Edit this bug report at http://bugs.php.net/?id=34071&edit=1
#34071 [Fbk->Opn]: buffering is destroyed when using ob_gzhandler and ob_clean
ID: 34071
User updated by: dennis at nocertainty dot com
Reported By: dennis at nocertainty dot com
-Status: Feedback
+Status: Open
Bug Type: Output Control
Operating System: Windows XP SP2
PHP Version: 5CVS-2005-08-10 (dev)
New Comment:
Yes, that works. But as soon as I use ob_gzhandler, instead of foo,
nothing is displayed.
I run PHP4 and PHP5 at the same time (port 80 is PHP4.3.4, port 83 is
PHP5Dev). Could it be that the bug is caused by my PHP4 installation?
Previous Comments:
[2005-08-10 18:39:16] [EMAIL PROTECTED]
Still can't reproduce, even with FCGI.
Does this work for you:
?
[2005-08-10 18:19:53] dennis at nocertainty dot com
It works with PHP CLI.
SAPI: cgi-fcgi
[2005-08-10 18:14:58] [EMAIL PROTECTED]
Can't reproduce.
Please try with PHP CLI and tell what SAPI you're using.
[2005-08-10 18:08:20] dennis at nocertainty dot com
Description:
When using ob_start('ob_gzhandler') and ob_clean() the output buffer is
destroyed, and no ob_* function works anymore. It seems that PHP4 had
this problem as well (http://bugs.php.net/bug.php?id=29125)
Reproduce code:
---
Expected result:
"Should be shown" should've been printed, instead nothing is returned,
and nothing displays anymore.
--
Edit this bug report at http://bugs.php.net/?id=34071&edit=1
#34072 [Opn->Asn]: MySQL module can't connect if port is not 3306
ID: 34072
Updated by: [EMAIL PROTECTED]
Reported By: pash_ka at fonbet dot info
-Status: Open
+Status: Assigned
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5.1.0b3
-Assigned To:
+Assigned To: wez
New Comment:
Wez, could you plz check it out?
Previous Comments:
[2005-08-10 18:44:18] [EMAIL PROTECTED]
I've just copied your DSN and it worked for me.
But IIRC it's possible that it automagically uses local socket on my
Linux, which is not available on Win32.
[2005-08-10 18:38:40] pash_ka at fonbet dot info
Well, I've just downloaded php5-win32-latest.zip - it's the same one
(Aug 9 2005 ) and tried with it. The bug is still there for me.
Do i need to use "mysql:host=localhost;port=6733;dbname=www" dsn or
there is another syntax to specify port?
[2005-08-10 18:22:42] [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
Can't reproduce.
[2005-08-10 18:16:05] pash_ka at fonbet dot info
And yes, I've tried with port 3306 - it works fine. And it also works
fine with my non-standart port using mysql_connect().
So it's definetly a bug or missing future in PDO.
[2005-08-10 18:11:30] pash_ka at fonbet dot info
Description:
I can't connect with my MySQL server running on localhost using
non-standart port.
I've tried dsn
mysql:host=localhost;port=6733;dbname=www
(resulted with "Can't connect to MySQL server on 'localhost' (10061)"
error)
mysql:host=localhost:6733;dbname=www
(resulted with "Unknown MySQL server host 'localhost:6733' (11001)"
error)
I've also tried to use
ini_set('mysql.default_port', 6733);
and set in php.ini
I've tried it with PHP 5.1 beta3 and with php_pdo_mysql.dll from
"php5-win32-latest.zip" (09.08.2005).
--
Edit this bug report at http://bugs.php.net/?id=34072&edit=1
#34072 [Opn]: MySQL module can't connect if port is not 3306
ID: 34072
Updated by: [EMAIL PROTECTED]
Reported By: pash_ka at fonbet dot info
Status: Open
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5.1.0b3
New Comment:
I've just copied your DSN and it worked for me.
But IIRC it's possible that it automagically uses local socket on my
Linux, which is not available on Win32.
Previous Comments:
[2005-08-10 18:38:40] pash_ka at fonbet dot info
Well, I've just downloaded php5-win32-latest.zip - it's the same one
(Aug 9 2005 ) and tried with it. The bug is still there for me.
Do i need to use "mysql:host=localhost;port=6733;dbname=www" dsn or
there is another syntax to specify port?
[2005-08-10 18:22:42] [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
Can't reproduce.
[2005-08-10 18:16:05] pash_ka at fonbet dot info
And yes, I've tried with port 3306 - it works fine. And it also works
fine with my non-standart port using mysql_connect().
So it's definetly a bug or missing future in PDO.
[2005-08-10 18:11:30] pash_ka at fonbet dot info
Description:
I can't connect with my MySQL server running on localhost using
non-standart port.
I've tried dsn
mysql:host=localhost;port=6733;dbname=www
(resulted with "Can't connect to MySQL server on 'localhost' (10061)"
error)
mysql:host=localhost:6733;dbname=www
(resulted with "Unknown MySQL server host 'localhost:6733' (11001)"
error)
I've also tried to use
ini_set('mysql.default_port', 6733);
and set in php.ini
I've tried it with PHP 5.1 beta3 and with php_pdo_mysql.dll from
"php5-win32-latest.zip" (09.08.2005).
--
Edit this bug report at http://bugs.php.net/?id=34072&edit=1
#34071 [Opn->Fbk]: buffering is destroyed when using ob_gzhandler and ob_clean
ID: 34071
Updated by: [EMAIL PROTECTED]
Reported By: dennis at nocertainty dot com
-Status: Open
+Status: Feedback
Bug Type: Output Control
Operating System: Windows XP SP2
PHP Version: 5CVS-2005-08-10 (dev)
New Comment:
Still can't reproduce, even with FCGI.
Does this work for you:
?
Previous Comments:
[2005-08-10 18:19:53] dennis at nocertainty dot com
It works with PHP CLI.
SAPI: cgi-fcgi
[2005-08-10 18:14:58] [EMAIL PROTECTED]
Can't reproduce.
Please try with PHP CLI and tell what SAPI you're using.
[2005-08-10 18:08:20] dennis at nocertainty dot com
Description:
When using ob_start('ob_gzhandler') and ob_clean() the output buffer is
destroyed, and no ob_* function works anymore. It seems that PHP4 had
this problem as well (http://bugs.php.net/bug.php?id=29125)
Reproduce code:
---
Expected result:
"Should be shown" should've been printed, instead nothing is returned,
and nothing displays anymore.
--
Edit this bug report at http://bugs.php.net/?id=34071&edit=1
#34072 [Fbk->Opn]: MySQL module can't connect if port is not 3306
ID: 34072
User updated by: pash_ka at fonbet dot info
Reported By: pash_ka at fonbet dot info
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5.1.0b3
New Comment:
Well, I've just downloaded php5-win32-latest.zip - it's the same one
(Aug 9 2005 ) and tried with it. The bug is still there for me.
Do i need to use "mysql:host=localhost;port=6733;dbname=www" dsn or
there is another syntax to specify port?
Previous Comments:
[2005-08-10 18:22:42] [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
Can't reproduce.
[2005-08-10 18:16:05] pash_ka at fonbet dot info
And yes, I've tried with port 3306 - it works fine. And it also works
fine with my non-standart port using mysql_connect().
So it's definetly a bug or missing future in PDO.
[2005-08-10 18:11:30] pash_ka at fonbet dot info
Description:
I can't connect with my MySQL server running on localhost using
non-standart port.
I've tried dsn
mysql:host=localhost;port=6733;dbname=www
(resulted with "Can't connect to MySQL server on 'localhost' (10061)"
error)
mysql:host=localhost:6733;dbname=www
(resulted with "Unknown MySQL server host 'localhost:6733' (11001)"
error)
I've also tried to use
ini_set('mysql.default_port', 6733);
and set in php.ini
I've tried it with PHP 5.1 beta3 and with php_pdo_mysql.dll from
"php5-win32-latest.zip" (09.08.2005).
--
Edit this bug report at http://bugs.php.net/?id=34072&edit=1
#34072 [Opn->Fbk]: MySQL module can't connect if port is not 3306
ID: 34072
Updated by: [EMAIL PROTECTED]
Reported By: pash_ka at fonbet dot info
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5.1.0b3
New Comment:
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
Can't reproduce.
Previous Comments:
[2005-08-10 18:16:05] pash_ka at fonbet dot info
And yes, I've tried with port 3306 - it works fine. And it also works
fine with my non-standart port using mysql_connect().
So it's definetly a bug or missing future in PDO.
[2005-08-10 18:11:30] pash_ka at fonbet dot info
Description:
I can't connect with my MySQL server running on localhost using
non-standart port.
I've tried dsn
mysql:host=localhost;port=6733;dbname=www
(resulted with "Can't connect to MySQL server on 'localhost' (10061)"
error)
mysql:host=localhost:6733;dbname=www
(resulted with "Unknown MySQL server host 'localhost:6733' (11001)"
error)
I've also tried to use
ini_set('mysql.default_port', 6733);
and set in php.ini
I've tried it with PHP 5.1 beta3 and with php_pdo_mysql.dll from
"php5-win32-latest.zip" (09.08.2005).
--
Edit this bug report at http://bugs.php.net/?id=34072&edit=1
#34071 [Fbk->Opn]: buffering is destroyed when using ob_gzhandler and ob_clean
ID: 34071
User updated by: dennis at nocertainty dot com
Reported By: dennis at nocertainty dot com
-Status: Feedback
+Status: Open
Bug Type: Output Control
Operating System: Windows XP SP2
PHP Version: 5CVS-2005-08-10 (dev)
New Comment:
It works with PHP CLI.
SAPI: cgi-fcgi
Previous Comments:
[2005-08-10 18:14:58] [EMAIL PROTECTED]
Can't reproduce.
Please try with PHP CLI and tell what SAPI you're using.
[2005-08-10 18:08:20] dennis at nocertainty dot com
Description:
When using ob_start('ob_gzhandler') and ob_clean() the output buffer is
destroyed, and no ob_* function works anymore. It seems that PHP4 had
this problem as well (http://bugs.php.net/bug.php?id=29125)
Reproduce code:
---
Expected result:
"Should be shown" should've been printed, instead nothing is returned,
and nothing displays anymore.
--
Edit this bug report at http://bugs.php.net/?id=34071&edit=1
#34072 [Opn]: MySQL module can't connect if port is not 3306
ID: 34072
User updated by: pash_ka at fonbet dot info
Reported By: pash_ka at fonbet dot info
Status: Open
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5.1.0b3
New Comment:
And yes, I've tried with port 3306 - it works fine. And it also works
fine with my non-standart port using mysql_connect().
So it's definetly a bug or missing future in PDO.
Previous Comments:
[2005-08-10 18:11:30] pash_ka at fonbet dot info
Description:
I can't connect with my MySQL server running on localhost using
non-standart port.
I've tried dsn
mysql:host=localhost;port=6733;dbname=www
(resulted with "Can't connect to MySQL server on 'localhost' (10061)"
error)
mysql:host=localhost:6733;dbname=www
(resulted with "Unknown MySQL server host 'localhost:6733' (11001)"
error)
I've also tried to use
ini_set('mysql.default_port', 6733);
and set in php.ini
I've tried it with PHP 5.1 beta3 and with php_pdo_mysql.dll from
"php5-win32-latest.zip" (09.08.2005).
--
Edit this bug report at http://bugs.php.net/?id=34072&edit=1
#34071 [Opn->Fbk]: buffering is destroyed when using ob_gzhandler and ob_clean
ID: 34071
Updated by: [EMAIL PROTECTED]
Reported By: dennis at nocertainty dot com
-Status: Open
+Status: Feedback
Bug Type: Output Control
Operating System: Windows XP SP2
PHP Version: 5CVS-2005-08-10 (dev)
New Comment:
Can't reproduce.
Please try with PHP CLI and tell what SAPI you're using.
Previous Comments:
[2005-08-10 18:08:20] dennis at nocertainty dot com
Description:
When using ob_start('ob_gzhandler') and ob_clean() the output buffer is
destroyed, and no ob_* function works anymore. It seems that PHP4 had
this problem as well (http://bugs.php.net/bug.php?id=29125)
Reproduce code:
---
Expected result:
"Should be shown" should've been printed, instead nothing is returned,
and nothing displays anymore.
--
Edit this bug report at http://bugs.php.net/?id=34071&edit=1
#34072 [NEW]: MySQL module can't connect if port is not 3306
From: pash_ka at fonbet dot info
Operating system: Windows XP
PHP version: 5.1.0b3
PHP Bug Type: PDO related
Bug description: MySQL module can't connect if port is not 3306
Description:
I can't connect with my MySQL server running on localhost using
non-standart port.
I've tried dsn
mysql:host=localhost;port=6733;dbname=www
(resulted with "Can't connect to MySQL server on 'localhost' (10061)"
error)
mysql:host=localhost:6733;dbname=www
(resulted with "Unknown MySQL server host 'localhost:6733' (11001)"
error)
I've also tried to use
ini_set('mysql.default_port', 6733);
and set in php.ini
I've tried it with PHP 5.1 beta3 and with php_pdo_mysql.dll from
"php5-win32-latest.zip" (09.08.2005).
--
Edit bug report at http://bugs.php.net/?id=34072&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34072&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34072&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34072&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34072&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34072&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34072&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34072&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34072&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34072&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34072&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34072&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34072&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34072&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34072&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34072&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34072&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34072&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34072&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34072&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34072&r=mysqlcfg
#34071 [NEW]: buffering is destroyed when using ob_gzhandler and ob_clean
From: dennis at nocertainty dot com
Operating system: Windows XP SP2
PHP version: 5CVS-2005-08-10 (dev)
PHP Bug Type: Output Control
Bug description: buffering is destroyed when using ob_gzhandler and ob_clean
Description:
When using ob_start('ob_gzhandler') and ob_clean() the output buffer is
destroyed, and no ob_* function works anymore. It seems that PHP4 had this
problem as well (http://bugs.php.net/bug.php?id=29125)
Reproduce code:
---
Expected result:
"Should be shown" should've been printed, instead nothing is returned, and
nothing displays anymore.
--
Edit bug report at http://bugs.php.net/?id=34071&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34071&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34071&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34071&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34071&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34071&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34071&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34071&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34071&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34071&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34071&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34071&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34071&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34071&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34071&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34071&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34071&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34071&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34071&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34071&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34071&r=mysqlcfg
#34069 [Fbk->Bgs]: Named variable array not correctly returned from within member function
ID: 34069
Updated by: [EMAIL PROTECTED]
Reported By: davydm at gmail dot com
-Status: Feedback
+Status: Bogus
Bug Type: Class/Object related
Operating System: Linux
PHP Version: 4.4.0
New Comment:
Doesn't matter, I got it.
Use $this->{$name}[$idx] syntax in this case, as the Engine can't guess
what are you referring to:
to $this->{$name[0]} or to $this->{$name}[0].
If you set error_reporting to E_ALL, you'll see appropriate notices.
Previous Comments:
[2005-08-10 16:46:16] [EMAIL PROTECTED]
And add please expected and actual results of this code.
[2005-08-10 16:36:04] davydm at gmail dot com
I'm afraid that the giant 25 lines below is the smallest I can get a
full example of what I'm talking about, since the problem is a little
complex.
// begin php code
class Foo {
function Foo() {
$this->arrFoo = array("one", "two", "three");
}
function getFoo($name, $idx) {
if (array_key_exists($idx, $this->$name)) {
return $this->$name[$idx];
} else {print("no $name here of that $idx");}
}
function getBar($name, $idx) {
if (array_key_exists($idx, $this->$name)) {
foreach ($this->$name as $fidx => $val) {
if ($fidx == $idx) return $val;
}
} else {print("no $name here of that $idx");}
}
}
$myfoo = new Foo();
$badret = $myfoo->getFoo("arrFoo", 0); // bad return example
$goodret = $myfoo->getBar("arrFoo", 0); // kludged good return
var_dump($ret);
print("");
var_dump($myfoo->arrFoo[0]); // direct access works ok
print("");
var_dump($goodret);
// end php code
[2005-08-10 16:13:03] [EMAIL PROTECTED]
>If I can supply more code, please let me know.
No, thanks.
Could you plz provide a short but complete script max 20 lines long
that can be copy/pasted to reproduce the problem?
Thanks.
[2005-08-10 16:07:08] davydm at gmail dot com
Description:
I have a class which maintains heirachical data, as would be (and,
indeed, is) represented with xml. The class basically provides a
programmable interface to an xml data transport, allowing for data to
be transported from php to a tcl middleware server to be parsed and
used. So far, so good.
The best way to explain is to demonstrate:
If I were to load an instance of the object with the following xml:
Foo
Bar
Childname
Childdescr>
I would get an object which has:
$obj->name == "Foo"
$obj->descr == "Bar"
$obj->child[0]->name == "Childname"
$obj->child[0]->descr == "Childdescr"
and so forth. The class allows for nodes with the same name, which are
then placed into an an array, hence the array notation on the child
node above.
The oddity I have hit upon seems to be a PHP bug, but I'm well open to
suggestions. In programming the class, I wanted a consistent interface
with the TCL class I have that handles the same functionality, so there
are times when I have replicated interface functions even when they are
not necessairly required (for the sake of completeness). One such
interface mirroring is the get_child function, which takes in the
following arguments:
$childname (string)
$idx (integer)
and returns a reference to the child named by the $childname and
pointed to by the $idx (if there is one).
The wierdness is that in the original implementation of get_child,
where I just checked that the child name was known and the key existed
in the array, I did:
return $this->$childname[$idx];
once I had verified with array_key_exists that the element actually
existed, I *always* got back null. If I referenced the child from
outside of the class (with $obj->childname[$idx]), the child object is
quite alright and there, and alive and all of that.
The wierdness steps up a notch when I change the internals of
get_child: instead of just returning the object with:
return $this->$childname[$idx];
I do:
foreach ($this->$childname as $cidx => $child) {
if ($cidx == $idx) {
return $child;
}
}
and VOILA!, I get back the child I was looking for. The code is less
efficient, of course, because I have to iterate over the child array.
But that's not the thing that really bothers me -- I'm more bothered as
to *why* this happens, and the only explanation I can see is something
lower-level and internal to PHP
Reproduce code:
---
Please have a look at http://dascafe.lesbean.net/hdobj.php.gz ,
starting at line 289, which is the function definition for get_child.
You can also see that I've used a foreach in the function toXML(),
instead of using the child
#34069 [Opn->Fbk]: Named variable array not correctly returned from within member function
ID: 34069
Updated by: [EMAIL PROTECTED]
Reported By: davydm at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Class/Object related
Operating System: Linux
PHP Version: 4.4.0
New Comment:
And add please expected and actual results of this code.
Previous Comments:
[2005-08-10 16:36:04] davydm at gmail dot com
I'm afraid that the giant 25 lines below is the smallest I can get a
full example of what I'm talking about, since the problem is a little
complex.
// begin php code
class Foo {
function Foo() {
$this->arrFoo = array("one", "two", "three");
}
function getFoo($name, $idx) {
if (array_key_exists($idx, $this->$name)) {
return $this->$name[$idx];
} else {print("no $name here of that $idx");}
}
function getBar($name, $idx) {
if (array_key_exists($idx, $this->$name)) {
foreach ($this->$name as $fidx => $val) {
if ($fidx == $idx) return $val;
}
} else {print("no $name here of that $idx");}
}
}
$myfoo = new Foo();
$badret = $myfoo->getFoo("arrFoo", 0); // bad return example
$goodret = $myfoo->getBar("arrFoo", 0); // kludged good return
var_dump($ret);
print("");
var_dump($myfoo->arrFoo[0]); // direct access works ok
print("");
var_dump($goodret);
// end php code
[2005-08-10 16:13:03] [EMAIL PROTECTED]
>If I can supply more code, please let me know.
No, thanks.
Could you plz provide a short but complete script max 20 lines long
that can be copy/pasted to reproduce the problem?
Thanks.
[2005-08-10 16:07:08] davydm at gmail dot com
Description:
I have a class which maintains heirachical data, as would be (and,
indeed, is) represented with xml. The class basically provides a
programmable interface to an xml data transport, allowing for data to
be transported from php to a tcl middleware server to be parsed and
used. So far, so good.
The best way to explain is to demonstrate:
If I were to load an instance of the object with the following xml:
Foo
Bar
Childname
Childdescr>
I would get an object which has:
$obj->name == "Foo"
$obj->descr == "Bar"
$obj->child[0]->name == "Childname"
$obj->child[0]->descr == "Childdescr"
and so forth. The class allows for nodes with the same name, which are
then placed into an an array, hence the array notation on the child
node above.
The oddity I have hit upon seems to be a PHP bug, but I'm well open to
suggestions. In programming the class, I wanted a consistent interface
with the TCL class I have that handles the same functionality, so there
are times when I have replicated interface functions even when they are
not necessairly required (for the sake of completeness). One such
interface mirroring is the get_child function, which takes in the
following arguments:
$childname (string)
$idx (integer)
and returns a reference to the child named by the $childname and
pointed to by the $idx (if there is one).
The wierdness is that in the original implementation of get_child,
where I just checked that the child name was known and the key existed
in the array, I did:
return $this->$childname[$idx];
once I had verified with array_key_exists that the element actually
existed, I *always* got back null. If I referenced the child from
outside of the class (with $obj->childname[$idx]), the child object is
quite alright and there, and alive and all of that.
The wierdness steps up a notch when I change the internals of
get_child: instead of just returning the object with:
return $this->$childname[$idx];
I do:
foreach ($this->$childname as $cidx => $child) {
if ($cidx == $idx) {
return $child;
}
}
and VOILA!, I get back the child I was looking for. The code is less
efficient, of course, because I have to iterate over the child array.
But that's not the thing that really bothers me -- I'm more bothered as
to *why* this happens, and the only explanation I can see is something
lower-level and internal to PHP
Reproduce code:
---
Please have a look at http://dascafe.lesbean.net/hdobj.php.gz ,
starting at line 289, which is the function definition for get_child.
You can also see that I've used a foreach in the function toXML(),
instead of using the child indeces and the child_count function, as I
originally intended. If I can supply more code, please let me know.
Expected result:
With the commented out code in place, I expect a reference to a member
variable of the class which is itself an object of the same class.
Actual result:
--
When I use the commented out code, I get a
#34069 [Fbk->Opn]: Named variable array not correctly returned from within member function
ID: 34069
User updated by: davydm at gmail dot com
Reported By: davydm at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Class/Object related
Operating System: Linux
PHP Version: 4.4.0
New Comment:
I'm afraid that the giant 25 lines below is the smallest I can get a
full example of what I'm talking about, since the problem is a little
complex.
// begin php code
class Foo {
function Foo() {
$this->arrFoo = array("one", "two", "three");
}
function getFoo($name, $idx) {
if (array_key_exists($idx, $this->$name)) {
return $this->$name[$idx];
} else {print("no $name here of that $idx");}
}
function getBar($name, $idx) {
if (array_key_exists($idx, $this->$name)) {
foreach ($this->$name as $fidx => $val) {
if ($fidx == $idx) return $val;
}
} else {print("no $name here of that $idx");}
}
}
$myfoo = new Foo();
$badret = $myfoo->getFoo("arrFoo", 0); // bad return example
$goodret = $myfoo->getBar("arrFoo", 0); // kludged good return
var_dump($ret);
print("");
var_dump($myfoo->arrFoo[0]); // direct access works ok
print("");
var_dump($goodret);
// end php code
Previous Comments:
[2005-08-10 16:13:03] [EMAIL PROTECTED]
>If I can supply more code, please let me know.
No, thanks.
Could you plz provide a short but complete script max 20 lines long
that can be copy/pasted to reproduce the problem?
Thanks.
[2005-08-10 16:07:08] davydm at gmail dot com
Description:
I have a class which maintains heirachical data, as would be (and,
indeed, is) represented with xml. The class basically provides a
programmable interface to an xml data transport, allowing for data to
be transported from php to a tcl middleware server to be parsed and
used. So far, so good.
The best way to explain is to demonstrate:
If I were to load an instance of the object with the following xml:
Foo
Bar
Childname
Childdescr>
I would get an object which has:
$obj->name == "Foo"
$obj->descr == "Bar"
$obj->child[0]->name == "Childname"
$obj->child[0]->descr == "Childdescr"
and so forth. The class allows for nodes with the same name, which are
then placed into an an array, hence the array notation on the child
node above.
The oddity I have hit upon seems to be a PHP bug, but I'm well open to
suggestions. In programming the class, I wanted a consistent interface
with the TCL class I have that handles the same functionality, so there
are times when I have replicated interface functions even when they are
not necessairly required (for the sake of completeness). One such
interface mirroring is the get_child function, which takes in the
following arguments:
$childname (string)
$idx (integer)
and returns a reference to the child named by the $childname and
pointed to by the $idx (if there is one).
The wierdness is that in the original implementation of get_child,
where I just checked that the child name was known and the key existed
in the array, I did:
return $this->$childname[$idx];
once I had verified with array_key_exists that the element actually
existed, I *always* got back null. If I referenced the child from
outside of the class (with $obj->childname[$idx]), the child object is
quite alright and there, and alive and all of that.
The wierdness steps up a notch when I change the internals of
get_child: instead of just returning the object with:
return $this->$childname[$idx];
I do:
foreach ($this->$childname as $cidx => $child) {
if ($cidx == $idx) {
return $child;
}
}
and VOILA!, I get back the child I was looking for. The code is less
efficient, of course, because I have to iterate over the child array.
But that's not the thing that really bothers me -- I'm more bothered as
to *why* this happens, and the only explanation I can see is something
lower-level and internal to PHP
Reproduce code:
---
Please have a look at http://dascafe.lesbean.net/hdobj.php.gz ,
starting at line 289, which is the function definition for get_child.
You can also see that I've used a foreach in the function toXML(),
instead of using the child indeces and the child_count function, as I
originally intended. If I can supply more code, please let me know.
Expected result:
With the commented out code in place, I expect a reference to a member
variable of the class which is itself an object of the same class.
Actual result:
--
When I use the commented out code, I get a NULL reference instead of
the object. Using the foreach to iterate over each element in the
$childname array, and returning the child with a matching index works
-- although
#34070 [Opn->Bgs]: PHP Startup: Unable to load dynamic library '/php_mysql.dll'
ID: 34070 Updated by: [EMAIL PROTECTED] Reported By: mikerob818 at cs dot com -Status: Open +Status: Bogus Bug Type: PWS related Operating System: Windows 98 PHP Version: 5.0.4 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. . Previous Comments: [2005-08-10 16:27:15] mikerob818 at cs dot com Description: Error message when try to run hello.php under PWS: PHP Startup: Unable to load dynamic library '/php_mysql.dll'- One of the library files needed to run this application can not be found. The checklist below is based on PHP Manual. If the manual is missing instructions, please provide. Thanks, Robin *** Description Manual Installation: Download zip binary distribution from downloads page Website: http://www.php.net/downloads.php Description Microsoft 98/NT : Download latest version of Microsoft Data Access Components (MDAC) for your platform Website: http://msdn.microsoft.com/data/ Description Extract distribution file into c:\php Description Add c:\php to PATH by editing autoexec.bat file path C:\WINDOWS;C:\WINDOWS\COMMAND;C:\php Description Download PHP extensions into c:\php5 Website: http://www.php.net/downloads.php Description Place php5activescript.dll in c:\php Register dll with DOS command: cd c:\php regsvr32 php5activescript.dll (regsvr32.exe was copied from c:\Windows\System\inetsrv) Message: DllRegisterServer in php5activescript.dll succeeded Description To test if ActiveScript working: create test.wsf in c:\php Double click file If receive little window with "Hello World!", you're done Description Set up valid configuration file for php: php.ini-recommended saved as php.ini Description ActiveScript doesn't use php.ini file Create php-activescript.ini and place it in c:\php Description CGI users must set the cgi.force_redirect PHP directive to 0 in php.ini in php-activescript.ini Description In php.ini php-activescript.ini check these values: doc_root = c:\inetput\wwwroot extension_dir = "./" Description PWS 4 does not support ISAPI, only PHP CGI should be used Edit the pws-php5cgi.reg file in c:\php ".php"="c:\\php\\php-cgi.exe" double click to merge registry file into system In Personal Web Manager:* View > Advanced > Edit Properties Check box Execute *Note: It appears that the PHP manual is incorrect. This manual states the following: In the PWS Manager, right click on a given directory you want to add PHP support to, and select Properties. Check the 'Execute' checkbox, and confirm. Description The default location PHP searches for extensions is c:\php5 In php.ini php-activescript.ini kept default setting for extension_dir Description Enable the extensions In php.ini php-activescript.ini Done by deleting leading ; from extension you want to load Removed ; from beginning of: extension=php_mysql.dll Description Create hello.php and put in web server's root directory (document_root). Use browser to access locally with: http://localhost/hello.php Code: PHP Test Hello World'; ?> Got error message: PHP Startup: Unable to load dynamic library '/php_mysql.dll' One of the library files needed to run this application can not be found Files under c:\php fdftk.dll, fribidi.dll, gds32.dll, go-pear.bat, install.txt, libeay32.dll, libmhash.dll, libmysql.dll, license.txt, msql.dll, news.txt, ntwdblib.dll, php.exe, php.gif, php.ini, php.ini-dis, php.ini-recommended, php_mysql.dll, php5activescript.dll, php5apache.dll, php5apache_hooks.dll, php5apache2.dll, php5embed.lib, php5isapi.dll, php5nsapi.dll, php5ts.dll, php-activescript..ini, php-cgi.exe, php-win.exe, pws-php5cgi.reg, pws-php5isapi.reg, regsvr32.exe, snapshot.txt, ssleay32.dll, test.wsf, yaz.dll Files under c:\php\ext php_bz2.dll, php_cpdf.dll, php_curl.dll, php_dba.dll, php_dbase.dll, php_dbx.dll, php_dio.dll, php_exif.dll, php_fdf.dll, php_filepro.dll, php_gd2.dll, php_gettext.dll, php_ifx.dll, php_imap.dll, php_interbase.dll, php_ldap.dll, php_mbstring.dll, php_mcrypt.dll, php_mhash.dll, php_mime_magic.dll, php_ming.dll, php_msql.dll, php_mysql.dll, php_mysqli.dll, php_oci8.dll, php_openssl.dll, php_oracle.dll, php_pgsql.dll, php_pspell.dll, php_shmop.dll, php_snmp.dll, php_soap.dll, php_sockets.dll, php_sybase_ct.dll, php_tidy.dll, php_xmlrpc.dll, php_xsl.dll -- Edit this bug report at http://bugs.php.net/?id=34070&edit=1
#34070 [NEW]: PHP Startup: Unable to load dynamic library '/php_mysql.dll'
From: mikerob818 at cs dot com Operating system: Windows 98 PHP version: 5.0.4 PHP Bug Type: PWS related Bug description: PHP Startup: Unable to load dynamic library '/php_mysql.dll' Description: Error message when try to run hello.php under PWS: PHP Startup: Unable to load dynamic library '/php_mysql.dll'- One of the library files needed to run this application can not be found. The checklist below is based on PHP Manual. If the manual is missing instructions, please provide. Thanks, Robin *** Description Manual Installation: Download zip binary distribution from downloads page Website: http://www.php.net/downloads.php Description Microsoft 98/NT : Download latest version of Microsoft Data Access Components (MDAC) for your platform Website: http://msdn.microsoft.com/data/ Description Extract distribution file into c:\php Description Add c:\php to PATH by editing autoexec.bat file path C:\WINDOWS;C:\WINDOWS\COMMAND;C:\php Description Download PHP extensions into c:\php5 Website: http://www.php.net/downloads.php Description Place php5activescript.dll in c:\php Register dll with DOS command: cd c:\php regsvr32 php5activescript.dll (regsvr32.exe was copied from c:\Windows\System\inetsrv) Message: DllRegisterServer in php5activescript.dll succeeded Description To test if ActiveScript working: create test.wsf in c:\php Double click file If receive little window with "Hello World!", you're done Description Set up valid configuration file for php: php.ini-recommended saved as php.ini Description ActiveScript doesn't use php.ini file Create php-activescript.ini and place it in c:\php Description CGI users must set the cgi.force_redirect PHP directive to 0 in php.ini in php-activescript.ini Description In php.ini php-activescript.ini check these values: doc_root = c:\inetput\wwwroot extension_dir = "./" Description PWS 4 does not support ISAPI, only PHP CGI should be used Edit the pws-php5cgi.reg file in c:\php ".php"="c:\\php\\php-cgi.exe" double click to merge registry file into system In Personal Web Manager:* View > Advanced > Edit Properties Check box Execute *Note: It appears that the PHP manual is incorrect. This manual states the following: In the PWS Manager, right click on a given directory you want to add PHP support to, and select Properties. Check the 'Execute' checkbox, and confirm. Description The default location PHP searches for extensions is c:\php5 In php.ini php-activescript.ini kept default setting for extension_dir Description Enable the extensions In php.ini php-activescript.ini Done by deleting leading ; from extension you want to load Removed ; from beginning of: extension=php_mysql.dll Description Create hello.php and put in web server's root directory (document_root). Use browser to access locally with: http://localhost/hello.php Code: PHP Test Hello World'; ?> Got error message: PHP Startup: Unable to load dynamic library '/php_mysql.dll' One of the library files needed to run this application can not be found Files under c:\php fdftk.dll, fribidi.dll, gds32.dll, go-pear.bat, install.txt, libeay32.dll, libmhash.dll, libmysql.dll, license.txt, msql.dll, news.txt, ntwdblib.dll, php.exe, php.gif, php.ini, php.ini-dis, php.ini-recommended, php_mysql.dll, php5activescript.dll, php5apache.dll, php5apache_hooks.dll, php5apache2.dll, php5embed.lib, php5isapi.dll, php5nsapi.dll, php5ts.dll, php-activescript..ini, php-cgi.exe, php-win.exe, pws-php5cgi.reg, pws-php5isapi.reg, regsvr32.exe, snapshot.txt, ssleay32.dll, test.wsf, yaz.dll Files under c:\php\ext php_bz2.dll, php_cpdf.dll, php_curl.dll, php_dba.dll, php_dbase.dll, php_dbx.dll, php_dio.dll, php_exif.dll, php_fdf.dll, php_filepro.dll, php_gd2.dll, php_gettext.dll, php_ifx.dll, php_imap.dll, php_interbase.dll, php_ldap.dll, php_mbstring.dll, php_mcrypt.dll, php_mhash.dll, php_mime_magic.dll, php_ming.dll, php_msql.dll, php_mysql.dll, php_mysqli.dll, php_oci8.dll, php_openssl.dll, php_oracle.dll, php_pgsql.dll, php_pspell.dll, php_shmop.dll, php_snmp.dll, php_soap.dll, php_sockets.dll, php_sybase_ct.dll, php_tidy.dll, php_xmlrpc.dll, php_xsl.dll -- Edit bug report at http://bugs.php.net/?id=34070&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34070&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34070&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34070&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34070&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34070&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34070&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34070&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34070&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34070&r=support Expected behavior: h
#34062 [Csd]: Crash in catch block when many arguments are used
ID: 34062 User updated by: feldgendler at mail dot ru Reported By: feldgendler at mail dot ru Status: Closed Bug Type: Reproducible crash Operating System: Debian GNU/Linux PHP Version: 6.0.0-dev Assigned To: dmitry New Comment: Can I have the patch? Previous Comments: [2005-08-10 15:12:26] [EMAIL PROTECTED] Fixed in CVS HEAD (6,0), PHP_5_1 and PHP_5_0. [2005-08-10 10:45:15] [EMAIL PROTECTED] No. And today is not 1st of April too. See http://news.php.net/php.internals/17668 [2005-08-10 10:37:52] [EMAIL PROTECTED] No, 6.0.0-dev is correct. I still have to change the snapshot's builder though. [2005-08-10 10:35:54] feldgendler at mail dot ru "Version: 6.0.0-dev" Is this a misprint? [2005-08-10 10:19:22] [EMAIL PROTECTED] Dmitry, take a look at it plz, I can reproduce it with the latest CVS. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/34062 -- Edit this bug report at http://bugs.php.net/?id=34062&edit=1
#34069 [Opn->Fbk]: Named variable array not correctly returned from within member function
ID: 34069
Updated by: [EMAIL PROTECTED]
Reported By: davydm at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Class/Object related
Operating System: Linux
PHP Version: 4.4.0
New Comment:
>If I can supply more code, please let me know.
No, thanks.
Could you plz provide a short but complete script max 20 lines long
that can be copy/pasted to reproduce the problem?
Thanks.
Previous Comments:
[2005-08-10 16:07:08] davydm at gmail dot com
Description:
I have a class which maintains heirachical data, as would be (and,
indeed, is) represented with xml. The class basically provides a
programmable interface to an xml data transport, allowing for data to
be transported from php to a tcl middleware server to be parsed and
used. So far, so good.
The best way to explain is to demonstrate:
If I were to load an instance of the object with the following xml:
Foo
Bar
Childname
Childdescr>
I would get an object which has:
$obj->name == "Foo"
$obj->descr == "Bar"
$obj->child[0]->name == "Childname"
$obj->child[0]->descr == "Childdescr"
and so forth. The class allows for nodes with the same name, which are
then placed into an an array, hence the array notation on the child
node above.
The oddity I have hit upon seems to be a PHP bug, but I'm well open to
suggestions. In programming the class, I wanted a consistent interface
with the TCL class I have that handles the same functionality, so there
are times when I have replicated interface functions even when they are
not necessairly required (for the sake of completeness). One such
interface mirroring is the get_child function, which takes in the
following arguments:
$childname (string)
$idx (integer)
and returns a reference to the child named by the $childname and
pointed to by the $idx (if there is one).
The wierdness is that in the original implementation of get_child,
where I just checked that the child name was known and the key existed
in the array, I did:
return $this->$childname[$idx];
once I had verified with array_key_exists that the element actually
existed, I *always* got back null. If I referenced the child from
outside of the class (with $obj->childname[$idx]), the child object is
quite alright and there, and alive and all of that.
The wierdness steps up a notch when I change the internals of
get_child: instead of just returning the object with:
return $this->$childname[$idx];
I do:
foreach ($this->$childname as $cidx => $child) {
if ($cidx == $idx) {
return $child;
}
}
and VOILA!, I get back the child I was looking for. The code is less
efficient, of course, because I have to iterate over the child array.
But that's not the thing that really bothers me -- I'm more bothered as
to *why* this happens, and the only explanation I can see is something
lower-level and internal to PHP
Reproduce code:
---
Please have a look at http://dascafe.lesbean.net/hdobj.php.gz ,
starting at line 289, which is the function definition for get_child.
You can also see that I've used a foreach in the function toXML(),
instead of using the child indeces and the child_count function, as I
originally intended. If I can supply more code, please let me know.
Expected result:
With the commented out code in place, I expect a reference to a member
variable of the class which is itself an object of the same class.
Actual result:
--
When I use the commented out code, I get a NULL reference instead of
the object. Using the foreach to iterate over each element in the
$childname array, and returning the child with a matching index works
-- although they should have exactly the same result.
--
Edit this bug report at http://bugs.php.net/?id=34069&edit=1
#34069 [NEW]: Named variable array not correctly returned from within member function
From: davydm at gmail dot com
Operating system: Linux
PHP version: 4.4.0
PHP Bug Type: Class/Object related
Bug description: Named variable array not correctly returned from within
member function
Description:
I have a class which maintains heirachical data, as would be (and, indeed,
is) represented with xml. The class basically provides a programmable
interface to an xml data transport, allowing for data to be transported
from php to a tcl middleware server to be parsed and used. So far, so
good.
The best way to explain is to demonstrate:
If I were to load an instance of the object with the following xml:
Foo
Bar
Childname
Childdescr>
I would get an object which has:
$obj->name == "Foo"
$obj->descr == "Bar"
$obj->child[0]->name == "Childname"
$obj->child[0]->descr == "Childdescr"
and so forth. The class allows for nodes with the same name, which are
then placed into an an array, hence the array notation on the child node
above.
The oddity I have hit upon seems to be a PHP bug, but I'm well open to
suggestions. In programming the class, I wanted a consistent interface
with the TCL class I have that handles the same functionality, so there
are times when I have replicated interface functions even when they are
not necessairly required (for the sake of completeness). One such
interface mirroring is the get_child function, which takes in the
following arguments:
$childname (string)
$idx (integer)
and returns a reference to the child named by the $childname and pointed
to by the $idx (if there is one).
The wierdness is that in the original implementation of get_child, where I
just checked that the child name was known and the key existed in the
array, I did:
return $this->$childname[$idx];
once I had verified with array_key_exists that the element actually
existed, I *always* got back null. If I referenced the child from outside
of the class (with $obj->childname[$idx]), the child object is quite
alright and there, and alive and all of that.
The wierdness steps up a notch when I change the internals of get_child:
instead of just returning the object with:
return $this->$childname[$idx];
I do:
foreach ($this->$childname as $cidx => $child) {
if ($cidx == $idx) {
return $child;
}
}
and VOILA!, I get back the child I was looking for. The code is less
efficient, of course, because I have to iterate over the child array. But
that's not the thing that really bothers me -- I'm more bothered as to
*why* this happens, and the only explanation I can see is something
lower-level and internal to PHP
Reproduce code:
---
Please have a look at http://dascafe.lesbean.net/hdobj.php.gz , starting
at line 289, which is the function definition for get_child. You can also
see that I've used a foreach in the function toXML(), instead of using the
child indeces and the child_count function, as I originally intended. If I
can supply more code, please let me know.
Expected result:
With the commented out code in place, I expect a reference to a member
variable of the class which is itself an object of the same class.
Actual result:
--
When I use the commented out code, I get a NULL reference instead of the
object. Using the foreach to iterate over each element in the $childname
array, and returning the child with a matching index works -- although
they should have exactly the same result.
--
Edit bug report at http://bugs.php.net/?id=34069&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34069&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34069&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34069&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34069&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34069&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34069&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34069&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34069&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34069&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34069&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34069&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34069&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34069&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34069&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34069&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34069&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34069&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34069&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34069&r=nozend
MyS
#34068 [Asn->Opn]: Numeric string as array key cast to integer
ID: 34068
Updated by: [EMAIL PROTECTED]
Reported By: clemens at gutweiler dot net
-Status: Assigned
+Status: Open
-Bug Type: Scripting Engine problem
+Bug Type: WDDX related
Operating System: *
PHP Version: 5CVS-2005-08-10
Assigned To: dmitry
New Comment:
Nevermind that, we have it documented as expected behaviour.
WDDX should really be consistent with how PHP handles this..
Previous Comments:
[2005-08-10 15:39:29] [EMAIL PROTECTED]
Actually it's not WDDX issue, but general issue with numeric array
index not staying as string but getting silently changed to integer:
'abc', 'abc' => '123');
var_dump($a);
?>
Outputs:
array(2) {
[123]=>
string(3) "abc"
["abc"]=>
string(3) "123"
}
Although this is pretty old issue, Dmitry, can you check?
[2005-08-10 13:58:47] clemens at gutweiler dot net
Description:
The vartype of the 123 key changed after serialization, it should be
consistent.
Reproduce code:
---
'zahl',
'Foo' => 'bar',
);
var_dump( $data );
var_dump( wddx_deserialize( wddx_serialize_value( $data ) ) );
highlight_file( __FILE__ );
?>
Expected result:
array(2) {
["123"]=>
string(4) "zahl"
["Foo"]=>
string(3) "bar"
}
array(2) {
["123"]=>
string(4) "zahl"
["Foo"]=>
string(3) "bar"
}
Actual result:
--
array(2) {
[123]=>
string(4) "zahl"
["Foo"]=>
string(3) "bar"
}
array(2) {
["123"]=>
string(4) "zahl"
["Foo"]=>
string(3) "bar"
}
--
Edit this bug report at http://bugs.php.net/?id=34068&edit=1
#27089 [Opn->Fbk]: Can't even configurate PHP with OpenSSL support
ID: 27089
Updated by: [EMAIL PROTECTED]
Reported By: apalma at custodium dot com
-Status: Open
+Status: Feedback
Bug Type: Compile Failure
Operating System: RedHat Linux 7.2
PHP Version: php4-STABLE-200402011830
New Comment:
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
Previous Comments:
[2004-02-01 15:40:04] apalma at custodium dot com
The log says:
configure:16122: checking for OpenSSL version
configure:16262: checking for CRYPTO_free in -lcrypto
configure:16281: gcc -o conftest -g -O2 conftest.c -lcrypto -lresolv
-lm -ldl -lnsl -lpthread 1>&5
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libcrypto.so:
undefined reference to [EMAIL PROTECTED]'
collect2: ld returned 1 exit status
configure: failed program was:
#line 16270 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char CRYPTO_free();
int main() {
CRYPTO_free()
; return 0; }
I only keep openssl and openssl-devel packages in this machine, and
removed openssl095a and openssl096
[2004-01-31 23:46:31] [EMAIL PROTECTED]
Check config.log for the exact reason why the test fails.
[2004-01-30 19:50:56] apalma at custodium dot com
I tried the previous suggestion, download the latest stable snapshot at
Jan 30, but the error still persists.
[2004-01-29 16:49:15] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
You really should have searched the bug database first. :)
[2004-01-29 13:59:48] apalma at custodium dot com
Description:
I'm trying to install PHP 4.3.4 in a RedHat Linux 7.2 box, adding
support for Oracle8i (that's the reason why I don't use the rpm PHP
distribuited by RedHat). But every time I run the configure with
support for openssl (--with-openssl), I get an error:
checking for CRYPTO_free in -lcrypto... no
configure: error: libcrypto not found!
I got all the dependences installed in the machine (openssl,
openssl095a, openssl096 and openssl-devel are installed), with the
following shared object created in the system:
libcrypto.a
libcrypto.so -> ../../lib/libcrypto.so.0.9.6b
libcrypto.so.0 -> libcrypto.so.0.9.5a
libcrypto.so.0.9.5a
libcrypto.so.0.9.6
libcrypto.so.1 -> libcrypto.so.0.9.6
libssl.a
libssl.so -> ../../lib/libssl.so.0.9.6b
libssl.so.0 -> libssl.so.0.9.5a
libssl.so.0.9.5a
libssl.so.0.9.6
libssl.so.1 -> libssl.so.0.9.6
In fact, if I compile the source rpm provided by RedHat, I get the same
error:
rpmbuild --rebuild --target=i386 php-4.1.2-7.2.6.src.rpm
checking for CRYPTO_free in -lcrypto... no
configure: error: libcrypto not found!
but I guess this is not your business :-D
Reproduce code:
---
./configure --with-openssl
Expected result:
I'd like to see a successful Makefile created after the configure
script is run.
--
Edit this bug report at http://bugs.php.net/?id=27089&edit=1
#34068 [Opn->Asn]: Numeric string as array key cast to integer
ID: 34068
Updated by: [EMAIL PROTECTED]
-Summary: Different Variable-Type after serialization
Reported By: clemens at gutweiler dot net
-Status: Open
+Status: Assigned
-Bug Type: WDDX related
+Bug Type: Scripting Engine problem
-Operating System: Win
+Operating System: *
-PHP Version: 5.1.0b3
+PHP Version: 5CVS-2005-08-10
-Assigned To:
+Assigned To: dmitry
New Comment:
Actually it's not WDDX issue, but general issue with numeric array
index not staying as string but getting silently changed to integer:
'abc', 'abc' => '123');
var_dump($a);
?>
Outputs:
array(2) {
[123]=>
string(3) "abc"
["abc"]=>
string(3) "123"
}
Although this is pretty old issue, Dmitry, can you check?
Previous Comments:
[2005-08-10 13:58:47] clemens at gutweiler dot net
Description:
The vartype of the 123 key changed after serialization, it should be
consistent.
Reproduce code:
---
'zahl',
'Foo' => 'bar',
);
var_dump( $data );
var_dump( wddx_deserialize( wddx_serialize_value( $data ) ) );
highlight_file( __FILE__ );
?>
Expected result:
array(2) {
["123"]=>
string(4) "zahl"
["Foo"]=>
string(3) "bar"
}
array(2) {
["123"]=>
string(4) "zahl"
["Foo"]=>
string(3) "bar"
}
Actual result:
--
array(2) {
[123]=>
string(4) "zahl"
["Foo"]=>
string(3) "bar"
}
array(2) {
["123"]=>
string(4) "zahl"
["Foo"]=>
string(3) "bar"
}
--
Edit this bug report at http://bugs.php.net/?id=34068&edit=1
#34062 [Asn->Csd]: Crash in catch block when many arguments are used
ID: 34062
Updated by: [EMAIL PROTECTED]
Reported By: feldgendler at mail dot ru
-Status: Assigned
+Status: Closed
Bug Type: Reproducible crash
Operating System: Debian GNU/Linux
PHP Version: 6.0.0-dev
Assigned To: dmitry
New Comment:
Fixed in CVS HEAD (6,0), PHP_5_1 and PHP_5_0.
Previous Comments:
[2005-08-10 10:45:15] [EMAIL PROTECTED]
No. And today is not 1st of April too.
See http://news.php.net/php.internals/17668
[2005-08-10 10:37:52] [EMAIL PROTECTED]
No, 6.0.0-dev is correct. I still have to change the snapshot's builder
though.
[2005-08-10 10:35:54] feldgendler at mail dot ru
"Version: 6.0.0-dev"
Is this a misprint?
[2005-08-10 10:19:22] [EMAIL PROTECTED]
Dmitry, take a look at it plz, I can reproduce it with the latest CVS.
[2005-08-10 08:52:45] feldgendler at mail dot ru
Description:
PHP crashes in a catch block. It happened in a real program, and I've
gradually reduced its complexity until I came to the simple testcase
I'm posting below. Both mod_php5 for Apache 2 and php5-cli crash on
this testcase.
Here is what I found during research:
In the beginning, I had multiple functions calling each other, like
this:
catch (Exception $e) {
function f2() { f3(0, 0); }
}
function f3() { f4(0, 0, 0); }
function f4() { f5(0, 0); }
...up to a quite deep nesting. I found that I can keep PHP crashing if
I carry the zeros from one function call to another, as long as their
total number does not decrese. I could even carry the zeros between the
catch block and the try block. Also I could exchange one level of
nesting for two additional zeros. So I collapsed them all in the
argument list of max(). The max() function was chosen arbitararily, any
function that takes unlimited number of arguments will do. The zeros can
also be replaced with values of any type. The crash can also be
reproduced using set_exception_handler() instead of a catch block.
Reproduce code:
---
Expected result:
(((
here
)))
Actual result:
--
(((
here
Segmentation fault
Here is the stack dump (obtained from php-cli):
#0 0x081fb0b6 in _zval_ptr_dtor ()
#1 0x0822b47c in zend_do_fcall_common_helper ()
#2 0x0823bb73 in zend_do_fcall_handler ()
#3 0x08228c39 in execute ()
#4 0x08208414 in zend_execute_scripts ()
#5 0x081ce03d in php_execute_script ()
#6 0x0824c284 in main ()
--
Edit this bug report at http://bugs.php.net/?id=34062&edit=1
#26771 [Com]: register_tick_funtions crashes apache2 child process
ID: 26771 Comment by: fredrik at demomusic dot nu Reported By: info at tphnet dot com Status: Verified Bug Type: Apache2 related Operating System: * (ZTS only!) PHP Version: 5CVS, 4CVS (2005-06-17) New Comment: It is no longer an Apache-bug: Comment From jorton at redhat dot com 2005-08-10 14:19 It's a PHP thread-safety issue, it's not Windows-specific, it breaks on Unixes with threaded MPMs too. Previous Comments: [2005-08-10 14:10:20] fredrik at demomusic dot nu I also reported this to Apache (as it most likely is a bug in the phpXapacheX.dll binaries that are bundled with Apache): http://issues.apache.org/bugzilla/show_bug.cgi?id=36118. This can also be voted upon: http://issues.apache.org/bugzilla/votes.cgi?action=show_user&bug_id=36118, in order to get the Apache-delevopers attention. [2005-08-10 13:24:23] fredrik at demomusic dot nu Some last information: solace at ezmail dot ru (http://bugs.php.net/bug.php?id=28567) has made an excellent php-profiler class, available on www.phpclasses.org. I have rewritten that profiler to side-kick as a debug-logger, an invaluable tool that I use a lot in my dev work. As soon as I am finished, it will be available for everyone, as solace's stuff is GPL. Both uses ticks. My point here is that the use of ticks on Windows is of great value, and therefore this matter should not preferably only lead to a change in the documentation (as some have suggested), but to the state where ticks work when running php as a module under apache! solace's makes an important comment in his own bugreport on this matter (marked as bogus for some reason): ""How to generate a backtrace" page is for *nix platforms, but this bug appears ONLY on Windows. All I have is event in system log "Application error Apache.exe at address x". Even Apache doesn't report it in error.log or access.log, like bug script wasn't accessed at all (Apache 1.3.27). But Windows wants to send report to Microsoft twice. And I'm not alone with this bug..." Also, this bug-report's name should preferable be "Ticks crashed Apache when running php as a module". More accurate, I believe. That's all for now... [2005-08-10 13:03:38] fredrik at demomusic dot nu Unless Zend is automatically disabled when running as cgi? I couldn't find any Zend-configurations in httpd.conf, and so I presumed that this was not the case. If I am mistaken, and this is solely a Zend-problem, please inform me and I will be posting a bug report to the Zend-team. Thank you! [2005-08-10 13:01:39] fredrik at demomusic dot nu What is with the "* (ZTS only!)"? Does it stand for Zend Thread Safety?? I am not familiar with ZTS, but shouldn't this be marked as an Windows-issue? It certainly should, is my opinion. As it works nicely when running PHP as CGI, same compile-options, same php.ini, I don't see how this could be a Zend Engine-problem... It is clearly a Windows Apache+PHP as module combination problem. Please update this report. [2005-08-10 12:54:14] fredrik at demomusic dot nu Previous bug-reports that address the exact same issue are as follows: 29 May 2004 - #28567 (Status: Bogus) Ticks crash Apache SAPI (http://bugs.php.net/bug.php?id=28567) [solace at ezmail dot ru] 28 Jan 2002 - #15267 (Status: Closed) "declare" makes apacke crashes under Windows (http://bugs.php.net/bug.php?id=) [ferguson at becon dot org] 16 May 2002 - #17283 (Status:No Feedback) register_tick_function(); [sendidmax at yahoo dot com dot cn] 18 Nov 2002 - #20486 (Status: No Feedback) register_tick_function crashes apache [junkie at overdoos dot org] 4 Aug 2004 - #29519 (Status: No Feedback) PHP5.0.0 call to declare(ticks=1) crashes apache 1.3.31 [peter dot belt at gmail dot com] Here is a short summary of those reports as well as extra info (my own). The above mentioned should be marked as Duplicates or such, and this report (#26771) should be the official bug-report of this particular problem. Please prioritize this problem, PHP-developers, as it has existed in release after release, year after year, regardless of Apache-version! Systems reported having this problem: Windows Unspec. - PHP 4.3.6 - Apache Unspec. Windows 2000- PHP 4.0.6 - Apache 1.3.20 Windows 2000- PHP 4.1.1 - Apache 1.3.22 Windows 2000- PHP 4.2.3 - Apache 1.3.22 Windows XP Pro - PHP 4.2.2 - Apache Unspec. Windows Unspec. - PHP 4.2.4-dev - Apache Unspec. Windows 2000- PHP 4.2.1 - Apache 1.3.24 Windows Unspec. - PHP 4.3.4 - Apache 2.0.48 Windows 2000- PHP 4.2.2 - Apache 1.3.22 Windows 2000- PHP 4.2.3 - Apache 1.3.22 Windows
#34040 [Csd->Bgs]: using 08 and 09 as integer
ID: 34040
Updated by: [EMAIL PROTECTED]
Reported By: csmar51 at free dot fr
-Status: Closed
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Linux Fedora Core 3 & Windows XP
PHP Version: 5CVS-2005-08-08 (dev)
Previous Comments:
[2005-08-10 14:36:44] csmar51 at free dot fr
Ok, thaks for your answer.
I never heard of octal numbers before, that's now done.
[2005-08-08 19:56:46] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Never heard of octal numbers, have you?
[2005-08-08 19:55:26] csmar51 at free dot fr
Description:
When we assign 08 or 09 has a variable (or in an array), this one
registers only 0. While with 01, 02, etc, this problem does not appear.
This is also reproducible everytime you use 08 or 09 as integer.
This arises with different versions of php: 4CVS-2005-08-08, 5.0.4,
5CVS-2005-08-08, 5.1.0b3. Either with a modified or default
configuration.
PHP configure line: ./configure --prefix=/www/php
./configure --prefix=/www/php
--with-apxs=/www/apache/bin/apxs
--with-config-file-path=/www/apache/conf/ --enable-versioning
--with-mm=/usr --with-libxml-dir=/usr --enable-ftp --with-gd=/usr
--with-jpeg-dir=/usr --with-png-dir=/usr --with-zlib-dir=/usr
--with-freetype-dir=/usr --enable-gd-native-ttf --with-mysql=/www/mysql
--with-mysql-sock --enable-sockets --enable-shared --enable-static
Reproduce code:
---
01, 'Feb'=>02, 'Mar'=>03, 'Apr'=>04,
'May'=>05, 'Jun'=>06,
'Jul'=>07, 'Aug'=>08, 'Sep'=>09, 'Oct'=>10,
'Nov'=>11, 'Dec'=>12);
var_dump($mon_array);
?>
Expected result:
array(12) {
["Jan"]=> int(1)
["Feb"]=> int(2)
["Mar"]=> int(3)
["Apr"]=> int(4)
["May"]=> int(5)
["Jun"]=> int(6)
["Jul"]=> int(7)
["Aug"]=> int(8)
["Sep"]=> int(9)
["Oct"]=> int(10)
["Nov"]=> int(11)
["Dec"]=> int(12)
}
Actual result:
--
array(12) {
["Jan"]=> int(1)
["Feb"]=> int(2)
["Mar"]=> int(3)
["Apr"]=> int(4)
["May"]=> int(5)
["Jun"]=> int(6)
["Jul"]=> int(7)
["Aug"]=> int(0)
["Sep"]=> int(0)
["Oct"]=> int(10)
["Nov"]=> int(11)
["Dec"]=> int(12)
}
--
Edit this bug report at http://bugs.php.net/?id=34040&edit=1
#34040 [Bgs->Csd]: using 08 and 09 as integer
ID: 34040
User updated by: csmar51 at free dot fr
Reported By: csmar51 at free dot fr
-Status: Bogus
+Status: Closed
Bug Type: Unknown/Other Function
Operating System: Linux Fedora Core 3 & Windows XP
PHP Version: 5CVS-2005-08-08 (dev)
New Comment:
Ok, thaks for your answer.
I never heard of octal numbers before, that's now done.
Previous Comments:
[2005-08-08 19:56:46] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Never heard of octal numbers, have you?
[2005-08-08 19:55:26] csmar51 at free dot fr
Description:
When we assign 08 or 09 has a variable (or in an array), this one
registers only 0. While with 01, 02, etc, this problem does not appear.
This is also reproducible everytime you use 08 or 09 as integer.
This arises with different versions of php: 4CVS-2005-08-08, 5.0.4,
5CVS-2005-08-08, 5.1.0b3. Either with a modified or default
configuration.
PHP configure line: ./configure --prefix=/www/php
./configure --prefix=/www/php
--with-apxs=/www/apache/bin/apxs
--with-config-file-path=/www/apache/conf/ --enable-versioning
--with-mm=/usr --with-libxml-dir=/usr --enable-ftp --with-gd=/usr
--with-jpeg-dir=/usr --with-png-dir=/usr --with-zlib-dir=/usr
--with-freetype-dir=/usr --enable-gd-native-ttf --with-mysql=/www/mysql
--with-mysql-sock --enable-sockets --enable-shared --enable-static
Reproduce code:
---
01, 'Feb'=>02, 'Mar'=>03, 'Apr'=>04,
'May'=>05, 'Jun'=>06,
'Jul'=>07, 'Aug'=>08, 'Sep'=>09, 'Oct'=>10,
'Nov'=>11, 'Dec'=>12);
var_dump($mon_array);
?>
Expected result:
array(12) {
["Jan"]=> int(1)
["Feb"]=> int(2)
["Mar"]=> int(3)
["Apr"]=> int(4)
["May"]=> int(5)
["Jun"]=> int(6)
["Jul"]=> int(7)
["Aug"]=> int(8)
["Sep"]=> int(9)
["Oct"]=> int(10)
["Nov"]=> int(11)
["Dec"]=> int(12)
}
Actual result:
--
array(12) {
["Jan"]=> int(1)
["Feb"]=> int(2)
["Mar"]=> int(3)
["Apr"]=> int(4)
["May"]=> int(5)
["Jun"]=> int(6)
["Jul"]=> int(7)
["Aug"]=> int(0)
["Sep"]=> int(0)
["Oct"]=> int(10)
["Nov"]=> int(11)
["Dec"]=> int(12)
}
--
Edit this bug report at http://bugs.php.net/?id=34040&edit=1
#26771 [Com]: register_tick_funtions crashes apache2 child process
ID: 26771 Comment by: fredrik at demomusic dot nu Reported By: info at tphnet dot com Status: Verified Bug Type: Apache2 related Operating System: * (ZTS only!) PHP Version: 5CVS, 4CVS (2005-06-17) New Comment: I also reported this to Apache (as it most likely is a bug in the phpXapacheX.dll binaries that are bundled with Apache): http://issues.apache.org/bugzilla/show_bug.cgi?id=36118. This can also be voted upon: http://issues.apache.org/bugzilla/votes.cgi?action=show_user&bug_id=36118, in order to get the Apache-delevopers attention. Previous Comments: [2005-08-10 13:24:23] fredrik at demomusic dot nu Some last information: solace at ezmail dot ru (http://bugs.php.net/bug.php?id=28567) has made an excellent php-profiler class, available on www.phpclasses.org. I have rewritten that profiler to side-kick as a debug-logger, an invaluable tool that I use a lot in my dev work. As soon as I am finished, it will be available for everyone, as solace's stuff is GPL. Both uses ticks. My point here is that the use of ticks on Windows is of great value, and therefore this matter should not preferably only lead to a change in the documentation (as some have suggested), but to the state where ticks work when running php as a module under apache! solace's makes an important comment in his own bugreport on this matter (marked as bogus for some reason): ""How to generate a backtrace" page is for *nix platforms, but this bug appears ONLY on Windows. All I have is event in system log "Application error Apache.exe at address x". Even Apache doesn't report it in error.log or access.log, like bug script wasn't accessed at all (Apache 1.3.27). But Windows wants to send report to Microsoft twice. And I'm not alone with this bug..." Also, this bug-report's name should preferable be "Ticks crashed Apache when running php as a module". More accurate, I believe. That's all for now... [2005-08-10 13:03:38] fredrik at demomusic dot nu Unless Zend is automatically disabled when running as cgi? I couldn't find any Zend-configurations in httpd.conf, and so I presumed that this was not the case. If I am mistaken, and this is solely a Zend-problem, please inform me and I will be posting a bug report to the Zend-team. Thank you! [2005-08-10 13:01:39] fredrik at demomusic dot nu What is with the "* (ZTS only!)"? Does it stand for Zend Thread Safety?? I am not familiar with ZTS, but shouldn't this be marked as an Windows-issue? It certainly should, is my opinion. As it works nicely when running PHP as CGI, same compile-options, same php.ini, I don't see how this could be a Zend Engine-problem... It is clearly a Windows Apache+PHP as module combination problem. Please update this report. [2005-08-10 12:54:14] fredrik at demomusic dot nu Previous bug-reports that address the exact same issue are as follows: 29 May 2004 - #28567 (Status: Bogus) Ticks crash Apache SAPI (http://bugs.php.net/bug.php?id=28567) [solace at ezmail dot ru] 28 Jan 2002 - #15267 (Status: Closed) "declare" makes apacke crashes under Windows (http://bugs.php.net/bug.php?id=) [ferguson at becon dot org] 16 May 2002 - #17283 (Status:No Feedback) register_tick_function(); [sendidmax at yahoo dot com dot cn] 18 Nov 2002 - #20486 (Status: No Feedback) register_tick_function crashes apache [junkie at overdoos dot org] 4 Aug 2004 - #29519 (Status: No Feedback) PHP5.0.0 call to declare(ticks=1) crashes apache 1.3.31 [peter dot belt at gmail dot com] Here is a short summary of those reports as well as extra info (my own). The above mentioned should be marked as Duplicates or such, and this report (#26771) should be the official bug-report of this particular problem. Please prioritize this problem, PHP-developers, as it has existed in release after release, year after year, regardless of Apache-version! Systems reported having this problem: Windows Unspec. - PHP 4.3.6 - Apache Unspec. Windows 2000- PHP 4.0.6 - Apache 1.3.20 Windows 2000- PHP 4.1.1 - Apache 1.3.22 Windows 2000- PHP 4.2.3 - Apache 1.3.22 Windows XP Pro - PHP 4.2.2 - Apache Unspec. Windows Unspec. - PHP 4.2.4-dev - Apache Unspec. Windows 2000- PHP 4.2.1 - Apache 1.3.24 Windows Unspec. - PHP 4.3.4 - Apache 2.0.48 Windows 2000- PHP 4.2.2 - Apache 1.3.22 Windows 2000- PHP 4.2.3 - Apache 1.3.22 Windows 2000- PHP 4.4.0-dev - Apache 1.3.22 Windows 2000- PHP 4.4.0-dev - Apache 2.0.43 Windows XP - PHP 5.0.0b3 - Apache 2.0.48 Windows Unspec. - PHP 5.0.0 - Apache 1.3.31 Windows XP Pro - PHP 5.0.4 - Apache 2.0.50 Windows XP Pro - PHP 5.0.4 - Apache 2.0.54 (The latest stable versions as of this comment) Va
#25359 [Asn->Csd]: array_multisort() doesn't work in a function if array is global or reference
ID: 25359
Updated by: [EMAIL PROTECTED]
Reported By: matschek at gmx dot de
-Status: Assigned
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5CVS, 4CVS (2005-07-30)
Assigned To: dmitry
New Comment:
Fixed in CVS HEAD and PHP_5_1.
Previous Comments:
[2005-07-18 02:46:29] [EMAIL PROTECTED]
Still verified. Dmitry, can you take a look?
[2005-04-25 10:05:51] [EMAIL PROTECTED]
See also bug #32817 (uses references)
[2003-09-02 06:58:16] matschek at gmx dot de
Description:
When using array_multisort in a funciton, and the array is set to
"global", array_multisort fails to sort the array.
Reproduce code:
---
function does_work() {
$data = array('first', 'fifth', 'second', 'forth', 'third');
$sort = array(1, 5, 2, 4, 3);
array_multisort($sort, $data);
print_r($data);
}
function does_not_work() {
global $data;
$data = array('first', 'fifth', 'second', 'forth', 'third');
$sort = array(1, 5, 2, 4, 3);
array_multisort($sort, $data);
print_r($data);
}
echo "function does_work():\n";
does_work();
echo "\n\nfunction does_not_work():\n";
does_not_work();
Expected result:
function does_work():
Array
(
[0] => first
[1] => second
[2] => third
[3] => forth
[4] => fifth
)
function does_not_work():
Array
(
[0] => first
[1] => second
[2] => third
[3] => forth
[4] => fifth
)
Actual result:
--
function does_work():
Array
(
[0] => first
[1] => second
[2] => third
[3] => forth
[4] => fifth
)
function does_not_work():
Array
(
[0] => first
[1] => fifth
[2] => second
[3] => forth
[4] => third
)
--
Edit this bug report at http://bugs.php.net/?id=25359&edit=1
#34067 [Opn->Bgs]: can not get correct result in some cases
ID: 34067 Updated by: [EMAIL PROTECTED] Reported By: syre at citiz dot net -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: win2000 PHP Version: 5.0.3 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. . Previous Comments: [2005-08-10 13:57:54] syre at citiz dot net Description: mysql extension can not get correct result in some cases Reproduce code: --- ( SELECT '' AS Code FROM test1£¬type as Type WHERE 1 ) UNION ALL ( SELECT code AS Code,'' as Type FROM test2 WHERE 1 ) Expected result: just as the result in mysql console Actual result: -- field Code will always be empty. if uses ( SELECT code AS Code,'' as Type FROM test2 WHERE 1 ) UNION ALL ( SELECT '' AS Code FROM test1£¬type as Type WHERE 1 ) that will ok. -- Edit this bug report at http://bugs.php.net/?id=34067&edit=1
#34068 [NEW]: Different Variable-Type after serialization
From: clemens at gutweiler dot net
Operating system: Win
PHP version: 5.1.0b3
PHP Bug Type: WDDX related
Bug description: Different Variable-Type after serialization
Description:
The vartype of the 123 key changed after serialization, it should be
consistent.
Reproduce code:
---
'zahl',
'Foo' => 'bar',
);
var_dump( $data );
var_dump( wddx_deserialize( wddx_serialize_value( $data ) ) );
highlight_file( __FILE__ );
?>
Expected result:
array(2) {
["123"]=>
string(4) "zahl"
["Foo"]=>
string(3) "bar"
}
array(2) {
["123"]=>
string(4) "zahl"
["Foo"]=>
string(3) "bar"
}
Actual result:
--
array(2) {
[123]=>
string(4) "zahl"
["Foo"]=>
string(3) "bar"
}
array(2) {
["123"]=>
string(4) "zahl"
["Foo"]=>
string(3) "bar"
}
--
Edit bug report at http://bugs.php.net/?id=34068&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34068&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34068&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34068&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34068&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34068&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34068&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34068&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34068&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34068&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34068&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34068&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34068&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34068&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34068&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34068&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34068&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34068&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34068&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34068&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34068&r=mysqlcfg
#34067 [NEW]: can not get correct result in some cases
From: syre at citiz dot net Operating system: win2000 PHP version: 5.0.3 PHP Bug Type: MySQL related Bug description: can not get correct result in some cases Description: mysql extension can not get correct result in some cases Reproduce code: --- ( SELECT '' AS Code FROM test1£¬type as Type WHERE 1 ) UNION ALL ( SELECT code AS Code,'' as Type FROM test2 WHERE 1 ) Expected result: just as the result in mysql console Actual result: -- field Code will always be empty. if uses ( SELECT code AS Code,'' as Type FROM test2 WHERE 1 ) UNION ALL ( SELECT '' AS Code FROM test1£¬type as Type WHERE 1 ) that will ok. -- Edit bug report at http://bugs.php.net/?id=34067&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34067&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34067&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34067&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34067&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34067&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34067&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34067&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34067&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34067&r=support Expected behavior: http://bugs.php.net/fix.php?id=34067&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34067&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34067&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34067&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34067&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34067&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34067&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34067&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34067&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34067&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34067&r=mysqlcfg
#26771 [Com]: register_tick_funtions crashes apache2 child process
ID: 26771 Comment by: fredrik at demomusic dot nu Reported By: info at tphnet dot com Status: Verified Bug Type: Apache2 related Operating System: * (ZTS only!) PHP Version: 5CVS, 4CVS (2005-06-17) New Comment: Some last information: solace at ezmail dot ru (http://bugs.php.net/bug.php?id=28567) has made an excellent php-profiler class, available on www.phpclasses.org. I have rewritten that profiler to side-kick as a debug-logger, an invaluable tool that I use a lot in my dev work. As soon as I am finished, it will be available for everyone, as solace's stuff is GPL. Both uses ticks. My point here is that the use of ticks on Windows is of great value, and therefore this matter should not preferably only lead to a change in the documentation (as some have suggested), but to the state where ticks work when running php as a module under apache! solace's makes an important comment in his own bugreport on this matter (marked as bogus for some reason): ""How to generate a backtrace" page is for *nix platforms, but this bug appears ONLY on Windows. All I have is event in system log "Application error Apache.exe at address x". Even Apache doesn't report it in error.log or access.log, like bug script wasn't accessed at all (Apache 1.3.27). But Windows wants to send report to Microsoft twice. And I'm not alone with this bug..." Also, this bug-report's name should preferable be "Ticks crashed Apache when running php as a module". More accurate, I believe. That's all for now... Previous Comments: [2005-08-10 13:03:38] fredrik at demomusic dot nu Unless Zend is automatically disabled when running as cgi? I couldn't find any Zend-configurations in httpd.conf, and so I presumed that this was not the case. If I am mistaken, and this is solely a Zend-problem, please inform me and I will be posting a bug report to the Zend-team. Thank you! [2005-08-10 13:01:39] fredrik at demomusic dot nu What is with the "* (ZTS only!)"? Does it stand for Zend Thread Safety?? I am not familiar with ZTS, but shouldn't this be marked as an Windows-issue? It certainly should, is my opinion. As it works nicely when running PHP as CGI, same compile-options, same php.ini, I don't see how this could be a Zend Engine-problem... It is clearly a Windows Apache+PHP as module combination problem. Please update this report. [2005-08-10 12:54:14] fredrik at demomusic dot nu Previous bug-reports that address the exact same issue are as follows: 29 May 2004 - #28567 (Status: Bogus) Ticks crash Apache SAPI (http://bugs.php.net/bug.php?id=28567) [solace at ezmail dot ru] 28 Jan 2002 - #15267 (Status: Closed) "declare" makes apacke crashes under Windows (http://bugs.php.net/bug.php?id=) [ferguson at becon dot org] 16 May 2002 - #17283 (Status:No Feedback) register_tick_function(); [sendidmax at yahoo dot com dot cn] 18 Nov 2002 - #20486 (Status: No Feedback) register_tick_function crashes apache [junkie at overdoos dot org] 4 Aug 2004 - #29519 (Status: No Feedback) PHP5.0.0 call to declare(ticks=1) crashes apache 1.3.31 [peter dot belt at gmail dot com] Here is a short summary of those reports as well as extra info (my own). The above mentioned should be marked as Duplicates or such, and this report (#26771) should be the official bug-report of this particular problem. Please prioritize this problem, PHP-developers, as it has existed in release after release, year after year, regardless of Apache-version! Systems reported having this problem: Windows Unspec. - PHP 4.3.6 - Apache Unspec. Windows 2000- PHP 4.0.6 - Apache 1.3.20 Windows 2000- PHP 4.1.1 - Apache 1.3.22 Windows 2000- PHP 4.2.3 - Apache 1.3.22 Windows XP Pro - PHP 4.2.2 - Apache Unspec. Windows Unspec. - PHP 4.2.4-dev - Apache Unspec. Windows 2000- PHP 4.2.1 - Apache 1.3.24 Windows Unspec. - PHP 4.3.4 - Apache 2.0.48 Windows 2000- PHP 4.2.2 - Apache 1.3.22 Windows 2000- PHP 4.2.3 - Apache 1.3.22 Windows 2000- PHP 4.4.0-dev - Apache 1.3.22 Windows 2000- PHP 4.4.0-dev - Apache 2.0.43 Windows XP - PHP 5.0.0b3 - Apache 2.0.48 Windows Unspec. - PHP 5.0.0 - Apache 1.3.31 Windows XP Pro - PHP 5.0.4 - Apache 2.0.50 Windows XP Pro - PHP 5.0.4 - Apache 2.0.54 (The latest stable versions as of this comment) Variant: Windows 2000 - PHP 4.0.6 - Apache 1.3.22 - No crash, but internal server error Probably a bug with php4apache2.dll and php5apache2.dll, ey? [2005-08-10 12:52:43] fredrik at demomusic dot nu It seems to be the "declare(ticks=1);" that causes the crash. Some have reported that it does not crash when the reg-function is commented out (I am one of those). Although it could al
#29519 [Com]: PHP5.0.0 call to declare(ticks=1) crashes apache 1.3.31
ID: 29519 Comment by: fredrik at demomusic dot nu Reported By: peter dot belt at gmail dot com Status: No Feedback Bug Type: Reproducible crash Operating System: win32 (XP-SP1) PHP Version: 5.0.0 New Comment: This is a duplicate. Please use this bug-report for this matter: http://bugs.php.net/bug.php?id=26771 Previous Comments: [2005-01-22 01:00:18] 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-14 23:36:42] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip [2004-08-04 11:01:46] peter dot belt at gmail dot com Description: Calling ticks(1) crashes apache 1.3.31. Plain vanilla setup from win32 pre-compiled distributions for both Apache and PHP5.0.0. Installed PEAR using all defaults and copied gd and mysql dlls to main PHP directory. That's all. When apache crashes, it comes up with the standard XP error reporting window. The data it wants to send to Microsoft includes the following: All you have to do is call is declare(ticks=1); and that's all folks. We are looking for a fix to this, or an atmitting of a permanent limitation for the win32 platform in the documentation. -- Edit this bug report at http://bugs.php.net/?id=29519&edit=1
#20486 [Com]: register_tick_function crashes apache
ID: 20486
Comment by: fredrik at demomusic dot nu
Reported By: junkie at overdoos dot org
Status: No Feedback
Bug Type: Scripting Engine problem
Operating System: win2k
PHP Version: 4.4.0-dev
New Comment:
This is a duplicate. Please use this bug-report for this matter:
http://bugs.php.net/bug.php?id=26771
Previous Comments:
[2003-01-02 18:39:46] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2002-12-19 23:08:59] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-12-08 10:56:56] [EMAIL PROTECTED]
Must be some win32 thing as I can not reproduce this within Linux (and
apache 1.3.27).
[2002-11-18 14:00:49] junkie at overdoos dot org
think it should be a scripting engine problem.. i dont know.. and its
reproduceble...
[2002-11-18 13:56:54] junkie at overdoos dot org
Register_tick_function crashes Apaches. These are the specs.
tried it on combinations of win2k with apache 1.3.22 and php as sapi
with versions 4.2.2 , 4.2.3 and 4.4.0-dev
and tried it with apache 2.0.43 with 4.4.0-dev too
the scripts was the example code from the documentation. It worked on
our cobalt server but when i wanted to use it for real when working at
home it crashed apache.
crashes an apache thread (probably) with a memory fault .. couldnt
read
from address 0x0etc . server does keep running though.
when commenting //register_tick_function() it works fine.
even leaving declare(ticks=1) {..} in tact.
Vincent.
--
Edit this bug report at http://bugs.php.net/?id=20486&edit=1
#17283 [Com]: register_tick_function();
ID: 17283 Comment by: fredrik at demomusic dot nu Reported By: sendidmax at yahoo dot com dot cn Status: No Feedback Bug Type: Scripting Engine problem Operating System: win2000 PHP Version: 4.2.1 New Comment: Please use this bug-report for this matter: http://bugs.php.net/bug.php?id=26771 Previous Comments: [2002-09-21 02:14:23] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2002-08-23 22:25:17] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-07-01 21:43:48] [EMAIL PROTECTED] duplicate of 11536 - I assume that this is supposed to indicate that if you keep reloading it, the lists gets longer and longer... [2002-05-16 23:04:40] sendidmax at yahoo dot com dot cn PHP as a module in Apache!(Apache1.3.24 + PHP4.2.1) -- Edit this bug report at http://bugs.php.net/?id=17283&edit=1
#26771 [Com]: register_tick_funtions crashes apache2 child process
ID: 26771 Comment by: fredrik at demomusic dot nu Reported By: info at tphnet dot com Status: Verified Bug Type: Apache2 related Operating System: * (ZTS only!) PHP Version: 5CVS, 4CVS (2005-06-17) New Comment: Unless Zend is automatically disabled when running as cgi? I couldn't find any Zend-configurations in httpd.conf, and so I presumed that this was not the case. If I am mistaken, and this is solely a Zend-problem, please inform me and I will be posting a bug report to the Zend-team. Thank you! Previous Comments: [2005-08-10 13:01:39] fredrik at demomusic dot nu What is with the "* (ZTS only!)"? Does it stand for Zend Thread Safety?? I am not familiar with ZTS, but shouldn't this be marked as an Windows-issue? It certainly should, is my opinion. As it works nicely when running PHP as CGI, same compile-options, same php.ini, I don't see how this could be a Zend Engine-problem... It is clearly a Windows Apache+PHP as module combination problem. Please update this report. [2005-08-10 12:54:14] fredrik at demomusic dot nu Previous bug-reports that address the exact same issue are as follows: 29 May 2004 - #28567 (Status: Bogus) Ticks crash Apache SAPI (http://bugs.php.net/bug.php?id=28567) [solace at ezmail dot ru] 28 Jan 2002 - #15267 (Status: Closed) "declare" makes apacke crashes under Windows (http://bugs.php.net/bug.php?id=) [ferguson at becon dot org] 16 May 2002 - #17283 (Status:No Feedback) register_tick_function(); [sendidmax at yahoo dot com dot cn] 18 Nov 2002 - #20486 (Status: No Feedback) register_tick_function crashes apache [junkie at overdoos dot org] 4 Aug 2004 - #29519 (Status: No Feedback) PHP5.0.0 call to declare(ticks=1) crashes apache 1.3.31 [peter dot belt at gmail dot com] Here is a short summary of those reports as well as extra info (my own). The above mentioned should be marked as Duplicates or such, and this report (#26771) should be the official bug-report of this particular problem. Please prioritize this problem, PHP-developers, as it has existed in release after release, year after year, regardless of Apache-version! Systems reported having this problem: Windows Unspec. - PHP 4.3.6 - Apache Unspec. Windows 2000- PHP 4.0.6 - Apache 1.3.20 Windows 2000- PHP 4.1.1 - Apache 1.3.22 Windows 2000- PHP 4.2.3 - Apache 1.3.22 Windows XP Pro - PHP 4.2.2 - Apache Unspec. Windows Unspec. - PHP 4.2.4-dev - Apache Unspec. Windows 2000- PHP 4.2.1 - Apache 1.3.24 Windows Unspec. - PHP 4.3.4 - Apache 2.0.48 Windows 2000- PHP 4.2.2 - Apache 1.3.22 Windows 2000- PHP 4.2.3 - Apache 1.3.22 Windows 2000- PHP 4.4.0-dev - Apache 1.3.22 Windows 2000- PHP 4.4.0-dev - Apache 2.0.43 Windows XP - PHP 5.0.0b3 - Apache 2.0.48 Windows Unspec. - PHP 5.0.0 - Apache 1.3.31 Windows XP Pro - PHP 5.0.4 - Apache 2.0.50 Windows XP Pro - PHP 5.0.4 - Apache 2.0.54 (The latest stable versions as of this comment) Variant: Windows 2000 - PHP 4.0.6 - Apache 1.3.22 - No crash, but internal server error Probably a bug with php4apache2.dll and php5apache2.dll, ey? [2005-08-10 12:52:43] fredrik at demomusic dot nu It seems to be the "declare(ticks=1);" that causes the crash. Some have reported that it does not crash when the reg-function is commented out (I am one of those). Although it could also be the combination of register_tick_function() and declare(ticks=1). Apache log when crashing: [Sat Jan 03 01:11:04 2004] [notice] Parent: child process exited with status 3221225477 -- Restarting. [Sat Jan 03 01:11:04 2004] [notice] Parent: Created child process 3036 [Sat Jan 03 01:11:04 2004] [notice] Child 3036: Child process is running [Sat Jan 03 01:11:04 2004] [notice] Child 3036: Acquired the start mutex. [Sat Jan 03 01:11:04 2004] [notice] Child 3036: Starting 250 worker threads. When apache crashes, it comes up with the standard XP error reporting window. The data it wants to send to Microsoft includes the following: Hope this helps resolve the matter more quickly! [2004-01-02 19:23:33] info at tphnet dot com Description: While searching the bug database I found some similar problems, but all were suspended. I wasn't sure if it was useful to reply to one of those (Most recent one: http://bugs.php.net/bug.php?id=26286). Well anyways, here goes: The problem is very simple. I just copy and paste the 'tick' example from the php manual into a new php file an try to execute it on my apache2 server. The apache child process crashes, restarts, crashes, restarts and eventually just stops restarting. When I comment out the line 'register_tick_functi
#26771 [Com]: register_tick_funtions crashes apache2 child process
ID: 26771 Comment by: fredrik at demomusic dot nu Reported By: info at tphnet dot com Status: Verified Bug Type: Apache2 related Operating System: * (ZTS only!) PHP Version: 5CVS, 4CVS (2005-06-17) New Comment: What is with the "* (ZTS only!)"? Does it stand for Zend Thread Safety?? I am not familiar with ZTS, but shouldn't this be marked as an Windows-issue? It certainly should, is my opinion. As it works nicely when running PHP as CGI, same compile-options, same php.ini, I don't see how this could be a Zend Engine-problem... It is clearly a Windows Apache+PHP as module combination problem. Please update this report. Previous Comments: [2005-08-10 12:54:14] fredrik at demomusic dot nu Previous bug-reports that address the exact same issue are as follows: 29 May 2004 - #28567 (Status: Bogus) Ticks crash Apache SAPI (http://bugs.php.net/bug.php?id=28567) [solace at ezmail dot ru] 28 Jan 2002 - #15267 (Status: Closed) "declare" makes apacke crashes under Windows (http://bugs.php.net/bug.php?id=) [ferguson at becon dot org] 16 May 2002 - #17283 (Status:No Feedback) register_tick_function(); [sendidmax at yahoo dot com dot cn] 18 Nov 2002 - #20486 (Status: No Feedback) register_tick_function crashes apache [junkie at overdoos dot org] 4 Aug 2004 - #29519 (Status: No Feedback) PHP5.0.0 call to declare(ticks=1) crashes apache 1.3.31 [peter dot belt at gmail dot com] Here is a short summary of those reports as well as extra info (my own). The above mentioned should be marked as Duplicates or such, and this report (#26771) should be the official bug-report of this particular problem. Please prioritize this problem, PHP-developers, as it has existed in release after release, year after year, regardless of Apache-version! Systems reported having this problem: Windows Unspec. - PHP 4.3.6 - Apache Unspec. Windows 2000- PHP 4.0.6 - Apache 1.3.20 Windows 2000- PHP 4.1.1 - Apache 1.3.22 Windows 2000- PHP 4.2.3 - Apache 1.3.22 Windows XP Pro - PHP 4.2.2 - Apache Unspec. Windows Unspec. - PHP 4.2.4-dev - Apache Unspec. Windows 2000- PHP 4.2.1 - Apache 1.3.24 Windows Unspec. - PHP 4.3.4 - Apache 2.0.48 Windows 2000- PHP 4.2.2 - Apache 1.3.22 Windows 2000- PHP 4.2.3 - Apache 1.3.22 Windows 2000- PHP 4.4.0-dev - Apache 1.3.22 Windows 2000- PHP 4.4.0-dev - Apache 2.0.43 Windows XP - PHP 5.0.0b3 - Apache 2.0.48 Windows Unspec. - PHP 5.0.0 - Apache 1.3.31 Windows XP Pro - PHP 5.0.4 - Apache 2.0.50 Windows XP Pro - PHP 5.0.4 - Apache 2.0.54 (The latest stable versions as of this comment) Variant: Windows 2000 - PHP 4.0.6 - Apache 1.3.22 - No crash, but internal server error Probably a bug with php4apache2.dll and php5apache2.dll, ey? [2005-08-10 12:52:43] fredrik at demomusic dot nu It seems to be the "declare(ticks=1);" that causes the crash. Some have reported that it does not crash when the reg-function is commented out (I am one of those). Although it could also be the combination of register_tick_function() and declare(ticks=1). Apache log when crashing: [Sat Jan 03 01:11:04 2004] [notice] Parent: child process exited with status 3221225477 -- Restarting. [Sat Jan 03 01:11:04 2004] [notice] Parent: Created child process 3036 [Sat Jan 03 01:11:04 2004] [notice] Child 3036: Child process is running [Sat Jan 03 01:11:04 2004] [notice] Child 3036: Acquired the start mutex. [Sat Jan 03 01:11:04 2004] [notice] Child 3036: Starting 250 worker threads. When apache crashes, it comes up with the standard XP error reporting window. The data it wants to send to Microsoft includes the following: Hope this helps resolve the matter more quickly! [2004-01-02 19:23:33] info at tphnet dot com Description: While searching the bug database I found some similar problems, but all were suspended. I wasn't sure if it was useful to reply to one of those (Most recent one: http://bugs.php.net/bug.php?id=26286). Well anyways, here goes: The problem is very simple. I just copy and paste the 'tick' example from the php manual into a new php file an try to execute it on my apache2 server. The apache child process crashes, restarts, crashes, restarts and eventually just stops restarting. When I comment out the line 'register_tick_function', everyting works just fine. Also, when I start the file from the CLI version of PHP it is executed without any problems. I'm using PHP 4.3.4 and Apache 2.0.48 (in conjunction with php4apache2.dll). Reproduce code: --- http://nl.php.net/manual/en/control-structures.declare.php See Example 11-1 Actual result: -- [Sat Jan 03 01:11:04 2004] [notice] Parent: child process exited with status 322
#26771 [Com]: register_tick_funtions crashes apache2 child process
ID: 26771 Comment by: fredrik at demomusic dot nu Reported By: info at tphnet dot com Status: Verified Bug Type: Apache2 related Operating System: * (ZTS only!) PHP Version: 5CVS, 4CVS (2005-06-17) New Comment: Previous bug-reports that address the exact same issue are as follows: 29 May 2004 - #28567 (Status: Bogus) Ticks crash Apache SAPI (http://bugs.php.net/bug.php?id=28567) [solace at ezmail dot ru] 28 Jan 2002 - #15267 (Status: Closed) "declare" makes apacke crashes under Windows (http://bugs.php.net/bug.php?id=) [ferguson at becon dot org] 16 May 2002 - #17283 (Status:No Feedback) register_tick_function(); [sendidmax at yahoo dot com dot cn] 18 Nov 2002 - #20486 (Status: No Feedback) register_tick_function crashes apache [junkie at overdoos dot org] 4 Aug 2004 - #29519 (Status: No Feedback) PHP5.0.0 call to declare(ticks=1) crashes apache 1.3.31 [peter dot belt at gmail dot com] Here is a short summary of those reports as well as extra info (my own). The above mentioned should be marked as Duplicates or such, and this report (#26771) should be the official bug-report of this particular problem. Please prioritize this problem, PHP-developers, as it has existed in release after release, year after year, regardless of Apache-version! Systems reported having this problem: Windows Unspec. - PHP 4.3.6 - Apache Unspec. Windows 2000- PHP 4.0.6 - Apache 1.3.20 Windows 2000- PHP 4.1.1 - Apache 1.3.22 Windows 2000- PHP 4.2.3 - Apache 1.3.22 Windows XP Pro - PHP 4.2.2 - Apache Unspec. Windows Unspec. - PHP 4.2.4-dev - Apache Unspec. Windows 2000- PHP 4.2.1 - Apache 1.3.24 Windows Unspec. - PHP 4.3.4 - Apache 2.0.48 Windows 2000- PHP 4.2.2 - Apache 1.3.22 Windows 2000- PHP 4.2.3 - Apache 1.3.22 Windows 2000- PHP 4.4.0-dev - Apache 1.3.22 Windows 2000- PHP 4.4.0-dev - Apache 2.0.43 Windows XP - PHP 5.0.0b3 - Apache 2.0.48 Windows Unspec. - PHP 5.0.0 - Apache 1.3.31 Windows XP Pro - PHP 5.0.4 - Apache 2.0.50 Windows XP Pro - PHP 5.0.4 - Apache 2.0.54 (The latest stable versions as of this comment) Variant: Windows 2000 - PHP 4.0.6 - Apache 1.3.22 - No crash, but internal server error Probably a bug with php4apache2.dll and php5apache2.dll, ey? Previous Comments: [2005-08-10 12:52:43] fredrik at demomusic dot nu It seems to be the "declare(ticks=1);" that causes the crash. Some have reported that it does not crash when the reg-function is commented out (I am one of those). Although it could also be the combination of register_tick_function() and declare(ticks=1). Apache log when crashing: [Sat Jan 03 01:11:04 2004] [notice] Parent: child process exited with status 3221225477 -- Restarting. [Sat Jan 03 01:11:04 2004] [notice] Parent: Created child process 3036 [Sat Jan 03 01:11:04 2004] [notice] Child 3036: Child process is running [Sat Jan 03 01:11:04 2004] [notice] Child 3036: Acquired the start mutex. [Sat Jan 03 01:11:04 2004] [notice] Child 3036: Starting 250 worker threads. When apache crashes, it comes up with the standard XP error reporting window. The data it wants to send to Microsoft includes the following: Hope this helps resolve the matter more quickly! [2004-01-02 19:23:33] info at tphnet dot com Description: While searching the bug database I found some similar problems, but all were suspended. I wasn't sure if it was useful to reply to one of those (Most recent one: http://bugs.php.net/bug.php?id=26286). Well anyways, here goes: The problem is very simple. I just copy and paste the 'tick' example from the php manual into a new php file an try to execute it on my apache2 server. The apache child process crashes, restarts, crashes, restarts and eventually just stops restarting. When I comment out the line 'register_tick_function', everyting works just fine. Also, when I start the file from the CLI version of PHP it is executed without any problems. I'm using PHP 4.3.4 and Apache 2.0.48 (in conjunction with php4apache2.dll). Reproduce code: --- http://nl.php.net/manual/en/control-structures.declare.php See Example 11-1 Actual result: -- [Sat Jan 03 01:11:04 2004] [notice] Parent: child process exited with status 3221225477 -- Restarting. [Sat Jan 03 01:11:04 2004] [notice] Parent: Created child process 3036 [Sat Jan 03 01:11:04 2004] [notice] Child 3036: Child process is running [Sat Jan 03 01:11:04 2004] [notice] Child 3036: Acquired the start mutex. [Sat Jan 03 01:11:04 2004] [notice] Child 3036: Starting 250 worker threads. Small snippit from my apache2 error.log. It's filled with the above lines, the status code is the same for every restart. -- Edit this bug report a
#26771 [Com]: register_tick_funtions crashes apache2 child process
ID: 26771 Comment by: fredrik at demomusic dot nu Reported By: info at tphnet dot com Status: Verified Bug Type: Apache2 related Operating System: * (ZTS only!) PHP Version: 5CVS, 4CVS (2005-06-17) New Comment: It seems to be the "declare(ticks=1);" that causes the crash. Some have reported that it does not crash when the reg-function is commented out (I am one of those). Although it could also be the combination of register_tick_function() and declare(ticks=1). Apache log when crashing: [Sat Jan 03 01:11:04 2004] [notice] Parent: child process exited with status 3221225477 -- Restarting. [Sat Jan 03 01:11:04 2004] [notice] Parent: Created child process 3036 [Sat Jan 03 01:11:04 2004] [notice] Child 3036: Child process is running [Sat Jan 03 01:11:04 2004] [notice] Child 3036: Acquired the start mutex. [Sat Jan 03 01:11:04 2004] [notice] Child 3036: Starting 250 worker threads. When apache crashes, it comes up with the standard XP error reporting window. The data it wants to send to Microsoft includes the following: Hope this helps resolve the matter more quickly! Previous Comments: [2004-01-02 19:23:33] info at tphnet dot com Description: While searching the bug database I found some similar problems, but all were suspended. I wasn't sure if it was useful to reply to one of those (Most recent one: http://bugs.php.net/bug.php?id=26286). Well anyways, here goes: The problem is very simple. I just copy and paste the 'tick' example from the php manual into a new php file an try to execute it on my apache2 server. The apache child process crashes, restarts, crashes, restarts and eventually just stops restarting. When I comment out the line 'register_tick_function', everyting works just fine. Also, when I start the file from the CLI version of PHP it is executed without any problems. I'm using PHP 4.3.4 and Apache 2.0.48 (in conjunction with php4apache2.dll). Reproduce code: --- http://nl.php.net/manual/en/control-structures.declare.php See Example 11-1 Actual result: -- [Sat Jan 03 01:11:04 2004] [notice] Parent: child process exited with status 3221225477 -- Restarting. [Sat Jan 03 01:11:04 2004] [notice] Parent: Created child process 3036 [Sat Jan 03 01:11:04 2004] [notice] Child 3036: Child process is running [Sat Jan 03 01:11:04 2004] [notice] Child 3036: Acquired the start mutex. [Sat Jan 03 01:11:04 2004] [notice] Child 3036: Starting 250 worker threads. Small snippit from my apache2 error.log. It's filled with the above lines, the status code is the same for every restart. -- Edit this bug report at http://bugs.php.net/?id=26771&edit=1
#34064 [Asn->Csd]: arr[] as param to function in class gives invalid opcode
ID: 34064 Updated by: [EMAIL PROTECTED] Reported By: phpbugreport at elexer dot com -Status: Assigned +Status: Closed Bug Type: Scripting Engine problem Operating System: * PHP Version: 5CVS-2005-08-10 Assigned To: dmitry New Comment: Closed in CVS HEAD and PHP_5_1. An additional bug - $arr[] can be passed only to function that receives argument by reference. This is fixed in CVS HEAD, PHP_5_1, PHP_5_0 and PHP_4_4. Previous Comments: [2005-08-10 11:19:33] [EMAIL PROTECTED] Dmitry, that's something you should know how to fix.. [2005-08-10 11:02:58] phpbugreport at elexer dot com Description: PHP 5.1.0-dev (cli) (built: Aug 9 2005 00:41:59) from http://snaps.php.net - compiling below code generates an Invalid opcode error. Works fine when you take the "test()" function out of the class. Reproduce code: --- test($ar[]); } } $o = new XmlTest(); $o->run(); ?> Expected result: No "Invalid opcode" error Actual result: -- Fatal error: Invalid opcode 93/16/8. in D:\php5\a.php on line 14 -- Edit this bug report at http://bugs.php.net/?id=34064&edit=1
#34066 [Opn->Fbk]: recursive array_walk causes Segmentain fault
ID: 34066 Updated by: [EMAIL PROTECTED] Reported By: ondrej at sury dot org -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Linux PHP Version: 5.0.4 New Comment: 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 Previous Comments: [2005-08-10 12:10:34] ondrej at sury dot org Description: Paul Slootman reported bug when using array_walk recursively which crashes php 5.0.4 with Segmentation Fault. In php 4.4.0 it ends with: Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 138060825 bytes) in /tmp/bug.php on line 252 Reproduce code: --- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245934 Expected result: Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 138060825 bytes) in /tmp/bug.php on line 252 Actual result: -- Segmentation fault Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x081fc929 in zend_call_function () -- Edit this bug report at http://bugs.php.net/?id=34066&edit=1
#34066 [NEW]: recursive array_walk causes Segmentain fault
From: ondrej at sury dot org Operating system: Linux PHP version: 5.0.4 PHP Bug Type: Reproducible crash Bug description: recursive array_walk causes Segmentain fault Description: Paul Slootman reported bug when using array_walk recursively which crashes php 5.0.4 with Segmentation Fault. In php 4.4.0 it ends with: Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 138060825 bytes) in /tmp/bug.php on line 252 Reproduce code: --- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245934 Expected result: Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 138060825 bytes) in /tmp/bug.php on line 252 Actual result: -- Segmentation fault Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x081fc929 in zend_call_function () -- Edit bug report at http://bugs.php.net/?id=34066&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34066&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34066&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34066&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34066&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34066&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34066&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34066&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34066&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34066&r=support Expected behavior: http://bugs.php.net/fix.php?id=34066&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34066&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34066&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34066&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34066&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34066&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34066&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34066&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34066&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34066&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34066&r=mysqlcfg
#34065 [NEW]: throw in foreach produce memory leaks
From: [EMAIL PROTECTED] Operating system: any PHP version: 5CVS-2005-08-10 (dev) PHP Bug Type: Scripting Engine problem Bug description: throw in foreach produce memory leaks Description: Throwing exception from inside a foreach block can produce memory leaks, because ZEND_SWITCH_FREE opcode is not executed. Reproduce code: --- Expected result: ok Actual result: -- memory leaks -- Edit bug report at http://bugs.php.net/?id=34065&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34065&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34065&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34065&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34065&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34065&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34065&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34065&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34065&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34065&r=support Expected behavior: http://bugs.php.net/fix.php?id=34065&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34065&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34065&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34065&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34065&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34065&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34065&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34065&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34065&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34065&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34065&r=mysqlcfg
#34064 [Ver->Asn]: arr[] as param to function in class gives invalid opcode
ID: 34064 Updated by: [EMAIL PROTECTED] Reported By: phpbugreport at elexer dot com -Status: Verified +Status: Assigned Bug Type: Scripting Engine problem Operating System: * PHP Version: 5CVS-2005-08-10 -Assigned To: +Assigned To: dmitry New Comment: Dmitry, that's something you should know how to fix.. Previous Comments: [2005-08-10 11:02:58] phpbugreport at elexer dot com Description: PHP 5.1.0-dev (cli) (built: Aug 9 2005 00:41:59) from http://snaps.php.net - compiling below code generates an Invalid opcode error. Works fine when you take the "test()" function out of the class. Reproduce code: --- test($ar[]); } } $o = new XmlTest(); $o->run(); ?> Expected result: No "Invalid opcode" error Actual result: -- Fatal error: Invalid opcode 93/16/8. in D:\php5\a.php on line 14 -- Edit this bug report at http://bugs.php.net/?id=34064&edit=1
#34064 [Opn->Ver]: arr[] as param to function in class gives invalid opcode
ID: 34064 Updated by: [EMAIL PROTECTED] Reported By: phpbugreport at elexer dot com -Status: Open +Status: Verified Bug Type: Scripting Engine problem -Operating System: WinXP +Operating System: * -PHP Version: 5CVS-2005-08-10 (dev) +PHP Version: 5CVS-2005-08-10 Previous Comments: [2005-08-10 11:02:58] phpbugreport at elexer dot com Description: PHP 5.1.0-dev (cli) (built: Aug 9 2005 00:41:59) from http://snaps.php.net - compiling below code generates an Invalid opcode error. Works fine when you take the "test()" function out of the class. Reproduce code: --- test($ar[]); } } $o = new XmlTest(); $o->run(); ?> Expected result: No "Invalid opcode" error Actual result: -- Fatal error: Invalid opcode 93/16/8. in D:\php5\a.php on line 14 -- Edit this bug report at http://bugs.php.net/?id=34064&edit=1
#34064 [NEW]: arr[] as param to function in class gives invalid opcode
From: phpbugreport at elexer dot com Operating system: WinXP PHP version: 5CVS-2005-08-10 (dev) PHP Bug Type: Scripting Engine problem Bug description: arr[] as param to function in class gives invalid opcode Description: PHP 5.1.0-dev (cli) (built: Aug 9 2005 00:41:59) from http://snaps.php.net - compiling below code generates an Invalid opcode error. Works fine when you take the "test()" function out of the class. Reproduce code: --- test($ar[]); } } $o = new XmlTest(); $o->run(); ?> Expected result: No "Invalid opcode" error Actual result: -- Fatal error: Invalid opcode 93/16/8. in D:\php5\a.php on line 14 -- Edit bug report at http://bugs.php.net/?id=34064&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34064&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34064&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34064&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34064&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34064&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34064&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34064&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34064&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34064&r=support Expected behavior: http://bugs.php.net/fix.php?id=34064&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34064&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34064&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34064&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34064&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34064&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34064&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34064&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34064&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34064&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34064&r=mysqlcfg
#34001 [Opn->Asn]: truncating value when optional display width value is used
ID: 34001
Updated by: [EMAIL PROTECTED]
Reported By: james at safesearching dot com
-Status: Open
+Status: Assigned
Bug Type: PDO related
Operating System: *
PHP Version: 5.1.0b3
-Assigned To:
+Assigned To: wez
New Comment:
Is the truncating supposed to happen?
Previous Comments:
[2005-08-10 04:01:33] james at safesearching dot com
Tested php5-200508100030, and the junk character issue seems to be
resolved, but values from the database are still being truncated.
[2005-08-05 11:20:46] [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
[2005-08-05 02:36:43] james at safesearching dot com
Description:
PDO seems to be trucating the value from MySQL when using the optional
display width syntax (ie, mediumint(4)).
>From http://dev.mysql.com/doc/mysql/en/numeric-types.html
...
The display width does not constrain the range of values that can be
stored in the column, nor the number of digits that are displayed for
values having a width exceeding that specified for the column.
I'm not sure if that is the goal of PDO here is to acutally constrain
the display width, since I occasionally get junk characters after the
specified length.
ie:
+-+
| id mediumint(4) |
+-+
| 123456 |
+-+
value from PDO is '1234', but sometimes is '1234Àd' or other junk
characters.
Reproduce code:
---
$c = new PDO(
"mysql:dbname=test;host=localhost", '***', '***'
);
// mysql mediumint
// bytes: 3
// minimum: -8388608 / 0
// maximum: 8388607 / 16777215
$c->exec('CREATE TABLE IF NOT EXISTS foo (id mediumint(4), primary key
(id));');
$c->exec("INSERT INTO foo VALUES (12345);");
$c->exec("INSERT INTO foo VALUES (1234567);");
$stmt = $c->prepare("SELECT * FROM foo");
$stmt->execute();
print_r($stmt->fetchAll());
Expected result:
Array
(
[0] => Array
(
[id] => 12345
[0] => 12345
)
[1] => Array
(
[id] => 1234567
[0] => 1234567
)
)
Actual result:
--
Array
(
[0] => Array
(
[id] => 1234
[0] => 1234
)
[1] => Array
(
[id] => 1234
[0] => 1234
)
)
--- or sometimes
Array
(
[0] => Array
(
[id] => 1234À
[0] => 1234À
)
[1] => Array
(
[id] => 1234ÀdL
[0] => 1234ÀdL
)
)
--
Edit this bug report at http://bugs.php.net/?id=34001&edit=1
#34062 [Asn]: Crash in catch block when many arguments are used
ID: 34062
Updated by: [EMAIL PROTECTED]
Reported By: feldgendler at mail dot ru
Status: Assigned
Bug Type: Reproducible crash
Operating System: Debian GNU/Linux
PHP Version: 6.0.0-dev
Assigned To: dmitry
New Comment:
No. And today is not 1st of April too.
See http://news.php.net/php.internals/17668
Previous Comments:
[2005-08-10 10:37:52] [EMAIL PROTECTED]
No, 6.0.0-dev is correct. I still have to change the snapshot's builder
though.
[2005-08-10 10:35:54] feldgendler at mail dot ru
"Version: 6.0.0-dev"
Is this a misprint?
[2005-08-10 10:19:22] [EMAIL PROTECTED]
Dmitry, take a look at it plz, I can reproduce it with the latest CVS.
[2005-08-10 08:52:45] feldgendler at mail dot ru
Description:
PHP crashes in a catch block. It happened in a real program, and I've
gradually reduced its complexity until I came to the simple testcase
I'm posting below. Both mod_php5 for Apache 2 and php5-cli crash on
this testcase.
Here is what I found during research:
In the beginning, I had multiple functions calling each other, like
this:
catch (Exception $e) {
function f2() { f3(0, 0); }
}
function f3() { f4(0, 0, 0); }
function f4() { f5(0, 0); }
...up to a quite deep nesting. I found that I can keep PHP crashing if
I carry the zeros from one function call to another, as long as their
total number does not decrese. I could even carry the zeros between the
catch block and the try block. Also I could exchange one level of
nesting for two additional zeros. So I collapsed them all in the
argument list of max(). The max() function was chosen arbitararily, any
function that takes unlimited number of arguments will do. The zeros can
also be replaced with values of any type. The crash can also be
reproduced using set_exception_handler() instead of a catch block.
Reproduce code:
---
Expected result:
(((
here
)))
Actual result:
--
(((
here
Segmentation fault
Here is the stack dump (obtained from php-cli):
#0 0x081fb0b6 in _zval_ptr_dtor ()
#1 0x0822b47c in zend_do_fcall_common_helper ()
#2 0x0823bb73 in zend_do_fcall_handler ()
#3 0x08228c39 in execute ()
#4 0x08208414 in zend_execute_scripts ()
#5 0x081ce03d in php_execute_script ()
#6 0x0824c284 in main ()
--
Edit this bug report at http://bugs.php.net/?id=34062&edit=1
#34062 [Asn]: Crash in catch block when many arguments are used
ID: 34062
Updated by: [EMAIL PROTECTED]
Reported By: feldgendler at mail dot ru
Status: Assigned
Bug Type: Reproducible crash
Operating System: Debian GNU/Linux
PHP Version: 6.0.0-dev
Assigned To: dmitry
New Comment:
No, 6.0.0-dev is correct. I still have to change the snapshot's builder
though.
Previous Comments:
[2005-08-10 10:35:54] feldgendler at mail dot ru
"Version: 6.0.0-dev"
Is this a misprint?
[2005-08-10 10:19:22] [EMAIL PROTECTED]
Dmitry, take a look at it plz, I can reproduce it with the latest CVS.
[2005-08-10 08:52:45] feldgendler at mail dot ru
Description:
PHP crashes in a catch block. It happened in a real program, and I've
gradually reduced its complexity until I came to the simple testcase
I'm posting below. Both mod_php5 for Apache 2 and php5-cli crash on
this testcase.
Here is what I found during research:
In the beginning, I had multiple functions calling each other, like
this:
catch (Exception $e) {
function f2() { f3(0, 0); }
}
function f3() { f4(0, 0, 0); }
function f4() { f5(0, 0); }
...up to a quite deep nesting. I found that I can keep PHP crashing if
I carry the zeros from one function call to another, as long as their
total number does not decrese. I could even carry the zeros between the
catch block and the try block. Also I could exchange one level of
nesting for two additional zeros. So I collapsed them all in the
argument list of max(). The max() function was chosen arbitararily, any
function that takes unlimited number of arguments will do. The zeros can
also be replaced with values of any type. The crash can also be
reproduced using set_exception_handler() instead of a catch block.
Reproduce code:
---
Expected result:
(((
here
)))
Actual result:
--
(((
here
Segmentation fault
Here is the stack dump (obtained from php-cli):
#0 0x081fb0b6 in _zval_ptr_dtor ()
#1 0x0822b47c in zend_do_fcall_common_helper ()
#2 0x0823bb73 in zend_do_fcall_handler ()
#3 0x08228c39 in execute ()
#4 0x08208414 in zend_execute_scripts ()
#5 0x081ce03d in php_execute_script ()
#6 0x0824c284 in main ()
--
Edit this bug report at http://bugs.php.net/?id=34062&edit=1
#34062 [Asn]: Crash in catch block when many arguments are used
ID: 34062
User updated by: feldgendler at mail dot ru
Reported By: feldgendler at mail dot ru
Status: Assigned
Bug Type: Reproducible crash
Operating System: Debian GNU/Linux
PHP Version: 6.0.0-dev
Assigned To: dmitry
New Comment:
"Version: 6.0.0-dev"
Is this a misprint?
Previous Comments:
[2005-08-10 10:19:22] [EMAIL PROTECTED]
Dmitry, take a look at it plz, I can reproduce it with the latest CVS.
[2005-08-10 08:52:45] feldgendler at mail dot ru
Description:
PHP crashes in a catch block. It happened in a real program, and I've
gradually reduced its complexity until I came to the simple testcase
I'm posting below. Both mod_php5 for Apache 2 and php5-cli crash on
this testcase.
Here is what I found during research:
In the beginning, I had multiple functions calling each other, like
this:
catch (Exception $e) {
function f2() { f3(0, 0); }
}
function f3() { f4(0, 0, 0); }
function f4() { f5(0, 0); }
...up to a quite deep nesting. I found that I can keep PHP crashing if
I carry the zeros from one function call to another, as long as their
total number does not decrese. I could even carry the zeros between the
catch block and the try block. Also I could exchange one level of
nesting for two additional zeros. So I collapsed them all in the
argument list of max(). The max() function was chosen arbitararily, any
function that takes unlimited number of arguments will do. The zeros can
also be replaced with values of any type. The crash can also be
reproduced using set_exception_handler() instead of a catch block.
Reproduce code:
---
Expected result:
(((
here
)))
Actual result:
--
(((
here
Segmentation fault
Here is the stack dump (obtained from php-cli):
#0 0x081fb0b6 in _zval_ptr_dtor ()
#1 0x0822b47c in zend_do_fcall_common_helper ()
#2 0x0823bb73 in zend_do_fcall_handler ()
#3 0x08228c39 in execute ()
#4 0x08208414 in zend_execute_scripts ()
#5 0x081ce03d in php_execute_script ()
#6 0x0824c284 in main ()
--
Edit this bug report at http://bugs.php.net/?id=34062&edit=1
#33940 [Opn->Csd]: array_map() fails to pass by reference when called recursively
ID: 33940
Updated by: [EMAIL PROTECTED]
Reported By: david dot tulloh at infaze dot com dot au
-Status: Open
+Status: Closed
Bug Type: Arrays related
Operating System: *
PHP Version: 5CVS-2005-08-02
-Assigned To:
+Assigned To: dmitry
New Comment:
Your expectation is wrong because array_map() receives arrays arguments
by value. To make array_map() work as you expected you should pass
arrays by reference directly.
However there is anothe bug in this case. array_map() shouldn't modify
sorce array if it isn't called by reference.
This is fixed in CVS HEAD (6.0), PHP_5_1m PHP_5_0 and PHP_4_4.
See test case for more details: ext/standard/tests/array/bug33940.phpt
Previous Comments:
[2005-08-01 05:05:50] david dot tulloh at infaze dot com dot au
Description:
array_map fails to work recursively.
It does not pass by reference in the inner array_map call.
Changing the line to
$ret = array_map('ref_map', &$item);
provides the expected result but throws a Call-time pass-by-reference
warning.
Reproduce code:
---
Expected result:
Inner return: Array
(
[0] => 2
)
Inner item: Array
(
[0] => 1
)
Array: Array
(
[0] => Array
(
[0] => 1
)
[1] => 1
)
Return: Array
(
[0] => Array
(
[0] => 2
)
[1] => 2
)
Actual result:
--
Inner return: Array
(
[0] => 2
)
Inner item: Array
(
[0] => 0
)
Array: Array
(
[0] => Array
(
[0] => 0
)
[1] => 1
)
Return: Array
(
[0] => Array
(
[0] => 2
)
[1] => 2
)
--
Edit this bug report at http://bugs.php.net/?id=33940&edit=1
#34062 [Opn->Asn]: Crash in catch block when many arguments are used
ID: 34062
Updated by: [EMAIL PROTECTED]
Reported By: feldgendler at mail dot ru
-Status: Open
+Status: Assigned
Bug Type: Reproducible crash
Operating System: Debian GNU/Linux
-PHP Version: 5.0.4
+PHP Version: 6.0.0-dev
-Assigned To:
+Assigned To: dmitry
New Comment:
Dmitry, take a look at it plz, I can reproduce it with the latest CVS.
Previous Comments:
[2005-08-10 08:52:45] feldgendler at mail dot ru
Description:
PHP crashes in a catch block. It happened in a real program, and I've
gradually reduced its complexity until I came to the simple testcase
I'm posting below. Both mod_php5 for Apache 2 and php5-cli crash on
this testcase.
Here is what I found during research:
In the beginning, I had multiple functions calling each other, like
this:
catch (Exception $e) {
function f2() { f3(0, 0); }
}
function f3() { f4(0, 0, 0); }
function f4() { f5(0, 0); }
...up to a quite deep nesting. I found that I can keep PHP crashing if
I carry the zeros from one function call to another, as long as their
total number does not decrese. I could even carry the zeros between the
catch block and the try block. Also I could exchange one level of
nesting for two additional zeros. So I collapsed them all in the
argument list of max(). The max() function was chosen arbitararily, any
function that takes unlimited number of arguments will do. The zeros can
also be replaced with values of any type. The crash can also be
reproduced using set_exception_handler() instead of a catch block.
Reproduce code:
---
Expected result:
(((
here
)))
Actual result:
--
(((
here
Segmentation fault
Here is the stack dump (obtained from php-cli):
#0 0x081fb0b6 in _zval_ptr_dtor ()
#1 0x0822b47c in zend_do_fcall_common_helper ()
#2 0x0823bb73 in zend_do_fcall_handler ()
#3 0x08228c39 in execute ()
#4 0x08208414 in zend_execute_scripts ()
#5 0x081ce03d in php_execute_script ()
#6 0x0824c284 in main ()
--
Edit this bug report at http://bugs.php.net/?id=34062&edit=1
#34063 [Opn->Bgs]: Printer functions Problem, printer_set_option does not work
ID: 34063 Updated by: [EMAIL PROTECTED] Reported By: hawk_master at web dot de -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Win XP Prog PHP Version: 5.1.0b3 New Comment: Please report PECL related bugs to the PECL bugsystem: http://pecl.php.net/bugs/ Thanks. Previous Comments: [2005-08-10 09:56:20] hawk_master at web dot de Description: Hi all, I have PHP 5.0.1 , Apache 2.0.50 on Win XP Prof SP2 I tried some example code with the printer functions I can print to a printer, but I have no chance to set some options with "printer_set_option" I tried also "PRINTER_COPIES" but no reaction from the printer. I do not know exact if this is a bug or if the printer functions does not work correct on XP? regards hawk Reproduce code: --- -- Edit this bug report at http://bugs.php.net/?id=34063&edit=1
#34063 [NEW]: Printer functions Problem, printer_set_option does not work
From: hawk_master at web dot de Operating system: Win XP Prog PHP version: 5.1.0b3 PHP Bug Type: Unknown/Other Function Bug description: Printer functions Problem, printer_set_option does not work Description: Hi all, I have PHP 5.0.1 , Apache 2.0.50 on Win XP Prof SP2 I tried some example code with the printer functions I can print to a printer, but I have no chance to set some options with "printer_set_option" I tried also "PRINTER_COPIES" but no reaction from the printer. I do not know exact if this is a bug or if the printer functions does not work correct on XP? regards hawk Reproduce code: --- -- Edit bug report at http://bugs.php.net/?id=34063&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34063&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34063&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34063&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34063&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34063&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34063&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34063&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34063&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34063&r=support Expected behavior: http://bugs.php.net/fix.php?id=34063&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34063&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34063&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34063&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34063&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34063&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34063&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34063&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34063&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34063&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34063&r=mysqlcfg
#29253 [Ver->Csd]: array_diff with $GLOBALS argument fails apache.(zend optimizer running)
ID: 29253
Updated by: [EMAIL PROTECTED]
Reported By: camka at email dot ee
-Status: Verified
+Status: Closed
Bug Type: Arrays related
Operating System: *
PHP Version: 5CVS, 4CVS (2004-08-01)
Previous Comments:
[2005-08-10 09:44:58] [EMAIL PROTECTED]
Fixed in CVS HEAD (6.0), PHP_5_1, PHP_5_0 and PHP_4_4.
[2004-08-07 13:42:32] [EMAIL PROTECTED]
To my knowledge array_diff* do not unset anything. I confirm the
behaviour under 5.1.0-dev (of 7.Aug.2004) as well as with 4.2.3 (so
this problem exists also in the old implementation of the function).
The problem appears when only $GLOBALS is used, and the latter is a
variable (array) with specific behaviour. Unfortunately I wasn't able
to reproduce similar problem with one of the other array functions.
[2004-07-20 14:40:32] camka at email dot ee
last win snapshot
when optimizer is disabled gives the following notice message and
doesn't crash
Notice: Undefined variable: zz in c:\w\test\crashme.php on line 7
NULL
seems like array_diff parameters are being unset inside the function
[2004-07-19 09:58:31] camka at email dot ee
Description:
when using array_diff with one of the parameters is $GLOBALS seems like
the whole variable scope is messed up.
Reproduce code:
---
Expected result:
expect seeing 'afad' and empty array;
Actual result:
--
array(0) { } Arra
the length of "Arra" string depends on the length of $gg length;
if uncomment the last line - apache child fails
[Mon Jul 19 10:26:00 2004] [notice] child pid 10946 exit signal
Segmentation fault (11
--
Edit this bug report at http://bugs.php.net/?id=29253&edit=1
#29253 [Ver]: array_diff with $GLOBALS argument fails apache.(zend optimizer running)
ID: 29253
Updated by: [EMAIL PROTECTED]
Reported By: camka at email dot ee
Status: Verified
Bug Type: Arrays related
Operating System: *
PHP Version: 5CVS, 4CVS (2004-08-01)
New Comment:
Fixed in CVS HEAD (6.0), PHP_5_1, PHP_5_0 and PHP_4_4.
Previous Comments:
[2004-08-07 13:42:32] [EMAIL PROTECTED]
To my knowledge array_diff* do not unset anything. I confirm the
behaviour under 5.1.0-dev (of 7.Aug.2004) as well as with 4.2.3 (so
this problem exists also in the old implementation of the function).
The problem appears when only $GLOBALS is used, and the latter is a
variable (array) with specific behaviour. Unfortunately I wasn't able
to reproduce similar problem with one of the other array functions.
[2004-07-20 14:40:32] camka at email dot ee
last win snapshot
when optimizer is disabled gives the following notice message and
doesn't crash
Notice: Undefined variable: zz in c:\w\test\crashme.php on line 7
NULL
seems like array_diff parameters are being unset inside the function
[2004-07-19 09:58:31] camka at email dot ee
Description:
when using array_diff with one of the parameters is $GLOBALS seems like
the whole variable scope is messed up.
Reproduce code:
---
Expected result:
expect seeing 'afad' and empty array;
Actual result:
--
array(0) { } Arra
the length of "Arra" string depends on the length of $gg length;
if uncomment the last line - apache child fails
[Mon Jul 19 10:26:00 2004] [notice] child pid 10946 exit signal
Segmentation fault (11
--
Edit this bug report at http://bugs.php.net/?id=29253&edit=1
