#47089 [Opn]: Shebang is printed under Windows
ID: 47089 User updated by: vr...@php.net Reported By: vr...@php.net Status: Open Bug Type: CGI related Operating System: win32 only PHP Version: 5.3.0alpha4-dev New Comment: php.exe in Windows distribution is CLI. prints "cli". Previous Comments: [2009-01-13 18:18:12] il...@php.net What SAPI are you using? [2009-01-13 12:44:46] vr...@php.net Description: The shebang line (e.g. #!/usr/bin/php) is printed in PHP 5.3.0alpha4-dev by php.exe while it was not printed in earlier versions (e.g. PHP 5.2.8). This is a backwards incompatible change which brings platform difference. Reproduce code: --- #!/usr/bin/php Expected result: 5.3.0alpha4-dev Actual result: -- #!/usr/bin/php 5.3.0alpha4-dev -- Edit this bug report at http://bugs.php.net/?id=47089&edit=1
#47096 [NEW]: move_uploaded_file not OS encoding aware
From: nuabaranda at web dot de Operating system: Windows XP PHP version: 5.2.8 PHP Bug Type: Filesystem function related Bug description: move_uploaded_file not OS encoding aware Description: Files with filenames containing non-ascii characters like german umlauts get destroyed when saved with move_uploaded_file(). The UTF-8 special characters get translated byte-wise into CP1251 characters when determining the Windows filenames thus destroying the original special characters. -- Edit bug report at http://bugs.php.net/?id=47096&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47096&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47096&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47096&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47096&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47096&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47096&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47096&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47096&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47096&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47096&r=support Expected behavior: http://bugs.php.net/fix.php?id=47096&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47096&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47096&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47096&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47096&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47096&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47096&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47096&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47096&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47096&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47096&r=mysqlcfg
#47088 [Opn->Csd]: Problems w/ session_set_save_handler when changing $_SESSION from a function
ID: 47088
User updated by: guido_jansen at gmx dot de
Reported By: guido_jansen at gmx dot de
-Status: Open
+Status: Closed
Bug Type: Session related
Operating System: Win XP
PHP Version: 5.2.8
New Comment:
This is not a bug, it was a problem with the content of the session
array. I used a key which contains a '|' (pipe) character.
This is not an allowed character for a session key, because PHP uses
this in the process of serializing session variables into ONE string.
The function issue is not reproducable, so this was not the problem.
Previous Comments:
[2009-01-14 03:49:45] typoon at gmail dot com
I am unable to reproduce the issue on PHP 5.2.8 (cli) and am unable to
reproduce on PHP 5.3.0alpha4 on both Windows XP and Linux.
Please try the code below and see if you see the issue. Perhaps you
have some code problem there?
In case you still see the issue, please provide more details on how and
where you are executing the code
http://www.zend.com/zend/spotlight/code-gallery-wade8.php
Everything works fine except one thing
If I change the $_SESSION from within a function, then the argument
which should contain the session_data is emtpy
Reproduce code:
---
session_start();
session_set_save_handler( [...] array(&$ses_class, '_write' [...]);
// ...
$_SESSION['a'] = 'b';
function temp() {
$_SESSION['c'] = 'd';
}
// ...
session_write_close(); // this will call custom _write function
-
class Session() {
// ...
function _write($id, $data) {
var_dump($data);// < here is the output
// ...
}
// ...
}
Expected result:
Inside the custom session write function, the second argument should
dump as
string(20) "a|s:1:"b";c|s:1:"d";"
Actual result:
--
Actually the output is
string(0) ""
--
Edit this bug report at http://bugs.php.net/?id=47088&edit=1
#47090 [Opn]: Memory leak in stream_socket_client when Zend is active
ID: 47090 User updated by: dominique dot fournier at grenoble dot cnrs dot fr dot Reported By: dominique dot fournier at grenoble dot cnrs dot fr dot Status: Open Bug Type: Streams related Operating System: Linux PHP Version: 5.2.8 New Comment: More informations : CVS version has the problem too. BUT : when PHP is compiled with --enable-debug option, the leak disapear. Without debug, and with USE_ZEND_ALLOC=1, the problem persist. ./configure --prefix=/usr --disable-cgi --with-config-file-path=/etc/php5/cli --with-config-file-scan-dir=/etc/php5/cli/conf.d --build=i486-linux-gnu --host=i486-linux-gnu --mandir=/usr/share/man --enable-memory-limit --with-regex=php --disable-rpath --disable-static --with-pic --with-layout=GNU --with-pear=/usr/share/php --enable-calendar --enable-sysvsem --enable-sysvshm --enable-sysvmsg --enable-track-vars --enable-trans-sid --enable-bcmath --with-bz2 --enable-ctype --with-db4 --without-gdbm --with-iconv --enable-exif --enable-filepro --enable-ftp --with-gettext --enable-mbstring --with-pcre-regex=/usr --enable-shmop --enable-sockets --enable-wddx --with-libxml-dir=/usr --with-zlib --with-kerberos=/usr --with-openssl=/usr --enable-dbx --enable-soap --enable-zip --with-mime-magic=/usr/share/file/magic.mime --with-exec-dir=/usr/lib/php5/libexec --without-mm --disable-pdo --without-mysql --without-sybase-ct --without-sqlite --enable-pcntl --with-ncurses=/usr --enable-debug OR --disable-debug Previous Comments: [2009-01-14 02:28:22] crrodriguez at opensuse dot org Cannot reproduce,memory usage is stable with 5_2 and 5_3. [2009-01-13 16:26:42] dominique dot fournier at grenoble dot cnrs dot fr dot Description: When export USE_ZEND_ALLOC=1, before run the following script in CLI, there is a memory_leak. When export USE_ZEND_ALLOC=0, the script leave on the same value. The IP in the script is available, but the port is closed (no service available on this port). Reproduce code: --- Expected result: Always the same value (in my case, when ALLOC=0, 8200) Actual result: -- 49936 50016 50044 ... repeat with an increment 30 times -- Edit this bug report at http://bugs.php.net/?id=47090&edit=1
#45546 [Com]: PCRE with utf8 kill apache childprocess
ID: 45546 Comment by: jdc at parodius dot com Reported By: kaiser at macbureau dot de Status: No Feedback Bug Type: PCRE related Operating System: FreeBSD 7 PHP Version: 5.2.6 New Comment: This bug still exists in PHP 5.2.8, which uses its own bundled version of pcre. FreeBSD 7.1-STABLE is being used here. I have a customer who is experiencing this problem on a near-daily basis (logs showing httpd SIGILL regularly). I can induce a signal 11 from the shell (using PHP CLI) executing the code provided by "hempalex at gmail dot com" as well as the code provided by "kaiser at macbureau dot de". The comment from "ale at FreeBSD.org" also applies -- the value given to str_repeat() does in fact play a role. But when run from within Apache (2.2.11 using mod_php), signal 4 (illegal instruction) happens. I'm not sure why from within Apache it's SIGILL but from the command-line it's SIGSEGV. Increasing pcre.backtrack_limit and pcre.recursion_limit does not help. Decreasing them also does not help. I'd like to urge the PHP folks to take this problem seriously. There are many of us using FreeBSD who would be more than happy to give you an account on a development/test system for you to work out the source of this problem. Previous Comments: [2008-09-26 16:17:20] nlop...@php.net again I cannot reproduce this problem. Try to adjust pcre.backtrack_limit and pcre.recursion_limit to some sane values. [2008-09-26 09:17:06] ale at FreeBSD dot org The feedback was provided. In any case the above script works if the string length is <= 2243 and stops working if > 2243 'a' chars. [2008-07-27 01:00:01] 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". [2008-07-25 13:45:15] hempalex at gmail dot com I reproduced this on FreeBSD 7.0 + Apache/2.2.9 + PHP/5.2.6 (bundled prce) script: mod_php: in apache logs: [notice] child pid 54586 exit signal Illegal instruction (4) in cli works fine! [2008-07-22 23:08:28] nikolas dot hagelstein at gmail dot com Confirmed. System: FreeBSD 7 PHP 5.2.6 (PCRE Library Version => 7.6 2008-01-28) stack size (kbytes, -s) 524288 Backtrace: #6216 0x00080407a494 in match () from /usr/local/lib/php/20060613/pcre.so # #6217 0x00080407701c in match () from /usr/local/lib/php/20060613/pcre.so # #6218 0x00080407a494 in match () from /usr/local/lib/php/20060613/pcre.so # #6219 0x00080407701c in match () from /usr/local/lib/php/20060613/pcre.so # #6220 0x000804076d05 in match () from /usr/local/lib/php/20060613/pcre.so # #6221 0x00080407f12f in php_pcre_exec () # from /usr/local/lib/php/20060613/pcre.so # # #6222 0x000804084c02 in php_pcre_match_impl () # from /usr/local/lib/php/20060613/pcre.so # #6223 0x00080408569b in php_do_pcre_match () # from /usr/local/lib/php/20060613/pcre.so # #6224 0x00538912 in zend_do_fcall_common_helper_SPEC () # #6225 0x00528603 in execute () # #6226 0x005383a4 in zend_do_fcall_common_helper_SPEC () # #6227 0x00528603 in execute () # #6228 0x00508dd3 in zend_execute_scripts () # #6229 0x004c5a5d in php_execute_script () 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/45546 -- Edit this bug report at http://bugs.php.net/?id=45546&edit=1
#45546 [Com]: PCRE with utf8 kill apache childprocess
ID: 45546 Comment by: jdc at parodius dot com Reported By: kaiser at macbureau dot de Status: No Feedback Bug Type: PCRE related Operating System: FreeBSD 7 PHP Version: 5.2.6 New Comment: I've built PHP 5.2.8 with debugging enabled, and ran the following script under PHP via the CLI, under gdb: It's important to note that if I change the str_repeat() length from 1244 to 1243, the segfault doesn't happen. The system limits: Resource limits (current): cputime infinity secs filesize infinity kB datasize 786432 kB stacksize 131072 kB coredumpsize infinity kB memoryuseinfinity kB memorylocked infinity kB maxprocesses 5547 openfiles 11095 sbsize infinity bytes vmemoryuse infinity kB Anyway, the results of the gdb backtrace are here (~790KB file): http://www.malkavian.com/~jdc/php.bug45546.backtrace.txt Hope this helps. Previous Comments: [2009-01-14 12:27:59] jdc at parodius dot com This bug still exists in PHP 5.2.8, which uses its own bundled version of pcre. FreeBSD 7.1-STABLE is being used here. I have a customer who is experiencing this problem on a near-daily basis (logs showing httpd SIGILL regularly). I can induce a signal 11 from the shell (using PHP CLI) executing the code provided by "hempalex at gmail dot com" as well as the code provided by "kaiser at macbureau dot de". The comment from "ale at FreeBSD.org" also applies -- the value given to str_repeat() does in fact play a role. But when run from within Apache (2.2.11 using mod_php), signal 4 (illegal instruction) happens. I'm not sure why from within Apache it's SIGILL but from the command-line it's SIGSEGV. Increasing pcre.backtrack_limit and pcre.recursion_limit does not help. Decreasing them also does not help. I'd like to urge the PHP folks to take this problem seriously. There are many of us using FreeBSD who would be more than happy to give you an account on a development/test system for you to work out the source of this problem. [2008-09-26 16:17:20] nlop...@php.net again I cannot reproduce this problem. Try to adjust pcre.backtrack_limit and pcre.recursion_limit to some sane values. [2008-09-26 09:17:06] ale at FreeBSD dot org The feedback was provided. In any case the above script works if the string length is <= 2243 and stops working if > 2243 'a' chars. [2008-07-27 01:00:01] 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". [2008-07-25 13:45:15] hempalex at gmail dot com I reproduced this on FreeBSD 7.0 + Apache/2.2.9 + PHP/5.2.6 (bundled prce) script: mod_php: in apache logs: [notice] child pid 54586 exit signal Illegal instruction (4) in cli works fine! 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/45546 -- Edit this bug report at http://bugs.php.net/?id=45546&edit=1
#47098 [NEW]: Apache image downloads stops
From: marcus dot aureliano at vivo dot com dot br Operating system: IBM AIX 5.3 PHP version: 5.2.8 PHP Bug Type: Apache2 related Bug description: Apache image downloads stops Description: Apache sends a tcp FIN package when serving objects grater than 1Mb. It happens often, but not all the time. We dont get any error on the logs files. Reproduce code: --- http://www.vivo.com.br/mallu5/img1.png Expected result: download all the file Actual result: -- like described, sometimes apache stop serving the files. We´ve instaled another instance with the same version and modules, and when we don´t run any PHP page the error does not occur. -- Edit bug report at http://bugs.php.net/?id=47098&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47098&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47098&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47098&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47098&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47098&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47098&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47098&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47098&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47098&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47098&r=support Expected behavior: http://bugs.php.net/fix.php?id=47098&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47098&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47098&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47098&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47098&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47098&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47098&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47098&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47098&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47098&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47098&r=mysqlcfg
#46755 [Asn->Csd]: warning: use statement with non-compound name
ID: 46755 Updated by: dmi...@php.net Reported By: david at grudl dot com -Status: Assigned +Status: Closed Bug Type: Scripting Engine problem Operating System: * PHP Version: 5.3.0alpha3 Assigned To: dmitry 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: [2009-01-01 02:54:03] cel...@php.net assign to namespace maintainer [2008-12-29 01:41:46] david at grudl dot com 1) The warning says "The use statement with non-compound name 'Foo' has no effect". This is not correct. I have posted example which show it HAS effect. Try it run in PHP. 2) "...the leading backslash is unnecessary and not allowed, as import names must be fully qualified, and are not processed relative to the current namespace." This is nonsense. If they are not processed relative, Foo is fully qualified - why developers MUST use leading backslash in some cases and MUST NOT is other cases - in all cases it is fully qualified. This should be fixed in documentation. Please, change status to Open. [2008-12-28 23:47:02] fel...@php.net "Note that for namespaced names (fully qualified namespace names containing namespace separator, such as Foo\Bar as opposed to global names that do not, such as FooBar), the leading backslash is unnecessary and not allowed, as import names must be fully qualified, and are not processed relative to the current namespace." This explain it. [2008-12-28 23:33:34] david at grudl dot com I have read it. Please, change status to Open. [2008-12-28 21:08:29] fel...@php.net Read: http://docs.php.net/manual/en/language.namespaces.importing.php 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/46755 -- Edit this bug report at http://bugs.php.net/?id=46755&edit=1
#46979 [Asn->Csd]: use with non-compound name *has* effect
ID: 46979 Updated by: dmi...@php.net Reported By: ladislav at marek dot su -Status: Assigned +Status: Closed Bug Type: Scripting Engine problem Operating System: * PHP Version: 5.3.0alpha3 Assigned To: dmitry 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: [2009-01-01 02:52:52] cel...@php.net assign to namespace maintainer [2008-12-31 09:36:09] ladislav at marek dot su Yes, but bug isn't fixed, 'use ArrayObject' is same as 'use \ArrayObject' manual is wrong. Please consider importing non-compound class or namespace names without \ prefix (remove invalid warning). [2008-12-30 23:49:09] fel...@php.net Duplicated of Bug #46755 [2008-12-30 23:38:25] ladislav at marek dot su Description: Currently php throws bogus warning with non-compound name in use statement. Reproduce code: --- namespace My; use Foo; new Foo\Bar; Expected result: Fatal error: Class 'Foo\Bar' not found in ... Actual result: -- Warning: The use statement with non-compound name 'Foo' has no effect in ... Fatal error: Class 'Foo\Bar' not found in ... 'use Foo' has effect, because fully qualified name isn't My\Foo\Bar but Foo\Bar. -- Edit this bug report at http://bugs.php.net/?id=46979&edit=1
#47099 [NEW]: PHP doesn't work with Apache 2.3
From: hjalle at sgh dot se Operating system: Debian PHP version: 5.2.8 PHP Bug Type: Apache2 related Bug description: PHP doesn't work with Apache 2.3 Description: This bug should have been worked out but it looks like it have not been that. This is the former bug: http://bugs.php.net/bug.php?id=39787&edit=2 When starting apache an error occurs. I used the latest PHP build: php5.2-200901141130 Expected result: Starting without problem Actual result: -- httpd: Syntax error on line 174 of /etc/apache23/conf/httpd.conf: Syntax error on line 5 of /etc/apache23/conf.d/php-users.conf: Cannot load /usr/lib/apache2/modules/libphp5apache23.so into server: /usr/lib/apache2/modules/libphp5apache23.so: undefined symbol: ap_get_server_version -- Edit bug report at http://bugs.php.net/?id=47099&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47099&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47099&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47099&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47099&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47099&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47099&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47099&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47099&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47099&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47099&r=support Expected behavior: http://bugs.php.net/fix.php?id=47099&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47099&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47099&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47099&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47099&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47099&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47099&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47099&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47099&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47099&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47099&r=mysqlcfg
#47100 [NEW]: Magic method __call() does not work when class is named __call
From: dreadlabs at gmail dot com Operating system: Ubuntu PHP version: 5.2.8 PHP Bug Type: Unknown/Other Function Bug description: Magic method __call() does not work when class is named __call Description: I created a class named __call, within that class i created the magic method __call. I then instantiated the __call class and tried to call a non-existent method. I then got a missing argument error from PHP, instead of it using the __call method. Reproduce code: --- test(); ?> Expected result: test Actual result: -- Warning: Missing argument 1 for __call::__call(), called in /home/tam/test.php on line 15 and defined in /home/tam/test.php on line 5 Warning: Missing argument 2 for __call::__call(), called in /home/tam/test.php on line 15 and defined in /home/tam/test.php on line 5 -- Edit bug report at http://bugs.php.net/?id=47100&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47100&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47100&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47100&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47100&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47100&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47100&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47100&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47100&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47100&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47100&r=support Expected behavior: http://bugs.php.net/fix.php?id=47100&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47100&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47100&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47100&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47100&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47100&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47100&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47100&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47100&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47100&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47100&r=mysqlcfg
#47101 [NEW]: XSLT gives an error after putting a new namespace in the DOM
From: php at mycel dot nl
Operating system: Ubuntu 8.10, Windows XP
PHP version: 5.2.8
PHP Bug Type: DOM XML related
Bug description: XSLT gives an error after putting a new namespace in the DOM
Description:
If you add a new namespace to the DOM Document then the XSLT gives an
error "undefined namespace". And if you save the DOM and load again it
works.
Reproduce code:
---
$oDOM = new DOMDocument();
$oDOM->load('random_file.xsl'); //Must be a valid XSL file with a
tag
$oDOM2 = new DOMDocument();
$oDOM2->load('random_file.xml'); //Must be a valid XML file
$oElement = $oDOM->getElementsbyTagNameNS('*', 'stylesheet')->item(0);
$oElement->setAttribute('xmlns:exsl', 'http://exslt.org/common');
$oXSLTransform = new XSLTProcessor();
$oXSLTransform->importStyleSheet($oDOM);
$oOutput = $oXSLTransform->transformToDoc($oDOM);
Expected result:
A transformed DOC document (without errors)
Actual result:
--
Warning: XSLTProcessor::importStylesheet()
[xsltprocessor.importstylesheet]: compilation error: file file.xsl line 3
element stylesheet in file.php on line 13
Warning: XSLTProcessor::importStylesheet()
[xsltprocessor.importstylesheet]: xsl:extension-element-prefix : undefined
namespace exsl in file.php on line 13
--
Edit bug report at http://bugs.php.net/?id=47101&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47101&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47101&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47101&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47101&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47101&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47101&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47101&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47101&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47101&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47101&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47101&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47101&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47101&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47101&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47101&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47101&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47101&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47101&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47101&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47101&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47101&r=mysqlcfg
#47101 [Opn->Bgs]: XSLT gives an error after putting a new namespace in the DOM
ID: 47101
Updated by: rricha...@php.net
Reported By: php at mycel dot nl
-Status: Open
+Status: Bogus
Bug Type: DOM XML related
Operating System: Ubuntu 8.10, Windows XP
PHP Version: 5.2.8
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
You need to use DOM Level 2 NS aware methods (setAttributeNS) and
properly create the namespace declaration in the XMLNS namespace
Previous Comments:
[2009-01-14 15:35:12] php at mycel dot nl
Description:
If you add a new namespace to the DOM Document then the XSLT gives an
error "undefined namespace". And if you save the DOM and load again it
works.
Reproduce code:
---
$oDOM = new DOMDocument();
$oDOM->load('random_file.xsl'); //Must be a valid XSL file with a
tag
$oDOM2 = new DOMDocument();
$oDOM2->load('random_file.xml'); //Must be a valid XML file
$oElement = $oDOM->getElementsbyTagNameNS('*', 'stylesheet')->item(0);
$oElement->setAttribute('xmlns:exsl', 'http://exslt.org/common');
$oXSLTransform = new XSLTProcessor();
$oXSLTransform->importStyleSheet($oDOM);
$oOutput = $oXSLTransform->transformToDoc($oDOM);
Expected result:
A transformed DOC document (without errors)
Actual result:
--
Warning: XSLTProcessor::importStylesheet()
[xsltprocessor.importstylesheet]: compilation error: file file.xsl line
3 element stylesheet in file.php on line 13
Warning: XSLTProcessor::importStylesheet()
[xsltprocessor.importstylesheet]: xsl:extension-element-prefix :
undefined namespace exsl in file.php on line 13
--
Edit this bug report at http://bugs.php.net/?id=47101&edit=1
#47045 [Asn->Csd]: Bug when comparing SplObjectStorage instances
ID: 47045 Updated by: col...@php.net Reported By: karsten at typo3 dot org -Status: Assigned +Status: Closed Bug Type: SPL related Operating System: Mac OS X 10.5.6 PHP Version: 5.3.0alpha3 Assigned To: colder 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: [2009-01-09 10:21:42] karsten at typo3 dot org Description: Two instances of SplObjectStorage should be considered equal only if they contain the same objects, when using == for comparison. Reproduce code: --- attach($someObject); var_dump($objectStorage === $objectStorage1); // FALSE, fine var_dump($objectStorage == $objectStorage1); // TRUE, huh? $objectStorage1->attach($someObject); var_dump($objectStorage === $objectStorage1); // FALSE, fine var_dump($objectStorage == $objectStorage1); // TRUE, fine ?> Expected result: bool(false) bool(true) bool(false) bool(false) bool(false) bool(true) Actual result: -- bool(false) bool(true) bool(false) bool(true) bool(false) bool(true) -- Edit this bug report at http://bugs.php.net/?id=47045&edit=1
#47102 [NEW]: strripos issues unepxected warning with UNICODE haystack
From: wharmby at uk dot ibm dot com
Operating system: Windows XP
PHP version: 6CVS-2009-01-14 (snap)
PHP Bug Type: Strings related
Bug description: strripos issues unepxected warning with UNICODE haystack
Description:
I get an unexpected warning msg when I specify an haystack with a non-zero
offset.
I think the problem lies in the following code in ext/standard/string.c
2913 if (haystack_type == IS_UNICODE) {
2914if (offset >= 0) {
2915 U16_FWD_N(haystack.u, cu_offset, haystack_len, offset);
2916 if (cu_offset > haystack_len - needle_len) {
2917 php_error_docref(NULL TSRMLS_CC, E_NOTICE, "Offset is greater
than the length of haystack string");
2918 RETURN_FALSE;
2919}
2920u_p = haystack.u + cu_offset;
2921u_e = haystack.u + haystack_len - needle_len;
2922 } else {
If (cu_offset > haystack_len - needle_len) then FALSE should be returned
but the warning is bogus; that should only be output if cu_offset >
haystack_len.
Reproduce code:
---
Expected result:
int(0)
bool(false)
Actual result:
--
int(0)
bool(false)
PHP Notice: strripos(): Offset is greater than the length of haystack
string in etc
--
Edit bug report at http://bugs.php.net/?id=47102&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47102&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47102&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47102&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47102&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47102&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47102&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47102&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47102&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47102&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47102&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47102&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47102&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47102&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47102&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47102&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47102&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47102&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47102&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47102&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47102&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47102&r=mysqlcfg
#47049 [Fbk->Opn]: SoapClient::__soapCall causes a segmentation fault.
ID: 47049
User updated by: uli dot staerk at globalways dot net
Reported By: uli dot staerk at globalways dot net
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Linux 2.6.16
PHP Version: 5.2.8
New Comment:
I found the reason why PHP crashed. The WSDL had an invalid
service-port-address (namespace):
Correct is:
This error is not reproduceable with other WSDL Documents, where the
following exception is thrown:
SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: Unexpected WSDL
element
Previous Comments:
[2009-01-09 12:52:53] scott...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
[2009-01-09 12:45:47] uli dot staerk at globalways dot net
WSDL: http://uli-staerk.de/temp/report.wsdl
You will need to fill in valid service-address.
[2009-01-09 11:47:46] uli dot staerk at globalways dot net
Description:
I cant not give you any further information as the example shows.
Reproduce code:
---
'; print_r($str); echo ''; }
try {
$client = new SoapClient('reporter.wsdl',
array('trace' => 1 , 'exceptions' => true)
);
// debug(debug($client->__getFunctions())); // works
$host = array('uuid' => 'foo');
$software_list = array(array('name' => 'package', 'version' =>
'1.2.3', 'state' => 'installed'));
$updates = array();
$report_id =
$client->__soapCall('reportSoftwareStatus',array($host, $software_list,
$updates));
}
catch (Exception $e) {
debug((string)$e);
}
Expected result:
segmentation fault
Actual result:
--
error message ;)
--
Edit this bug report at http://bugs.php.net/?id=47049&edit=1
#47103 [NEW]: memory leak using foreach and references
From: soywiz at gmail dot com Operating system: General PHP version: 5.2.8 PHP Bug Type: Scripting Engine problem Bug description: memory leak using foreach and references Description: This snippet causes an out of memory. It seems that it's duplicating the value (it's trying to allocate a memory chunk as large as each element on the array) and it's not freeing it. The problem persists even with a unset($v); within the foreach. I reproduced it using php 5.2.8-cli on windows and php 5.2.5-cgi on linux. I think it should work, but maybe it's a php feature? Reproduce code: --- Expected result: Don't waste all the memory Actual result: -- Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 9992 bytes) in test.php on line 3 -- Edit bug report at http://bugs.php.net/?id=47103&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47103&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47103&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47103&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47103&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47103&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47103&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47103&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47103&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47103&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47103&r=support Expected behavior: http://bugs.php.net/fix.php?id=47103&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47103&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47103&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47103&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47103&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47103&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47103&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47103&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47103&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47103&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47103&r=mysqlcfg
#47104 [NEW]: Fails to link shared extensions with icc
From: oleg dot grenrus at dynamoid dot com Operating system: Linux PHP version: 5.2.8 PHP Bug Type: Compile Failure Bug description: Fails to link shared extensions with icc Description: When compiling with icc, fails to link shared extensions. in build/libtool.m4 in AC_LIBTOOL_PROG_COMPILER_PIC([TAGNAME]) with both icpc and icc there are: _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC' but should be: _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-fpic' -- Edit bug report at http://bugs.php.net/?id=47104&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47104&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47104&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47104&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47104&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47104&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47104&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47104&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47104&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47104&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47104&r=support Expected behavior: http://bugs.php.net/fix.php?id=47104&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47104&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47104&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47104&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47104&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47104&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47104&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47104&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47104&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47104&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47104&r=mysqlcfg
#47103 [Com]: memory leak using foreach and references
ID: 47103 Comment by: crrodriguez at opensuse dot org Reported By: soywiz at gmail dot com Status: Open Bug Type: Scripting Engine problem Operating System: General PHP Version: 5.2.8 New Comment: looks like expected, do not use foreach value by reference, it is know to have "apparently unexpected behaviors" that are normal. Previous Comments: [2009-01-14 16:35:07] soywiz at gmail dot com Description: This snippet causes an out of memory. It seems that it's duplicating the value (it's trying to allocate a memory chunk as large as each element on the array) and it's not freeing it. The problem persists even with a unset($v); within the foreach. I reproduced it using php 5.2.8-cli on windows and php 5.2.5-cgi on linux. I think it should work, but maybe it's a php feature? Reproduce code: --- Expected result: Don't waste all the memory Actual result: -- Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 9992 bytes) in test.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=47103&edit=1
#47100 [Com]: Magic method __call() does not work when class is named __call
ID: 47100 Comment by: crrodriguez at opensuse dot org Reported By: dreadlabs at gmail dot com Status: Open Bug Type: Unknown/Other Function Operating System: Ubuntu PHP Version: 5.2.8 New Comment: Interesting.. in reality it IMHO should abort with a fatal error when classes are named __construct, __destruct, __call, __callStatic, __get, __set, __isset, __unset, __sleep, __wakeup, __toString, __set_state and __clone. Previous Comments: [2009-01-14 15:11:04] dreadlabs at gmail dot com Description: I created a class named __call, within that class i created the magic method __call. I then instantiated the __call class and tried to call a non-existent method. I then got a missing argument error from PHP, instead of it using the __call method. Reproduce code: --- test(); ?> Expected result: test Actual result: -- Warning: Missing argument 1 for __call::__call(), called in /home/tam/test.php on line 15 and defined in /home/tam/test.php on line 5 Warning: Missing argument 2 for __call::__call(), called in /home/tam/test.php on line 15 and defined in /home/tam/test.php on line 5 -- Edit this bug report at http://bugs.php.net/?id=47100&edit=1
#47100 [Opn]: Magic method __call() does not work when class is named __call
ID: 47100 User updated by: dreadlabs at gmail dot com Reported By: dreadlabs at gmail dot com Status: Open Bug Type: Unknown/Other Function Operating System: Ubuntu PHP Version: 5.2.8 New Comment: Personally, i dont see why you would raise a fatal error when using magic methods for class names, you're not conflicting with anything, it should allow you to use it as normal. Previous Comments: [2009-01-14 17:42:53] crrodriguez at opensuse dot org Interesting.. in reality it IMHO should abort with a fatal error when classes are named __construct, __destruct, __call, __callStatic, __get, __set, __isset, __unset, __sleep, __wakeup, __toString, __set_state and __clone. [2009-01-14 15:11:04] dreadlabs at gmail dot com Description: I created a class named __call, within that class i created the magic method __call. I then instantiated the __call class and tried to call a non-existent method. I then got a missing argument error from PHP, instead of it using the __call method. Reproduce code: --- test(); ?> Expected result: test Actual result: -- Warning: Missing argument 1 for __call::__call(), called in /home/tam/test.php on line 15 and defined in /home/tam/test.php on line 5 Warning: Missing argument 2 for __call::__call(), called in /home/tam/test.php on line 15 and defined in /home/tam/test.php on line 5 -- Edit this bug report at http://bugs.php.net/?id=47100&edit=1
#47105 [NEW]: cli crash with mysqli extension ksk2h342
From: michel dot dumontier at gmail dot com Operating system: Windows 7 beta PHP version: 5.2.8 PHP Bug Type: Reproducible crash Bug description: cli crash with mysqli extension ksk2h342 Description: Executing the CLI php.exe on Windows 7 beta when including php_mysqli.dll(by itself or with others) in the windows config file for php 5.2.8 causes a hang. This version included in XAMPP 1.7 package. Inclusion of mysqli using apache httpd seems to be fine. Reproduce code: --- php -V -- Edit bug report at http://bugs.php.net/?id=47105&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47105&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47105&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47105&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47105&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47105&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47105&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47105&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47105&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47105&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47105&r=support Expected behavior: http://bugs.php.net/fix.php?id=47105&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47105&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47105&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47105&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47105&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47105&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47105&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47105&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47105&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47105&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47105&r=mysqlcfg
#47105 [Opn->Fbk]: cli crash with mysqli extension ksk2h342
ID: 47105 Updated by: paj...@php.net Reported By: michel dot dumontier at gmail dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Windows 7 beta PHP Version: 5.2.8 New Comment: Have you installed mysql too? like mysql 5.1? Previous Comments: [2009-01-14 18:40:17] michel dot dumontier at gmail dot com Description: Executing the CLI php.exe on Windows 7 beta when including php_mysqli.dll(by itself or with others) in the windows config file for php 5.2.8 causes a hang. This version included in XAMPP 1.7 package. Inclusion of mysqli using apache httpd seems to be fine. Reproduce code: --- php -V -- Edit this bug report at http://bugs.php.net/?id=47105&edit=1
#47105 [Fbk->Opn]: cli crash with mysqli extension ksk2h342
ID: 47105 User updated by: michel dot dumontier at gmail dot com Reported By: michel dot dumontier at gmail dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Windows 7 beta PHP Version: 5.2.8 New Comment: MySQL 5.1.30 is installed. scripts will successfully execute against mysql databases. php hangs after that. Previous Comments: [2009-01-14 18:53:30] paj...@php.net Have you installed mysql too? like mysql 5.1? [2009-01-14 18:40:17] michel dot dumontier at gmail dot com Description: Executing the CLI php.exe on Windows 7 beta when including php_mysqli.dll(by itself or with others) in the windows config file for php 5.2.8 causes a hang. This version included in XAMPP 1.7 package. Inclusion of mysqli using apache httpd seems to be fine. Reproduce code: --- php -V -- Edit this bug report at http://bugs.php.net/?id=47105&edit=1
#47105 [Opn->Bgs]: cli crash with mysqli extension ksk2h342
ID: 47105 Updated by: paj...@php.net Reported By: michel dot dumontier at gmail dot com -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Windows 7 beta PHP Version: 5.2.8 New Comment: Be sure that the libmysql in PHP is used and not libmysql from mysql 5.1. It works perfectly fine here (no matter which windows, incl. win7). Not a php bug > closed (bogus). Previous Comments: [2009-01-14 18:56:05] michel dot dumontier at gmail dot com MySQL 5.1.30 is installed. scripts will successfully execute against mysql databases. php hangs after that. [2009-01-14 18:53:30] paj...@php.net Have you installed mysql too? like mysql 5.1? [2009-01-14 18:40:17] michel dot dumontier at gmail dot com Description: Executing the CLI php.exe on Windows 7 beta when including php_mysqli.dll(by itself or with others) in the windows config file for php 5.2.8 causes a hang. This version included in XAMPP 1.7 package. Inclusion of mysqli using apache httpd seems to be fine. Reproduce code: --- php -V -- Edit this bug report at http://bugs.php.net/?id=47105&edit=1
#47106 [NEW]: extending interfaces (and abstract classes) inflexible
From: rico dot moorman at gmail dot com
Operating system: Linux
PHP version: 5.2.8
PHP Bug Type: Feature/Change Request
Bug description: extending interfaces (and abstract classes) inflexible
Description:
With interfaces we are given the possibility to extend them too. We may
define additional methods. But while it's possible to add new methods it's
not possible to change the method signatures.
Within the "normal" class hierarchy on the other hand it's possible
though.
Adding this to the Interface implementation would surely lead to more
overall flexibility of the Interfaces/abstracts.
Reproduce code:
---
// interfaces to test with
interface MillableInterface { }
interface StoneInterface extends MillableInterface { }
interface WheatInterface extends MillableInterface { }
// works actually
class Mill {
function mill(MillableInterface $stuff) {}
}
class StoneMill extends Mill {
function mill(StoneInterface $stuff) {}
}
class WheatMill extends Mill {
function mill(WheatInterface $stuff) {}
}
// doesn't work
interface MillInterface {
function mill(MillableInterface $stuff);
}
interface StoneMillInterface extends MillInterface {
function mill(StoneInterface $stuff);
}
interface WheatMillInterface extends MillInterface {
function mill(WheatInterface $stuff);
}
Expected result:
no fatals ... just a working interface check
Actual result:
--
Fatal error: Can't inherit abstract function MillInterface::mill()
(previously declared abstract in StoneMillInterface) in
/home/rico/dingen.php on line 29
--
Edit bug report at http://bugs.php.net/?id=47106&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47106&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47106&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47106&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47106&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47106&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47106&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47106&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47106&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47106&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47106&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47106&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47106&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47106&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47106&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47106&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47106&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47106&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47106&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47106&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47106&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47106&r=mysqlcfg
#47089 [Opn]: Shebang is printed under Windows
ID: 47089 Updated by: il...@php.net Reported By: vr...@php.net Status: Open Bug Type: CGI related Operating System: win32 only PHP Version: 5.3.0alpha4-dev -Assigned To: +Assigned To: pierre New Comment: Pierre, Is there a problem with mmap() on windows where it ignores the start offset? Previous Comments: [2009-01-14 09:19:47] vr...@php.net php.exe in Windows distribution is CLI. prints "cli". [2009-01-13 18:18:12] il...@php.net What SAPI are you using? [2009-01-13 12:44:46] vr...@php.net Description: The shebang line (e.g. #!/usr/bin/php) is printed in PHP 5.3.0alpha4-dev by php.exe while it was not printed in earlier versions (e.g. PHP 5.2.8). This is a backwards incompatible change which brings platform difference. Reproduce code: --- #!/usr/bin/php Expected result: 5.3.0alpha4-dev Actual result: -- #!/usr/bin/php 5.3.0alpha4-dev -- Edit this bug report at http://bugs.php.net/?id=47089&edit=1
#47107 [NEW]: numbers with more than 15 digits are not behaved normally
From: mucahitkahveci at gmail dot com
Operating system: Windows xp sp2
PHP version: 5.2.8
PHP Bug Type: Scripting Engine problem
Bug description: numbers with more than 15 digits are not behaved normally
Description:
printf('%f', );
prints 7376.00
This number (555...) has 20 digits this happen in any number with more
than 15 digits
Reproduce code:
---
printf('%f', );
Expected result:
.00
Actual result:
--
7376.00
--
Edit bug report at http://bugs.php.net/?id=47107&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47107&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47107&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47107&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47107&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47107&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47107&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47107&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47107&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47107&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47107&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47107&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47107&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47107&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47107&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47107&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47107&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47107&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47107&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47107&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47107&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47107&r=mysqlcfg
#47089 [Opn->Asn]: Shebang is printed under Windows
ID: 47089 Updated by: paj...@php.net Reported By: vr...@php.net -Status: Open +Status: Assigned Bug Type: CGI related Operating System: win32 only PHP Version: 5.3.0alpha4-dev -Assigned To: pierre +Assigned To: pajoye New Comment: I have to check (assigned to me +) Previous Comments: [2009-01-14 19:31:44] il...@php.net Pierre, Is there a problem with mmap() on windows where it ignores the start offset? [2009-01-14 09:19:47] vr...@php.net php.exe in Windows distribution is CLI. prints "cli". [2009-01-13 18:18:12] il...@php.net What SAPI are you using? [2009-01-13 12:44:46] vr...@php.net Description: The shebang line (e.g. #!/usr/bin/php) is printed in PHP 5.3.0alpha4-dev by php.exe while it was not printed in earlier versions (e.g. PHP 5.2.8). This is a backwards incompatible change which brings platform difference. Reproduce code: --- #!/usr/bin/php Expected result: 5.3.0alpha4-dev Actual result: -- #!/usr/bin/php 5.3.0alpha4-dev -- Edit this bug report at http://bugs.php.net/?id=47089&edit=1
#46204 [Bgs]: Anonymous function segfaults when used in spl_autoload_register
ID: 46204
User updated by: north at sublink dot ca
Reported By: north at sublink dot ca
Status: Bogus
Bug Type: Reproducible crash
Operating System: linux 2.6
-PHP Version: 5.3.0alpha2
+PHP Version: 5.3.0alpha4-dev
New Comment:
I've tried the 2009-01-14 snapshot on linux again, and the code is
still causing a segmentation fault.
Just to be clear: it segfaults in linux, but not in windows.
Here is the code again to reproduce the bug:
# php -r 'spl_autoload_register(function($n){});new T();'
Segmentation fault
And the php version:
# php -v
PHP 5.3.0alpha4-dev (cli) (built: Jan 14 2009 01:06:21)
I'm not sure this should be marked as Bogus.
Previous Comments:
[2008-10-18 17:58:05] fel...@php.net
Ok, thanks.
[2008-10-09 01:00:01] 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".
[2008-10-02 00:09:35] north at sublink dot ca
Tested on php5.3-win32-200809251104, and it worked as expected. No
segfault.
Anything else I should try?
[2008-10-02 00:02:54] north at sublink dot ca
I've tried using the latest snapshot of 5.3 (php5.3-200810012230)
PHP 5.3.0alpha3-dev (cli) (built: Oct 1 2008 16:52:06)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2008 Zend Technologies
This still causes a segfault:
php -r 'spl_autoload_register(function($n){});new T();'
I`m running Ubuntu 8.04.1 inside of VirtualBox 2.0.2
Let me know if there is any other information that would be helpful.
[2008-10-01 23:25:38] fel...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.3-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.3-win32-installer-latest.msi
I can't reproduce 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/46204
--
Edit this bug report at http://bugs.php.net/?id=46204&edit=1
#47108 [Com]: 0xAE breaks DOMDocument's loadHTML
ID: 47108 Comment by: typoon at gmail dot com Reported By: terrafr...@php.net Status: Open Bug Type: DOM XML related Operating System: Windows XP PHP Version: 5.2.8 New Comment: The explanation to this might be the fact that ISO-8859-7 does not have the character 0xAE. When libxml tries to convert it, an error is thrown because of this. References: http://www.itscj.ipsj.or.jp/ISO-IR/227.pdf http://en.wikipedia.org/wiki/ISO_8859-7 Checking the PDF you will see 0xAE is not assigned. Quoting wikipedia: "Code values 001F, 7F, 809F, AE, D2 and FF are not assigned to characters by ISO/IEC 8859-7." More information and other reference can also be found on google. My 2 cents then are that this is not a bug at all. If you still think it is, the we might need to open a bug report for the libxml team as this is an error generated inside libxml, not PHP. Regards, Henrique Previous Comments: [2009-01-14 20:08:27] terrafr...@php.net Description: All HTML after chr(0xAE) (if present) is ignored by DOMDocument's loadHTML(), even if chr(0xAE) is a valid character per the HTML's charset. In the Reproduce code, replace chr(0xAE) with chr(0xAF) or chr(0xAD) or just remove it all together, and it works. Further, if you echo out $str and copy / paste the HTML into validator.w3.org, it's valid HTML, even with the chr(0xAE). Reproduce code: --- http://www.w3.org/TR/html4/strict.dtd";> test a' . chr(0xAE) . 'z '; $xml = new DOMDocument(); $xml->loadHTML($str); echo $xml->saveHTML(); Expected result: a�z Actual result: -- Warning: DOMDocument::loadHTML() [domdocument.loadhtml]: input conversion failed due to input error, bytes 0xAE 0x7A 0x7A 0x7A in C:\htdocs\test.php on line 14 Warning: DOMDocument::loadHTML() [domdocument.loadhtml]: input conversion failed due to input error, bytes 0xAE 0x7A 0x7A 0x7A in C:\htdocs\test.php on line 14 Warning: DOMDocument::loadHTML() [domdocument.loadhtml]: htmlCheckEncoding: encoder error in Entity, line: 4 in C:\htdocs\test.php on line 14 Warning: DOMDocument::loadHTML() [domdocument.loadhtml]: input conversion failed due to input error, bytes 0xAE 0x7A 0x7A 0x7A in C:\htdocs\test.php on line 14 a -- Edit this bug report at http://bugs.php.net/?id=47108&edit=1
#47100 [Com]: Magic method __call() does not work when class is named __call
ID: 47100 Comment by: typoon at gmail dot com Reported By: dreadlabs at gmail dot com Status: Open Bug Type: Unknown/Other Function Operating System: Ubuntu PHP Version: 5.2.8 New Comment: Think about it for a minute. If you class is called '__call' and you declare a function '__call', that one would be the constructor right? The error you experience is that you are calling the constructor without the parameters it expects. Check this code: test(); ?> So, either PHP should not allow a class to have the same name as magic methods, or you need to play with the idea that the constructor comes first. Other 'workaround' for this would be: test(); $obj2 = new __call; ?> Now you have a __construct() function, so __call can be used normally. Regards, Henrique Previous Comments: [2009-01-14 17:54:44] dreadlabs at gmail dot com Personally, i dont see why you would raise a fatal error when using magic methods for class names, you're not conflicting with anything, it should allow you to use it as normal. [2009-01-14 17:42:53] crrodriguez at opensuse dot org Interesting.. in reality it IMHO should abort with a fatal error when classes are named __construct, __destruct, __call, __callStatic, __get, __set, __isset, __unset, __sleep, __wakeup, __toString, __set_state and __clone. [2009-01-14 15:11:04] dreadlabs at gmail dot com Description: I created a class named __call, within that class i created the magic method __call. I then instantiated the __call class and tried to call a non-existent method. I then got a missing argument error from PHP, instead of it using the __call method. Reproduce code: --- test(); ?> Expected result: test Actual result: -- Warning: Missing argument 1 for __call::__call(), called in /home/tam/test.php on line 15 and defined in /home/tam/test.php on line 5 Warning: Missing argument 2 for __call::__call(), called in /home/tam/test.php on line 15 and defined in /home/tam/test.php on line 5 -- Edit this bug report at http://bugs.php.net/?id=47100&edit=1
