#36411 [NEW]: name of parameter in static method
From: Sm0ke999 at yandex dot ru Operating system: Win xp PHP version: 5.1.2 PHP Bug Type: Class/Object related Bug description: name of parameter in static method Description: Why in "static method" name of "parameter" can not be "$this" ? Reproduce code: --- x, $this->y)= array($this->y, $this->x); print_r($this); } } $o= new Base; Base::fnTest($o); ?> Expected result: Base::fnTest()Base Base Object ( [x] => y [y] => x ) Actual result: -- [Thu Feb 16 11:31:32 2006] [error] [client 192.168.0.250] PHP Fatal error: Using $this when not in object context in D:\\dev\\Site\\test.htm on line 11 -- Edit bug report at http://bugs.php.net/?id=36411&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36411&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36411&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36411&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36411&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36411&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36411&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36411&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36411&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36411&r=support Expected behavior:http://bugs.php.net/fix.php?id=36411&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36411&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36411&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36411&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36411&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36411&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36411&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36411&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36411&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36411&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36411&r=mysqlcfg
#36411 [Opn->Bgs]: name of parameter in static method
ID: 36411 Updated by: [EMAIL PROTECTED] Reported By: Sm0ke999 at yandex dot ru -Status: Open +Status: Bogus Bug Type: Class/Object related Operating System: Win xp PHP Version: 5.1.2 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. Because "$this" has a special meaning in PHP. Previous Comments: [2006-02-16 09:39:53] Sm0ke999 at yandex dot ru Description: Why in "static method" name of "parameter" can not be "$this" ? Reproduce code: --- x, $this->y)= array($this->y, $this->x); print_r($this); } } $o= new Base; Base::fnTest($o); ?> Expected result: Base::fnTest()Base Base Object ( [x] => y [y] => x ) Actual result: -- [Thu Feb 16 11:31:32 2006] [error] [client 192.168.0.250] PHP Fatal error: Using $this when not in object context in D:\\dev\\Site\\test.htm on line 11 -- Edit this bug report at http://bugs.php.net/?id=36411&edit=1
#36412 [NEW]: basename("gpg") has valgrind errors
From: [EMAIL PROTECTED]
Operating system: linux
PHP version: 5CVS-2006-02-16 (CVS)
PHP Bug Type: Strings related
Bug description: basename("gpg") has valgrind errors
Description:
basename("gpg") has valgrind errors, and for some reason uses mblen()...
Reproduce code:
---
valgrind --num-callers=24 php -r 'echo basename("gpg");'
Actual result:
--
==27568== Invalid read of size 4
==27568==at 0x4010FE7: (within /lib/ld-2.3.5.so)
==27568==by 0x400AFA9: (within /lib/ld-2.3.5.so)
==27568==by 0x4007DBD: (within /lib/ld-2.3.5.so)
==27568==by 0x45F3A6B: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x400B056: (within /lib/ld-2.3.5.so)
==27568==by 0x45F3BED: __libc_dlsym (in /lib/tls/libc-2.3.5.so)
==27568==by 0x450B54D: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x450ABD8: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x450B0E8: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x45037E0: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x456C538: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x4560DE5: mbrtowc (in /lib/tls/libc-2.3.5.so)
==27568==by 0x4518900: mblen (in /lib/tls/libc-2.3.5.so)
==27568==by 0x8300751: php_basename (string.c:1132)
==27568==by 0x8300921: zif_basename (string.c:1200)
==27568==by 0x83BE29C: execute_internal (zend_execute.c:1368)
==27568==by 0x497B40E: xdebug_execute_internal (xdebug.c:1375)
==27568==by 0x83BE83D: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:194)
==27568==by 0x83C3A33: ZEND_DO_FCALL_SPEC_CONST_HANDLER
(zend_vm_execute.h:1587)
==27568==by 0x83BE470: execute (zend_vm_execute.h:92)
==27568==by 0x497B0AA: xdebug_execute (xdebug.c:1313)
==27568==by 0x8394678: zend_eval_string (zend_execute_API.c:1091)
==27568==by 0x83947CA: zend_eval_string_ex (zend_execute_API.c:1125)
==27568==by 0x840F3DA: main (php_cli.c:1129)
==27568== Address 0x4B08A9C is 28 bytes inside a block of size 29
alloc'd
==27568==at 0x401B41A: malloc (vg_replace_malloc.c:149)
==27568==by 0x4003D27: (within /lib/ld-2.3.5.so)
==27568==by 0x40064DA: (within /lib/ld-2.3.5.so)
==27568==by 0x45F1B2F: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x400B056: (within /lib/ld-2.3.5.so)
==27568==by 0x45F24EA: _dl_open (in /lib/tls/libc-2.3.5.so)
==27568==by 0x45F39FC: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x400B056: (within /lib/ld-2.3.5.so)
==27568==by 0x45F3B5D: __libc_dlopen_mode (in /lib/tls/libc-2.3.5.so)
==27568==by 0x450B4FA: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x450ABD8: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x450B0E8: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x45037E0: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x456C538: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x4560DE5: mbrtowc (in /lib/tls/libc-2.3.5.so)
==27568==by 0x4518900: mblen (in /lib/tls/libc-2.3.5.so)
==27568==by 0x8300751: php_basename (string.c:1132)
==27568==by 0x8300921: zif_basename (string.c:1200)
==27568==by 0x83BE29C: execute_internal (zend_execute.c:1368)
==27568==by 0x497B40E: xdebug_execute_internal (xdebug.c:1375)
==27568==by 0x83BE83D: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:194)
==27568==by 0x83C3A33: ZEND_DO_FCALL_SPEC_CONST_HANDLER
(zend_vm_execute.h:1587)
==27568==by 0x83BE470: execute (zend_vm_execute.h:92)
==27568==by 0x497B0AA: xdebug_execute (xdebug.c:1313)
(turning off xdebug doesn't make a difference)
--
Edit bug report at http://bugs.php.net/?id=36412&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36412&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36412&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36412&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36412&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36412&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36412&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36412&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36412&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36412&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36412&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36412&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36412&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36412&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36412&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36412&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36412&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36412&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id
#36257 [Com]: php ini master values are reset between vhosts
ID: 36257
Comment by: david_sitecon at hotmail dot com
Reported By: cnovak at gmx dot net
Status: Feedback
Bug Type: *Configuration Issues
Operating System: Linux srv-01 2.6.12-vs2.0-gentoo
PHP Version: 4.4.2
New Comment:
We can't use 5.x yet either - is there a 4.4.x snapshot for this ?
Previous Comments:
[2006-02-11 13:21:06] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-02-02 12:56:36] cnovak at gmx dot net
Q1) Server API: Apache 2, API 20020903
Q2) We can not try 5.1
[2006-02-02 12:26:59] [EMAIL PROTECTED]
What Server API are you using?
Did you try with 5.1.x ?
[2006-02-02 12:23:52] cnovak at gmx dot net
Description:
PHI ini master values are not persistet between Apache virutal hosts.
1. php.ini setting mbstring.func_overload = 0
2. vhost www.example.com sets mbstring.func_overload = 6
3. after serving vhost www.example.com all other vhosts AND the doc
root inherit the individual mbstring.func_overload = 6 value.
ServerName www.infocenter.example.com.intra
SSLEngine on
SSLCertificateFile
/etc/apache2/ssl/www.infocenter.example.com.intra/www.infocenter.example.com.pem
SSLCertificateKeyFile
/etc/apache2/ssl/www.infocenter.example.com.intra/www.infocenter.example.com.pem
SSLCACertificateFile
/etc/apache2/ssl/www.infocenter.example.com.intra/www.infocenter.example.com.pem
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
RewriteRule /\.htaccess - [F]
php_admin_value magic_quotes_gpc 0
php_admin_value upload_tmp_dir
/www/customers/example/infocenter.example.com.intra/local/tmp
php_admin_value session.save_path
/www/customers/example/infocenter.example.com.intra/local/var/session
php_value mb_internal_encoding UTF-8
php_value mbstring.func_overload 6
php_value include_path "include"
Order deny,allow
Deny from all
AddType application/x-httpd-php .php
AddType application/x-httpd-php .php3
AddType application/x-httpd-php .php4
DocumentRoot
/www/customers/example/infocenter.example.com.intra/php-bin/
Alias /stats
/www/customers/example/infocenter.example.com.intra/stats
CustomLog
/www/customers/example/infocenter.example.com.intra/log/apache-www-actual.log
combined
ErrorLog
/www/customers/example/infocenter.example.com.intra/log/apache-error-actual.log
Reproduce code:
---
1. vhost.conf: php_value mbstring.func_overload 6
2. php.ini: mbstring.func_overload = 0
Expected result:
1. www.infocenter.example.com phpinfo mbstring.func_overload 6 0
2. www.docroot.com phpinfo mbstring.func_overload 0 0
Actual result:
--
1. www.example.com phpinfo mbstring.func_overload 6 6
2. www.docroot.com phpinfo mbstring.func_overload 6 6
--
Edit this bug report at http://bugs.php.net/?id=36257&edit=1
#36413 [NEW]: Win32 GD imagepng(): bad output to browser failure
From: smartbitcalc at hotmail dot com Operating system: Win32 (98SE, XPH/SP1) PHP version: 5CVS-2006-02-16 (snap) PHP Bug Type: GD related Bug description: Win32 GD imagepng(): bad output to browser failure Description: Win32 GD imagepng() outputs bad data to the browser when the source or any included file has extraneous whitespace surrounding the tags. Tested Systems: Windows 98 SE PHP 5CVS2006-Feb-15(snap), PHP 5.1.2, PHP 4.3.4RC1 MSIE 5.0, Firefox 1.0.6 Windows XP Home SP1 PHP 4.3.11, MSIE 6.0 (breaks on space|crlf before ) Reproduce code: --- test.php: testinc.php: _ <-- note: insert whitespace (0x20) after closing tag Expected result: Run test.php as listed and the browser displays the image as expected. Uncomment the include file, save and run test.php again, and the browser displays a "broken picture" icon. If you remove the trailing space from testinc.php the browser displays the image, but if you insert a space or a carriage return before the opening tag of either file, the image is "broken" again. (Firefox gives you the message 'The image "http://localhost/test.php"; cannot be displayed, because it contains errors' rather than a broken image icon, but the cause and effect are the same.) Actual result: -- Speculation: the problem is actually intermittent (or appears to be) but at least this is verifiable. I have a hunch that the extraneous whitespace is somehow finding its way to the output buffer as the source is being parsed. -- Edit bug report at http://bugs.php.net/?id=36413&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36413&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36413&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36413&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36413&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36413&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36413&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36413&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36413&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36413&r=support Expected behavior:http://bugs.php.net/fix.php?id=36413&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36413&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36413&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36413&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36413&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36413&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36413&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36413&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36413&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36413&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36413&r=mysqlcfg
#36407 [Opn->Fbk]: Encoding in xsl:output has no effect
ID: 36407
Updated by: [EMAIL PROTECTED]
Reported By: memoimyself at yahoo dot com dot br
-Status: Open
+Status: Feedback
Bug Type: XSLT related
Operating System: Windows XP
PHP Version: 5.1.2
New Comment:
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
Need xml doc and stylesheet you are using
Previous Comments:
[2006-02-16 02:10:23] memoimyself at yahoo dot com dot br
Description:
I have an XSL file to transform XML documents; the XSL and all XML
files are encoded in UTF-8. My PHP script is in a file also encoded in
UTF-8. The data is retrieved from a database (MySQL 5) whose character
set is UTF-8 and whose tables all have UTF-8 as their character set as
well. All the strings in all the tables are duly encoded in UTF-8.
Prior to data retrieval, the query 'SET NAMES "utf8"' is run to ensure
that all i/o operations use the same character set (UTF-8). (Hope I've
been thorough enough!)
Now, my XSL file has the following top-level (child node of the
document element, as it should be) element:
The transformation is performed by the transformToXML method of the
XSLTProcessor class.
When the code is run on a Windows server (Win XP, Apache 2.0.55,PHP
5.1.2), the result of the transformation is NEVER UTF-8 (always
iso-8859-1), even if I chage 'method' to 'xml', and even if I use a
'media-type' attribute.
When run on a Linux server (PHP 5.1.2 as well), everything goes well.
Reproduce code:
---
$xml = new DOMDocument('1.0', 'UTF-8');
$xml->loadXML($row->Report);
$xsl = new DOMDocument('1.0', 'UTF-8');
$xsl->load($xsl_file);
$proc = new XSLTProcessor;
$proc->importStyleSheet($xsl);
$report = $proc->transformToXML($xml);
Expected result:
Output string should be encoded in UTF-8.
Actual result:
--
Output string in NOT encoded in UTF-8 and accented characters appear
garbled. This problem only occurs under Windows.
--
Edit this bug report at http://bugs.php.net/?id=36407&edit=1
#36413 [Opn->Bgs]: Win32 GD imagepng(): bad output to browser failure
ID: 36413 Updated by: [EMAIL PROTECTED] Reported By: smartbitcalc at hotmail dot com -Status: Open +Status: Bogus Bug Type: GD related Operating System: Win32 (98SE, XPH/SP1) PHP Version: 5CVS-2006-02-16 (snap) 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. Of course it does this... you're outputting extra space, why should PHP not do this? This is not a bug. Previous Comments: [2006-02-16 11:11:17] smartbitcalc at hotmail dot com Description: Win32 GD imagepng() outputs bad data to the browser when the source or any included file has extraneous whitespace surrounding the tags. Tested Systems: Windows 98 SE PHP 5CVS2006-Feb-15(snap), PHP 5.1.2, PHP 4.3.4RC1 MSIE 5.0, Firefox 1.0.6 Windows XP Home SP1 PHP 4.3.11, MSIE 6.0 (breaks on space|crlf before ) Reproduce code: --- test.php: testinc.php: _ <-- note: insert whitespace (0x20) after closing tag Expected result: Run test.php as listed and the browser displays the image as expected. Uncomment the include file, save and run test.php again, and the browser displays a "broken picture" icon. If you remove the trailing space from testinc.php the browser displays the image, but if you insert a space or a carriage return before the opening tag of either file, the image is "broken" again. (Firefox gives you the message 'The image "http://localhost/test.php"; cannot be displayed, because it contains errors' rather than a broken image icon, but the cause and effect are the same.) Actual result: -- Speculation: the problem is actually intermittent (or appears to be) but at least this is verifiable. I have a hunch that the extraneous whitespace is somehow finding its way to the output buffer as the source is being parsed. -- Edit this bug report at http://bugs.php.net/?id=36413&edit=1
#36410 [Opn->Csd]: usleep() do strange behavior
ID: 36410 Updated by: [EMAIL PROTECTED] Reported By: sqchen at citiz dot net -Status: Open +Status: Closed Bug Type: Unknown/Other Function Operating System: redhat 7.3 PHP Version: 5.1.2 New Comment: While I agree, this function should not allow using negative values (fixed in CVS), float values are ok, as long as they are autoconverted to a valid integer. That's where the problem comes from: float -> int convertion may end up with negative integer value, even though float value was positive. Previous Comments: [2006-02-16 08:56:55] sqchen at citiz dot net Description: there are two questions: first: usleep(21474809); usleep(21474909); second: usleep(-1); usleep(-21474809); Actual result: -- first: usleep(21474809) wait for a long time (I am not sure hong long?) usleep(21474909) wait for 1 second second: usleep(-1) wait for a long time usleep(-21474809) wait for 0 second -- Edit this bug report at http://bugs.php.net/?id=36410&edit=1
#36413 [Bgs]: Win32 GD imagepng(): bad output to browser failure
ID: 36413 User updated by: smartbitcalc at hotmail dot com Reported By: smartbitcalc at hotmail dot com Status: Bogus Bug Type: GD related Operating System: Win32 (98SE, XPH/SP1) PHP Version: 5CVS-2006-02-16 (snap) New Comment: What a quick reply! Thanks, Derick. However -- The ability to output an image directly to the browser is exclusive to PHP's implementation of GD. Wouldn't it be a good idea to, say, update either the documentation or the library so that people don't keep reporting the same "bogus" issue? Previous Comments: [2006-02-16 11:16:40] [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. Of course it does this... you're outputting extra space, why should PHP not do this? This is not a bug. [2006-02-16 11:11:17] smartbitcalc at hotmail dot com Description: Win32 GD imagepng() outputs bad data to the browser when the source or any included file has extraneous whitespace surrounding the tags. Tested Systems: Windows 98 SE PHP 5CVS2006-Feb-15(snap), PHP 5.1.2, PHP 4.3.4RC1 MSIE 5.0, Firefox 1.0.6 Windows XP Home SP1 PHP 4.3.11, MSIE 6.0 (breaks on space|crlf before ) Reproduce code: --- test.php: testinc.php: _ <-- note: insert whitespace (0x20) after closing tag Expected result: Run test.php as listed and the browser displays the image as expected. Uncomment the include file, save and run test.php again, and the browser displays a "broken picture" icon. If you remove the trailing space from testinc.php the browser displays the image, but if you insert a space or a carriage return before the opening tag of either file, the image is "broken" again. (Firefox gives you the message 'The image "http://localhost/test.php"; cannot be displayed, because it contains errors' rather than a broken image icon, but the cause and effect are the same.) Actual result: -- Speculation: the problem is actually intermittent (or appears to be) but at least this is verifiable. I have a hunch that the extraneous whitespace is somehow finding its way to the output buffer as the source is being parsed. -- Edit this bug report at http://bugs.php.net/?id=36413&edit=1
#36412 [Opn]: basename("gpg") has valgrind errors
ID: 36412
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Strings related
Operating System: linux
PHP Version: 5CVS-2006-02-16 (CVS)
New Comment:
Just for the record: not reproducible on machines I have around here
(glibc 2.3.2/2.3.3/2.3.4).
Seems like glibc (or glibc-related) issue.
Previous Comments:
[2006-02-16 10:36:51] [EMAIL PROTECTED]
Description:
basename("gpg") has valgrind errors, and for some reason uses
mblen()...
Reproduce code:
---
valgrind --num-callers=24 php -r 'echo basename("gpg");'
Actual result:
--
==27568== Invalid read of size 4
==27568==at 0x4010FE7: (within /lib/ld-2.3.5.so)
==27568==by 0x400AFA9: (within /lib/ld-2.3.5.so)
==27568==by 0x4007DBD: (within /lib/ld-2.3.5.so)
==27568==by 0x45F3A6B: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x400B056: (within /lib/ld-2.3.5.so)
==27568==by 0x45F3BED: __libc_dlsym (in /lib/tls/libc-2.3.5.so)
==27568==by 0x450B54D: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x450ABD8: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x450B0E8: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x45037E0: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x456C538: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x4560DE5: mbrtowc (in /lib/tls/libc-2.3.5.so)
==27568==by 0x4518900: mblen (in /lib/tls/libc-2.3.5.so)
==27568==by 0x8300751: php_basename (string.c:1132)
==27568==by 0x8300921: zif_basename (string.c:1200)
==27568==by 0x83BE29C: execute_internal (zend_execute.c:1368)
==27568==by 0x497B40E: xdebug_execute_internal (xdebug.c:1375)
==27568==by 0x83BE83D: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:194)
==27568==by 0x83C3A33: ZEND_DO_FCALL_SPEC_CONST_HANDLER
(zend_vm_execute.h:1587)
==27568==by 0x83BE470: execute (zend_vm_execute.h:92)
==27568==by 0x497B0AA: xdebug_execute (xdebug.c:1313)
==27568==by 0x8394678: zend_eval_string (zend_execute_API.c:1091)
==27568==by 0x83947CA: zend_eval_string_ex
(zend_execute_API.c:1125)
==27568==by 0x840F3DA: main (php_cli.c:1129)
==27568== Address 0x4B08A9C is 28 bytes inside a block of size 29
alloc'd
==27568==at 0x401B41A: malloc (vg_replace_malloc.c:149)
==27568==by 0x4003D27: (within /lib/ld-2.3.5.so)
==27568==by 0x40064DA: (within /lib/ld-2.3.5.so)
==27568==by 0x45F1B2F: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x400B056: (within /lib/ld-2.3.5.so)
==27568==by 0x45F24EA: _dl_open (in /lib/tls/libc-2.3.5.so)
==27568==by 0x45F39FC: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x400B056: (within /lib/ld-2.3.5.so)
==27568==by 0x45F3B5D: __libc_dlopen_mode (in
/lib/tls/libc-2.3.5.so)
==27568==by 0x450B4FA: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x450ABD8: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x450B0E8: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x45037E0: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x456C538: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x4560DE5: mbrtowc (in /lib/tls/libc-2.3.5.so)
==27568==by 0x4518900: mblen (in /lib/tls/libc-2.3.5.so)
==27568==by 0x8300751: php_basename (string.c:1132)
==27568==by 0x8300921: zif_basename (string.c:1200)
==27568==by 0x83BE29C: execute_internal (zend_execute.c:1368)
==27568==by 0x497B40E: xdebug_execute_internal (xdebug.c:1375)
==27568==by 0x83BE83D: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:194)
==27568==by 0x83C3A33: ZEND_DO_FCALL_SPEC_CONST_HANDLER
(zend_vm_execute.h:1587)
==27568==by 0x83BE470: execute (zend_vm_execute.h:92)
==27568==by 0x497B0AA: xdebug_execute (xdebug.c:1313)
(turning off xdebug doesn't make a difference)
--
Edit this bug report at http://bugs.php.net/?id=36412&edit=1
#36412 [Opn->Asn]: basename("gpg") has valgrind errors
ID: 36412
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Assigned
Bug Type: Strings related
Operating System: linux
PHP Version: 5CVS-2006-02-16 (CVS)
-Assigned To:
+Assigned To: derick
Previous Comments:
[2006-02-16 11:50:24] [EMAIL PROTECTED]
Just for the record: not reproducible on machines I have around here
(glibc 2.3.2/2.3.3/2.3.4).
Seems like glibc (or glibc-related) issue.
[2006-02-16 10:36:51] [EMAIL PROTECTED]
Description:
basename("gpg") has valgrind errors, and for some reason uses
mblen()...
Reproduce code:
---
valgrind --num-callers=24 php -r 'echo basename("gpg");'
Actual result:
--
==27568== Invalid read of size 4
==27568==at 0x4010FE7: (within /lib/ld-2.3.5.so)
==27568==by 0x400AFA9: (within /lib/ld-2.3.5.so)
==27568==by 0x4007DBD: (within /lib/ld-2.3.5.so)
==27568==by 0x45F3A6B: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x400B056: (within /lib/ld-2.3.5.so)
==27568==by 0x45F3BED: __libc_dlsym (in /lib/tls/libc-2.3.5.so)
==27568==by 0x450B54D: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x450ABD8: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x450B0E8: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x45037E0: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x456C538: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x4560DE5: mbrtowc (in /lib/tls/libc-2.3.5.so)
==27568==by 0x4518900: mblen (in /lib/tls/libc-2.3.5.so)
==27568==by 0x8300751: php_basename (string.c:1132)
==27568==by 0x8300921: zif_basename (string.c:1200)
==27568==by 0x83BE29C: execute_internal (zend_execute.c:1368)
==27568==by 0x497B40E: xdebug_execute_internal (xdebug.c:1375)
==27568==by 0x83BE83D: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:194)
==27568==by 0x83C3A33: ZEND_DO_FCALL_SPEC_CONST_HANDLER
(zend_vm_execute.h:1587)
==27568==by 0x83BE470: execute (zend_vm_execute.h:92)
==27568==by 0x497B0AA: xdebug_execute (xdebug.c:1313)
==27568==by 0x8394678: zend_eval_string (zend_execute_API.c:1091)
==27568==by 0x83947CA: zend_eval_string_ex
(zend_execute_API.c:1125)
==27568==by 0x840F3DA: main (php_cli.c:1129)
==27568== Address 0x4B08A9C is 28 bytes inside a block of size 29
alloc'd
==27568==at 0x401B41A: malloc (vg_replace_malloc.c:149)
==27568==by 0x4003D27: (within /lib/ld-2.3.5.so)
==27568==by 0x40064DA: (within /lib/ld-2.3.5.so)
==27568==by 0x45F1B2F: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x400B056: (within /lib/ld-2.3.5.so)
==27568==by 0x45F24EA: _dl_open (in /lib/tls/libc-2.3.5.so)
==27568==by 0x45F39FC: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x400B056: (within /lib/ld-2.3.5.so)
==27568==by 0x45F3B5D: __libc_dlopen_mode (in
/lib/tls/libc-2.3.5.so)
==27568==by 0x450B4FA: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x450ABD8: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x450B0E8: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x45037E0: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x456C538: (within /lib/tls/libc-2.3.5.so)
==27568==by 0x4560DE5: mbrtowc (in /lib/tls/libc-2.3.5.so)
==27568==by 0x4518900: mblen (in /lib/tls/libc-2.3.5.so)
==27568==by 0x8300751: php_basename (string.c:1132)
==27568==by 0x8300921: zif_basename (string.c:1200)
==27568==by 0x83BE29C: execute_internal (zend_execute.c:1368)
==27568==by 0x497B40E: xdebug_execute_internal (xdebug.c:1375)
==27568==by 0x83BE83D: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:194)
==27568==by 0x83C3A33: ZEND_DO_FCALL_SPEC_CONST_HANDLER
(zend_vm_execute.h:1587)
==27568==by 0x83BE470: execute (zend_vm_execute.h:92)
==27568==by 0x497B0AA: xdebug_execute (xdebug.c:1313)
(turning off xdebug doesn't make a difference)
--
Edit this bug report at http://bugs.php.net/?id=36412&edit=1
#36414 [NEW]: imap_open can't connect with login = '[EMAIL PROTECTED]'
From: ldehon at i-puzzle dot fr
Operating system: Windows XP/2003
PHP version: 5.1.2
PHP Bug Type: IMAP related
Bug description: imap_open can't connect with login = '[EMAIL PROTECTED]'
Description:
I've an error when trying to connect with imap_open on a server which need
the full email adress to connect like "[EMAIL PROTECTED]"
PHP send me this error :
Couldn't open stream {pop..com:110/pop3}INBOX
and imap_errors() tell me "Can't login to this server."
I've tried the same code on a different pop3 server which username don't
need the domain and it works.
Thanks in advanced
Reproduce code:
---
$sServer= "pop..com";
$sPort = "110";
$sLogin = "[EMAIL PROTECTED]";
$sPassword = "mypassword";
$rIMAP = imap_open("{" . $sServer . ":" . $sPort . "/pop3}INBOX", $sLogin,
$sPassword);
imap_close($rIMAP);
--
Edit bug report at http://bugs.php.net/?id=36414&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36414&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36414&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36414&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36414&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36414&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36414&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36414&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36414&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36414&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36414&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36414&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36414&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36414&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36414&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36414&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36414&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36414&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36414&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36414&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36414&r=mysqlcfg
#36415 [NEW]: transformToXML will NOT output UTF-8
From: memoimyself at yahoo dot com dot br
Operating system: Windows XP
PHP version: 5.1.2
PHP Bug Type: XSLT related
Bug description: transformToXML will NOT output UTF-8
Description:
An instance of the XSLTProcessor class, via its transformToXML method, is
used to transform XML documents using an XSL stylesheet.
The XSL document is in a file that is encoded in UTF-8.
The PHP script is in a file also encoded in UTF-8.
The XML documents are created at run time from XML strings stored in a
MySQL 5 database whose character set is
UTF-8 and whose tables all have UTF-8 as their character set as well.
All the XML strings stored in the database are duly encoded in UTF-8.
Prior to data retrieval, a 'SET NAMES "utf8"' query is run to ensure that
all i/o operations use the UTF-8 character set.
Upon transformation, the results are output to the client preceded by
"header('Content-Type: text/html; charset=UTF-8')" to ensure that the
browser uses the correct character set.
The XSL file has the following top-level (child node of the document
element, as it should be) element:
When this code is run on a Windows server (Win XP, Apache 2.0.55,PHP
5.1.2), the transformation NEVER outputs UTF-8 text (seems to output
iso-8859-1), even if the 'method' attribute in the above element is
changed to 'xml', and even if a 'media-type' attribute is also used.
When run on a Linux server (also running PHP 5.1.2), the transformation
runs as expected and outputs proper UTF-8 text to the browser.
Reproduce code:
---
PHP code:
$dbo = new PDO(BD_DSN, BD_USERNAME, BD_PWD);
$dbo->query('SET NAMES "utf8"');
$sql = 'SELECT Report FROM reports WHERE Id =
'.$dbo->quote(strip_gpc_slashes($_GET['rid'])).'
AND Author = '.$dbo->quote($_SESSION['user']);
$result = $dbo->query($sql);
$row = $result->fetch(PDO::FETCH_OBJ);
$xml = new DOMDocument('1.0', 'UTF-8');
$xml->loadXML($row->Report);
$xsl = new DOMDocument('1.0', 'UTF-8');
$xsl->load('/path/to/xsl/file.xsl');
$proc = new XSLTProcessor;
$proc->importStyleSheet($xsl);
$output = $proc->transformToXML($xml);
header('Content-Type: text/html; charset=utf-8');
print $output;
Start of XSL document:
http://www.w3.org/1999/XSL/Transform";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://www.w3.org/2005/11/schema-for-xslt20.xsd";>
...
Expected result:
All text output to the browser should be proper UTF-8. If the browser's
character encoding is set to UTF-8 (which it should, with the
"content-type" header above), all accented character should be adequately
displayed.
Actual result:
--
When the code is run on a Windows XP server, the text output to the
browser is NOT proper UTF-8 and all accented characters are replaced by
weird symbols.
When the code is run on a Linux server (also equipped with PHP 5.1.2),
everything works as expected and the output is proper UTF-8.
--
Edit bug report at http://bugs.php.net/?id=36415&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36415&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36415&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36415&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36415&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36415&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36415&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36415&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36415&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36415&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36415&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36415&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36415&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36415&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36415&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36415&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36415&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36415&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36415&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36415&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36415&r=mysqlcfg
#36416 [NEW]: XSLT stylesheet can't be processed more
From: fidanza at uniroma3 dot it
Operating system: Windows Server 2003
PHP version: 5.1.2
PHP Bug Type: XSLT related
Bug description: XSLT stylesheet can't be processed more
Description:
A simple xslt stylesheet used on a production website with php 5.0.4
doesn't work more since we installed php 5.1.2.ù
Reproduce code:
---
PHP code:
public function loadXslFile(filewrapper $xslFile) {
$this->xslDom->load( $xslFile->getFileName() );
$this->xslProcessor->importStylesheet( $this->xslDom );
}
XSLT file:
http://www.w3.org/1999/XSL/Transform";>
::
Expected result:
The XSLT is expected to return the title attribute of a node element which
id matches 'current' param value.
Actual result:
--
We obtain the message:
XSLTProcessor::importStylesheet() [function.importStylesheet]: Undefined
variable
Trying to extend the scope of xsl:param to enclose the whole template will
result in:
XSLTProcessor::importStylesheet() [function.importStylesheet]: compilation
error: file D:/InetPub/wwwroot/www.uniroma3.it/xml/pagetitle.xsl line 6
element template
--
Edit bug report at http://bugs.php.net/?id=36416&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36416&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36416&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36416&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36416&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36416&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36416&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36416&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36416&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36416&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36416&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36416&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36416&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36416&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36416&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36416&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36416&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36416&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36416&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36416&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36416&r=mysqlcfg
#36416 [Opn->Fbk]: XSLT stylesheet can't be processed more
ID: 36416
Updated by: [EMAIL PROTECTED]
Reported By: fidanza at uniroma3 dot it
-Status: Open
+Status: Feedback
Bug Type: XSLT related
Operating System: Windows Server 2003
PHP Version: 5.1.2
New Comment:
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.
Previous Comments:
[2006-02-16 13:03:46] fidanza at uniroma3 dot it
Description:
A simple xslt stylesheet used on a production website with php 5.0.4
doesn't work more since we installed php 5.1.2.ù
Reproduce code:
---
PHP code:
public function loadXslFile(filewrapper $xslFile) {
$this->xslDom->load( $xslFile->getFileName() );
$this->xslProcessor->importStylesheet( $this->xslDom );
}
XSLT file:
http://www.w3.org/1999/XSL/Transform";>
::
Expected result:
The XSLT is expected to return the title attribute of a node element
which id matches 'current' param value.
Actual result:
--
We obtain the message:
XSLTProcessor::importStylesheet() [function.importStylesheet]:
Undefined variable
Trying to extend the scope of xsl:param to enclose the whole template
will result in:
XSLTProcessor::importStylesheet() [function.importStylesheet]:
compilation error: file
D:/InetPub/wwwroot/www.uniroma3.it/xml/pagetitle.xsl line 6 element
template
--
Edit this bug report at http://bugs.php.net/?id=36416&edit=1
#36416 [Fbk->Bgs]: XSLT stylesheet can't be processed more
ID: 36416
Updated by: [EMAIL PROTECTED]
Reported By: fidanza at uniroma3 dot it
-Status: Feedback
+Status: Bogus
Bug Type: XSLT related
Operating System: Windows Server 2003
PHP Version: 5.1.2
New Comment:
Not a php issue, but a libxslt "issue". xsltproc brings the
same error, but variables in matchers are not allowed
according to the specs, anyway.
See http://www.w3.org/TR/xslt#section-Defining-Template-Rules:
"It is an error for the value of the match attribute to
contain a VariableReference"
Previous Comments:
[2006-02-16 13:09:49] [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.
[2006-02-16 13:03:46] fidanza at uniroma3 dot it
Description:
A simple xslt stylesheet used on a production website with php 5.0.4
doesn't work more since we installed php 5.1.2.ù
Reproduce code:
---
PHP code:
public function loadXslFile(filewrapper $xslFile) {
$this->xslDom->load( $xslFile->getFileName() );
$this->xslProcessor->importStylesheet( $this->xslDom );
}
XSLT file:
http://www.w3.org/1999/XSL/Transform";>
::
Expected result:
The XSLT is expected to return the title attribute of a node element
which id matches 'current' param value.
Actual result:
--
We obtain the message:
XSLTProcessor::importStylesheet() [function.importStylesheet]:
Undefined variable
Trying to extend the scope of xsl:param to enclose the whole template
will result in:
XSLTProcessor::importStylesheet() [function.importStylesheet]:
compilation error: file
D:/InetPub/wwwroot/www.uniroma3.it/xml/pagetitle.xsl line 6 element
template
--
Edit this bug report at http://bugs.php.net/?id=36416&edit=1
#36407 [Fbk->Bgs]: Encoding in xsl:output has no effect
ID: 36407
Updated by: [EMAIL PROTECTED]
Reported By: memoimyself at yahoo dot com dot br
-Status: Feedback
+Status: Bogus
Bug Type: XSLT related
Operating System: Windows XP
PHP Version: 5.1.2
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
duped #36415
Previous Comments:
[2006-02-16 11:15:39] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
Need xml doc and stylesheet you are using
[2006-02-16 02:10:23] memoimyself at yahoo dot com dot br
Description:
I have an XSL file to transform XML documents; the XSL and all XML
files are encoded in UTF-8. My PHP script is in a file also encoded in
UTF-8. The data is retrieved from a database (MySQL 5) whose character
set is UTF-8 and whose tables all have UTF-8 as their character set as
well. All the strings in all the tables are duly encoded in UTF-8.
Prior to data retrieval, the query 'SET NAMES "utf8"' is run to ensure
that all i/o operations use the same character set (UTF-8). (Hope I've
been thorough enough!)
Now, my XSL file has the following top-level (child node of the
document element, as it should be) element:
The transformation is performed by the transformToXML method of the
XSLTProcessor class.
When the code is run on a Windows server (Win XP, Apache 2.0.55,PHP
5.1.2), the result of the transformation is NEVER UTF-8 (always
iso-8859-1), even if I chage 'method' to 'xml', and even if I use a
'media-type' attribute.
When run on a Linux server (PHP 5.1.2 as well), everything goes well.
Reproduce code:
---
$xml = new DOMDocument('1.0', 'UTF-8');
$xml->loadXML($row->Report);
$xsl = new DOMDocument('1.0', 'UTF-8');
$xsl->load($xsl_file);
$proc = new XSLTProcessor;
$proc->importStyleSheet($xsl);
$report = $proc->transformToXML($xml);
Expected result:
Output string should be encoded in UTF-8.
Actual result:
--
Output string in NOT encoded in UTF-8 and accented characters appear
garbled. This problem only occurs under Windows.
--
Edit this bug report at http://bugs.php.net/?id=36407&edit=1
#36415 [Opn->Fbk]: transformToXML will NOT output UTF-8
ID: 36415
Updated by: [EMAIL PROTECTED]
Reported By: memoimyself at yahoo dot com dot br
-Status: Open
+Status: Feedback
Bug Type: XSLT related
Operating System: Windows XP
PHP Version: 5.1.2
New Comment:
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.
This is not a reproducable script
We need something, we can copy&paste and run.
And please do not open 2 reports for the same problem
Previous Comments:
[2006-02-16 12:59:42] memoimyself at yahoo dot com dot br
Description:
An instance of the XSLTProcessor class, via its transformToXML method,
is used to transform XML documents using an XSL stylesheet.
The XSL document is in a file that is encoded in UTF-8.
The PHP script is in a file also encoded in UTF-8.
The XML documents are created at run time from XML strings stored in a
MySQL 5 database whose character set is
UTF-8 and whose tables all have UTF-8 as their character set as well.
All the XML strings stored in the database are duly encoded in UTF-8.
Prior to data retrieval, a 'SET NAMES "utf8"' query is run to ensure
that all i/o operations use the UTF-8 character set.
Upon transformation, the results are output to the client preceded by
"header('Content-Type: text/html; charset=UTF-8')" to ensure that the
browser uses the correct character set.
The XSL file has the following top-level (child node of the document
element, as it should be) element:
When this code is run on a Windows server (Win XP, Apache 2.0.55,PHP
5.1.2), the transformation NEVER outputs UTF-8 text (seems to output
iso-8859-1), even if the 'method' attribute in the above element is
changed to 'xml', and even if a 'media-type' attribute is also used.
When run on a Linux server (also running PHP 5.1.2), the transformation
runs as expected and outputs proper UTF-8 text to the browser.
Reproduce code:
---
PHP code:
$dbo = new PDO(BD_DSN, BD_USERNAME, BD_PWD);
$dbo->query('SET NAMES "utf8"');
$sql = 'SELECT Report FROM reports WHERE Id =
'.$dbo->quote(strip_gpc_slashes($_GET['rid'])).'
AND Author = '.$dbo->quote($_SESSION['user']);
$result = $dbo->query($sql);
$row = $result->fetch(PDO::FETCH_OBJ);
$xml = new DOMDocument('1.0', 'UTF-8');
$xml->loadXML($row->Report);
$xsl = new DOMDocument('1.0', 'UTF-8');
$xsl->load('/path/to/xsl/file.xsl');
$proc = new XSLTProcessor;
$proc->importStyleSheet($xsl);
$output = $proc->transformToXML($xml);
header('Content-Type: text/html; charset=utf-8');
print $output;
Start of XSL document:
http://www.w3.org/1999/XSL/Transform";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://www.w3.org/2005/11/schema-for-xslt20.xsd";>
...
Expected result:
All text output to the browser should be proper UTF-8. If the browser's
character encoding is set to UTF-8 (which it should, with the
"content-type" header above), all accented character should be
adequately displayed.
Actual result:
--
When the code is run on a Windows XP server, the text output to the
browser is NOT proper UTF-8 and all accented characters are replaced by
weird symbols.
When the code is run on a Linux server (also equipped with PHP 5.1.2),
everything works as expected and the output is proper UTF-8.
--
Edit this bug report at http://bugs.php.net/?id=36415&edit=1
#36417 [NEW]: /usr/php5/libtool[3194]: syntax error at line 1 : `|' unexpected
From: rupeshkt at gmail dot com Operating system: AIX PHP version: 5.1.2 PHP Bug Type: Compile Failure Bug description: /usr/php5/libtool[3194]: syntax error at line 1 : `|' unexpected Description: Compiling PHP 5.0.4 with oci8 fails with the error "/usr/php-5.0.4/libtool[3194]: syntax error at line 1 : `|' unexpected". I am using the below "configure" command before compiling with "make". CFLAGS="-I/usr/ociheaders -q64" ./configure --with-oci8=/oraHome --with-apxs2=/usr/local/apache2/bin/apxs --disable-libxml --enable-sigchild Expected result: Should compile properly. Actual result: -- # make/bin/sh /usr/php-5.0.4/libtool --silent --preserve-dup-deps --mode=link cc -I/usr/ociheaders -q64 -rpath /usr/php-5.0.4/libs -Wl,-brtl -Wl,-bI:/usr/local/apache2/modules/httpd.exp -avoid-version -module -L/oraHome/lib -R /oraHome/lib ext/ctype/ctype.lo ext/iconv/iconv.lo ext/oci8/oci8.lo ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo ext/posix/posix.lo ext/session/session.lo ext/session/mod_files.lo ext/session/mod_mm.lo ext/session/mod_user.lo ext/spl/php_spl.lo ext/spl/spl_functions.lo ext/spl/spl_engine.lo ext/spl/spl_iterators.lo ext/spl/spl_array.lo ext/spl/spl_directory.lo ext/spl/spl_sxe.lo ext/sqlite/sqlite.lo ext/sqlite/sess_sqlite.lo ext/sqlite/libsqlite/src/opcodes.lo ext/sqlite/libsqlite/src/parse.lo ext/sqlite/libsqlite/src/encode.lo ext/sqlite/libsqlite/src/auth.lo ext/sqlite/libsqlite/src/btree.lo ext/sqlite/libsqlite/src/build.lo ext/sqlite/libsqlite/src/delete.lo ext/sqlite/libsqlite/src/expr.lo ext/sqlite/libsqlite/src/func.lo ext/sqlite/libsqlite/src/hash.lo ext/sqlite/libsqlite/src/insert.lo ext/sqlite/libsqlite/src/main.lo ext/sqlite/libsqlite/src/os.lo ext/sqlite/libsqlite/src/pager.lo ext/sqlite/libsqlite/src/printf.lo ext/sqlite/libsqlite/src/random.lo ext/sqlite/libsqlite/src/select.lo ext/sqlite/libsqlite/src/table.lo ext/sqlite/libsqlite/src/tokenize.lo ext/sqlite/libsqlite/src/update.lo ext/sqlite/libsqlite/src/util.lo ext/sqlite/libsqlite/src/vdbe.lo ext/sqlite/libsqlite/src/attach.lo ext/sqlite/libsqlite/src/btree_rb.lo ext/sqlite/libsqlite/src/pragma.lo ext/sqlite/libsqlite/src/vacuum.lo ext/sqlite/libsqlite/src/copy.lo ext/sqlite/libsqlite/src/vdbeaux.lo ext/sqlite/libsqlite/src/date.lo ext/sqlite/libsqlite/src/where.lo ext/sqlite/libsqlite/src/trigger.lo regex/regcomp.lo regex/regexec.lo regex/regerror.lo regex/regfree.lo ext/standard/array.lo ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo ext/standard/formatted_print.lo ext/standard/fsock.lo ext/standard/head.lo ext/standard/html.lo ext/standard/image.lo ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo ext/standard/link.lo ext/standard/mail.lo ext/standard/math.lo ext/standard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo ext/standard/pack.lo ext/standard/pageinfo.lo ext/standard/parsedate.lo ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/reg.lo ext/standard/soundex.lo ext/standard/string.lo ext/standard/scanf.lo ext/standard/syslog.lo ext/standard/type.lo ext/standard/uniqid.lo ext/standard/url.lo ext/standard/url_scanner.lo ext/standard/var.lo ext/standard/versioning.lo ext/standard/assert.lo ext/standard/strnatcmp.lo ext/standard/levenshtein.lo ext/standard/incomplete_class.lo ext/standard/url_scanner_ex.lo ext/standard/ftp_fopen_wrapper.lo ext/standard/http_fopen_wrapper.lo ext/standard/php_fopen_wrapper.lo ext/standard/credits.lo ext/standard/css.lo ext/standard/var_unserializer.lo ext/standard/ftok.lo ext/standard/sha1.lo ext/standard/user_filters.lo ext/standard/uuencode.lo ext/standard/filters.lo ext/standard/proc_open.lo ext/standard/sunfuncs.lo ext/standard/streamsfuncs.lo ext/standard/http.lo ext/tokenizer/tokenizer.lo TSRM/TSRM.lo TSRM/tsrm_strtok_r.lo TSRM/tsrm_virtual_cwd.lo main/main.lo main/snprintf.lo main/spprintf.lo main/php_sprintf.lo main/safe_mode.lo main/fopen_wrappers.lo main/alloca.lo main/php_scandir.lo main/php_ini.lo main/SAPI.lo main/rfc1867.lo main/php_content_types.lo main/strlcpy.lo main/strlcat.lo main/mergesort.lo main/reentrancy.lo main/php_variables.lo main/php_ticks.lo main/network.lo main/php_open_temporary_file.lo main/php_logos.lo main/output.lo main/streams/streams.lo main/streams/cast.lo main/streams/memory.lo main/streams/filter.lo main/streams/plain_wrapper.lo main/streams/userspace.lo main/streams/transports.lo main/streams/xp_socket.lo main/streams/mmap.lo Zend/zend_language_parser.lo Zend/zend_language_scanner.lo Zend/zend_ini_parser.lo Zend/zend_ini_scanner.lo Zend/zend_alloc.lo Zend/zend_compile.lo Zend/zend_
#36417 [Opn->Fbk]: /usr/php5/libtool[3194]: syntax error at line 1 : `|' unexpected
ID: 36417 Updated by: [EMAIL PROTECTED] Reported By: rupeshkt at gmail dot com -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: AIX PHP Version: 5.1.2 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Previous Comments: [2006-02-16 13:32:10] rupeshkt at gmail dot com Description: Compiling PHP 5.0.4 with oci8 fails with the error "/usr/php-5.0.4/libtool[3194]: syntax error at line 1 : `|' unexpected". I am using the below "configure" command before compiling with "make". CFLAGS="-I/usr/ociheaders -q64" ./configure --with-oci8=/oraHome --with-apxs2=/usr/local/apache2/bin/apxs --disable-libxml --enable-sigchild Expected result: Should compile properly. Actual result: -- # make/bin/sh /usr/php-5.0.4/libtool --silent --preserve-dup-deps --mode=link cc -I/usr/ociheaders -q64 -rpath /usr/php-5.0.4/libs -Wl,-brtl -Wl,-bI:/usr/local/apache2/modules/httpd.exp -avoid-version -module -L/oraHome/lib -R /oraHome/lib ext/ctype/ctype.lo ext/iconv/iconv.lo ext/oci8/oci8.lo ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo ext/posix/posix.lo ext/session/session.lo ext/session/mod_files.lo ext/session/mod_mm.lo ext/session/mod_user.lo ext/spl/php_spl.lo ext/spl/spl_functions.lo ext/spl/spl_engine.lo ext/spl/spl_iterators.lo ext/spl/spl_array.lo ext/spl/spl_directory.lo ext/spl/spl_sxe.lo ext/sqlite/sqlite.lo ext/sqlite/sess_sqlite.lo ext/sqlite/libsqlite/src/opcodes.lo ext/sqlite/libsqlite/src/parse.lo ext/sqlite/libsqlite/src/encode.lo ext/sqlite/libsqlite/src/auth.lo ext/sqlite/libsqlite/src/btree.lo ext/sqlite/libsqlite/src/build.lo ext/sqlite/libsqlite/src/delete.lo ext/sqlite/libsqlite/src/expr.lo ext/sqlite/libsqlite/src/func.lo ext/sqlite/libsqlite/src/hash.lo ext/sqlite/libsqlite/src/insert.lo ext/sqlite/libsqlite/src/main.lo ext/sqlite/libsqlite/src/os.lo ext/sqlite/libsqlite/src/pager.lo ext/sqlite/libsqlite/src/printf.lo ext/sqlite/libsqlite/src/random.lo ext/sqlite/libsqlite/src/select.lo ext/sqlite/libsqlite/src/table.lo ext/sqlite/libsqlite/src/tokenize.lo ext/sqlite/libsqlite/src/update.lo ext/sqlite/libsqlite/src/util.lo ext/sqlite/libsqlite/src/vdbe.lo ext/sqlite/libsqlite/src/attach.lo ext/sqlite/libsqlite/src/btree_rb.lo ext/sqlite/libsqlite/src/pragma.lo ext/sqlite/libsqlite/src/vacuum.lo ext/sqlite/libsqlite/src/copy.lo ext/sqlite/libsqlite/src/vdbeaux.lo ext/sqlite/libsqlite/src/date.lo ext/sqlite/libsqlite/src/where.lo ext/sqlite/libsqlite/src/trigger.lo regex/regcomp.lo regex/regexec.lo regex/regerror.lo regex/regfree.lo ext/standard/array.lo ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo ext/standard/formatted_print.lo ext/standard/fsock.lo ext/standard/head.lo ext/standard/html.lo ext/standard/image.lo ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo ext/standard/link.lo ext/standard/mail.lo ext/standard/math.lo ext/standard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo ext/standard/pack.lo ext/standard/pageinfo.lo ext/standard/parsedate.lo ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/reg.lo ext/standard/soundex.lo ext/standard/string.lo ext/standard/scanf.lo ext/standard/syslog.lo ext/standard/type.lo ext/standard/uniqid.lo ext/standard/url.lo ext/standard/url_scanner.lo ext/standard/var.lo ext/standard/versioning.lo ext/standard/assert.lo ext/standard/strnatcmp.lo ext/standard/levenshtein.lo ext/standard/incomplete_class.lo ext/standard/url_scanner_ex.lo ext/standard/ftp_fopen_wrapper.lo ext/standard/http_fopen_wrapper.lo ext/standard/php_fopen_wrapper.lo ext/standard/credits.lo ext/standard/css.lo ext/standard/var_unserializer.lo ext/standard/ftok.lo ext/standard/sha1.lo ext/standard/user_filters.lo ext/standard/uuencode.lo ext/standard/filters.lo ext/standard/proc_open.lo ext/standard/sunfuncs.lo ext/standard/streamsfuncs.lo ext/standard/http.lo ext/tokenizer/tokenizer.lo TSRM/TSRM.lo TSRM/tsrm_strtok_r.lo TSRM/tsrm_virtual_cwd.lo main/main.lo main/snprintf.lo main/spprintf.lo main/php_sprintf.lo main/safe_mode.lo main/fopen_wrappers.lo main/alloca.lo main/php_scandir.lo main/php_ini.lo main/SAPI.lo main/rfc1867.lo main/php_content_types.lo main/strlcpy.lo main/strlcat.lo main/mergesort.lo main/reentrancy.lo main/php_variables.lo main/php_ticks.lo main/network.lo main/php_open_temporary_file.lo main/php_logos.lo main/output.lo main/streams/streams.lo main/strea
#36407 [Bgs]: Encoding in xsl:output has no effect
ID: 36407
User updated by: memoimyself at yahoo dot com dot br
Reported By: memoimyself at yahoo dot com dot br
Status: Bogus
Bug Type: XSLT related
Operating System: Windows XP
PHP Version: 5.1.2
New Comment:
This is NOT a bogus report. I explained in as much detail as possible
what happens and yet I was reprimanded with "not enough information was
provided for us to be able
to handle this bug". What other information is there to provide?
This is a script that runs on a test server that cannot be acessed over
the internet, so I cannot provide you with a link to the script.
According to your rules, I cannot submit more than 20 lines of code
either, so I cannot reproduce a typical XML document or the whole XSL
file, or even the complete PHP script, so I tried sending the bits that
really matter (in my humble opinion).
If you want to reproduce the problem, try this:
(a) Transform ANY XML document encoded in UTF-8 with any XSLT
stylesheet also encoded in UTF-8 with the tag ;
(b) Output the result of the transformation, preceded by a content-type
header specifying UTF-8 as the encoding, to a browser.
I'll bet you anything you want that the output will NOT be UTF-8 as it
should.
If you prefer to disregard this report, suit yourself. I'm just trying
to help. I guess we'll all be worse off if the bug is not fixed. But
what can I do?
Previous Comments:
[2006-02-16 13:16:40] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
duped #36415
[2006-02-16 11:15:39] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
Need xml doc and stylesheet you are using
[2006-02-16 02:10:23] memoimyself at yahoo dot com dot br
Description:
I have an XSL file to transform XML documents; the XSL and all XML
files are encoded in UTF-8. My PHP script is in a file also encoded in
UTF-8. The data is retrieved from a database (MySQL 5) whose character
set is UTF-8 and whose tables all have UTF-8 as their character set as
well. All the strings in all the tables are duly encoded in UTF-8.
Prior to data retrieval, the query 'SET NAMES "utf8"' is run to ensure
that all i/o operations use the same character set (UTF-8). (Hope I've
been thorough enough!)
Now, my XSL file has the following top-level (child node of the
document element, as it should be) element:
The transformation is performed by the transformToXML method of the
XSLTProcessor class.
When the code is run on a Windows server (Win XP, Apache 2.0.55,PHP
5.1.2), the result of the transformation is NEVER UTF-8 (always
iso-8859-1), even if I chage 'method' to 'xml', and even if I use a
'media-type' attribute.
When run on a Linux server (PHP 5.1.2 as well), everything goes well.
Reproduce code:
---
$xml = new DOMDocument('1.0', 'UTF-8');
$xml->loadXML($row->Report);
$xsl = new DOMDocument('1.0', 'UTF-8');
$xsl->load($xsl_file);
$proc = new XSLTProcessor;
$proc->importStyleSheet($xsl);
$report = $proc->transformToXML($xml);
Expected result:
Output string should be encoded in UTF-8.
Actual result:
--
Output string in NOT encoded in UTF-8 and accented characters appear
garbled. This problem only occurs under Windows.
--
Edit this bug report at http://bugs.php.net/?id=36407&edit=1
#36407 [Bgs]: Encoding in xsl:output has no effect
ID: 36407
User updated by: memoimyself at yahoo dot com dot br
Reported By: memoimyself at yahoo dot com dot br
Status: Bogus
Bug Type: XSLT related
Operating System: Windows XP
PHP Version: 5.1.2
New Comment:
Important detail I failed to include in my previous comment: the string
for the XML document has to be retrieved from a MySQL database,
preferably version 5, where all character sets (database and tables)
are UTF-8.
I considered the possibility that the bug was with PDO, not
XSLTProcessor, but when the same XML strings are retrieved from the
same table with PDO (which is what is done prior to XSLT transformation
in my report) and the output to the browser, the output IS proper
UTF-8.
A theory is that, somehow, when the string retrieved from the database
is imported into the XML file that will later be processed by
XSLTProcessor, it gets re-encoded in such a way that the output of the
transformation will not be proper UTF-8. That to me is still either an
XSLTProcessor or a DOMDocument problem.
Previous Comments:
[2006-02-16 14:00:06] memoimyself at yahoo dot com dot br
This is NOT a bogus report. I explained in as much detail as possible
what happens and yet I was reprimanded with "not enough information was
provided for us to be able
to handle this bug". What other information is there to provide?
This is a script that runs on a test server that cannot be acessed over
the internet, so I cannot provide you with a link to the script.
According to your rules, I cannot submit more than 20 lines of code
either, so I cannot reproduce a typical XML document or the whole XSL
file, or even the complete PHP script, so I tried sending the bits that
really matter (in my humble opinion).
If you want to reproduce the problem, try this:
(a) Transform ANY XML document encoded in UTF-8 with any XSLT
stylesheet also encoded in UTF-8 with the tag ;
(b) Output the result of the transformation, preceded by a content-type
header specifying UTF-8 as the encoding, to a browser.
I'll bet you anything you want that the output will NOT be UTF-8 as it
should.
If you prefer to disregard this report, suit yourself. I'm just trying
to help. I guess we'll all be worse off if the bug is not fixed. But
what can I do?
[2006-02-16 13:16:40] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
duped #36415
[2006-02-16 11:15:39] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
Need xml doc and stylesheet you are using
[2006-02-16 02:10:23] memoimyself at yahoo dot com dot br
Description:
I have an XSL file to transform XML documents; the XSL and all XML
files are encoded in UTF-8. My PHP script is in a file also encoded in
UTF-8. The data is retrieved from a database (MySQL 5) whose character
set is UTF-8 and whose tables all have UTF-8 as their character set as
well. All the strings in all the tables are duly encoded in UTF-8.
Prior to data retrieval, the query 'SET NAMES "utf8"' is run to ensure
that all i/o operations use the same character set (UTF-8). (Hope I've
been thorough enough!)
Now, my XSL file has the following top-level (child node of the
document element, as it should be) element:
The transformation is performed by the transformToXML method of the
XSLTProcessor class.
When the code is run on a Windows server (Win XP, Apache 2.0.55,PHP
5.1.2), the result of the transformation is NEVER UTF-8 (always
iso-8859-1), even if I chage 'method' to 'xml', and even if I use a
'media-type' attribute.
When run on a Linux server (PHP 5.1.2 as well), everything goes well.
Reproduce code:
---
$xml = new DOMDocument('1.0', 'UTF-8');
$xml->loadXML($row->Report);
$xsl = new DOMDocument('1.0', 'UTF-8');
$xsl->load($xsl_file);
$proc = new XSLTProcessor;
$proc->importStyleSheet($xsl);
$report = $proc->transformToXML($xml);
Expected result:
Output string should be encoded in UTF-8.
Actual result:
--
Output string in NOT encoded in UTF-8 and accented characters appear
garbled. This problem only occurs under Windows.
--
Edit this bug report at http://bugs.php.net/?id=36407&edit=1
#29974 [Com]: num_rows crashes Apache (recurrence)
ID: 29974
Comment by: grikdotnet at aim dot com
Reported By: david dot powers at dial dot pipex dot com
Status: No Feedback
Bug Type: MySQLi related
Operating System: Windows XP
PHP Version: 5.0.1
New Comment:
I have a crash (segfault) when accessing the num_rows field after
$result->close() is called.
Previous Comments:
[2004-09-23 01:00:06] 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".
[2004-09-20 01:31:27] splash2 at splashtech dot net
I also had this issue on php 5.0.1 final release... I downloaded the
latest (at this time) snapshot located at
http://snaps.php.net/win32/php5.0-win32-200409191630.zip.
The issue is resolved in that version. :)
[2004-09-15 09:30:27] [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-09-03 19:40:11] david dot powers at dial dot pipex dot com
Description:
Bug #28205 reported fixed in PHP 5.RC-3 appears to have resurfaced.
Use of $result->num_rows causes Apache to crash. Use of
mysqli_num_rows() works without problem.
Environment:
Windows XP Pro
Apache 1.3.31
PHP 5.0.1
MySQL 4.1.4-gamma
extension=php_mbstring.dll
extension=php_mysqli.dll
extension=php_mysql.dll
Reproduce code:
---
$db = new mysqli($hostname, $username, $password, 'db_name');
$sql = 'SELECT * FROM wordlist';
$result = $db->query($sql);
$total = $result->num_rows;
echo "Total words: $total";
while ($row = $result->fetch_assoc()) {
echo $row['word'].'';
}
Expected result:
I expect it not to crash.
Actual result:
--
Error report:
szAppName: Apache.exe szAppVer: 0.0.0.0
szModName: php_mysql.dll szModVer: 5.0.1.1
offset: 11fe
Code works perfectly if $total = $result->num_rows; is commented out.
--
Edit this bug report at http://bugs.php.net/?id=29974&edit=1
#36418 [NEW]: Graphics errors on multiple processes
From: jraben at alstermedia dot de
Operating system: Win XP
PHP version: 5.1.2
PHP Bug Type: *Graphics related
Bug description: Graphics errors on multiple processes
Description:
It's a script that joins a background .gif picture with transparent png
24-bit pictures to a thumb jpg. It actually no the complete script. $bfile
is always the same. $file and $target may vary.
Some files have corrupted backgrounds, if the script is started in
multiple instances at the same time. Seems to be a memory allocation bug.
Reproduce code:
---
$img = @imagecreatefromgif("$bfile");
$imgobj = @imagecreatefrompng("$file");
imagealphablending ( $imgobj, true );
$width = imagesx($imgobj);
$height = imagesy($imgobj);
$imgnew = imagecreatetruecolor($width, $height);
imagecopyresampled($imgnew,$img,0,0,$x,$y,$width,$height,$width,$height);
imagecopyresampled($imgnew,$imgobj,0,0,0,0,$width,$height,$width,$height);
imagejpeg($imgnew, $target, 90);
Expected result:
Not currupted pictures as .jpg with $bfile gif as background and $file
.png as foreground.
Actual result:
--
Some files have corrupted backgrounds, if this script is started in
multiple instances at the same time. Seems to be a memory allocation bug
or something with loading the same picture multiple times at the same
time.
--
Edit bug report at http://bugs.php.net/?id=36418&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36418&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36418&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36418&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36418&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36418&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36418&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36418&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36418&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36418&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36418&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36418&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36418&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36418&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36418&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36418&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36418&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36418&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36418&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36418&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36418&r=mysqlcfg
#36419 [NEW]: rpmbuild -bb php.spec fails
From: michael at stellarent dot com Operating system: Fedora Core 2 PHP version: 5.1.2 PHP Bug Type: *Compile Issues Bug description: rpmbuild -bb php.spec fails Description: Downloaded the latest fedora core source rpm (php-5.1.2-4.3.src.rpm), installed using rpm -ivh, and invoked rpmbuild -bb. Build fails with message: checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. error: Bad exit status from /var/tmp/rpm-tmp.21471 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.21471 (%build) I have tried earlier versions, but same problem. The only version which builds, is 5.0.4-3. Curiously, compiling php from tar.gz distrubution works fine. Expected result: php to build all rpms in /usr/src/redhat/RPMS/i386 Actual result: -- [EMAIL PROTECTED] php-5.1.2]# rpmbuild -bb /usr/src/redhat/SPECS/php-5.1.2-4.3.spec Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.68654 + umask 022 + cd /usr/src/redhat/BUILD + LANG=C + export LANG + unset DISPLAY + cd /usr/src/redhat/BUILD + rm -rf php-5.1.2 + /usr/bin/gzip -dc /usr/src/redhat/SOURCES/php-5.1.2.tar.gz + tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd php-5.1.2 ++ /usr/bin/id -u + '[' 0 = 0 ']' + /bin/chown -Rhf root . ++ /usr/bin/id -u + '[' 0 = 0 ']' + /bin/chgrp -Rhf root . + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + echo 'Patch #5 (php-4.3.3-install.patch):' Patch #5 (php-4.3.3-install.patch): + patch -p1 -b --suffix .install -s + echo 'Patch #6 (php-5.0.4-norpath.patch):' Patch #6 (php-5.0.4-norpath.patch): + patch -p1 -b --suffix .norpath -s + echo 'Patch #7 (php-4.3.2-libtool15.patch):' Patch #7 (php-4.3.2-libtool15.patch): + patch -p1 -b --suffix .libtool15 -s + echo 'Patch #13 (php-5.0.2-phpize64.patch):' Patch #13 (php-5.0.2-phpize64.patch): + patch -p1 -b --suffix .phpize64 -s + echo 'Patch #21 (php-4.3.1-odbc.patch):' Patch #21 (php-4.3.1-odbc.patch): + patch -p1 -b --suffix .odbc -s + echo 'Patch #22 (php-4.3.11-shutdown.patch):' Patch #22 (php-4.3.11-shutdown.patch): + patch -p1 -b --suffix .shutdown -s + echo 'Patch #30 (php-5.0.4-dlopen.patch):' Patch #30 (php-5.0.4-dlopen.patch): + patch -p1 -b --suffix .dlopen -s + echo 'Patch #31 (php-5.0.0-easter.patch):' Patch #31 (php-5.0.0-easter.patch): + patch -p1 -b --suffix .easter -s + echo 'Patch #50 (php-5.0.4-tests-dashn.patch):' Patch #50 (php-5.0.4-tests-dashn.patch): + patch -p1 -b --suffix .tests-dashn -s + echo 'Patch #51 (php-5.0.4-tests-wddx.patch):' Patch #51 (php-5.0.4-tests-wddx.patch): + patch -p1 -b --suffix .tests-wddx -s + cp Zend/LICENSE Zend/ZEND_LICENSE + cp TSRM/LICENSE TSRM_LICENSE + cp regex/COPYRIGHT regex_COPYRIGHT + cp ext/gd/libgd/README gd_README + mkdir build-cgi build-apache + rm -f ext/standard/tests/file/bug21131.phpt + rm -f ext/standard/tests/file/bug22414.phpt ext/iconv/tests/bug16069.phpt + exit 0 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.21471 + umask 022 + cd /usr/src/redhat/BUILD + cd php-5.1.2 + LANG=C + export LANG + unset DISPLAY + libtoolize --force --copy ++ aclocal --print-ac-dir + cat /usr/share/aclocal/libtool.m4 + ./buildconf --force Forcing buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.59 (ok) buildconf: Your version of autoconf likely contains buggy cache code. Running cvsclean for you. To avoid this, install autoconf-2.13. rebuilding aclocal.m4 rebuilding configure aclocal.m4:2054: PHP_PROG_LEX is expanded from... rebuilding main/php_config.h.in autoheader: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' autoheader: WARNING: and `config.h.top', to define templates for `config.h.in' autoheader: WARNING: is deprecated and discouraged. autoheader: autoheader: WARNING: Using the third argument of `AC_DEFINE' and autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without autoheader: WARNING: `acconfig.h': autoheader: autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1, autoheader: [Define if a function `main' is needed.]) autoheader: autoheader: WARNING: More sophisticated templates can also be produced, see the autoheader: WARNING: documentation. aclocal.m4:2054: PHP_PROG_LEX is expanded from... + CFLAGS=-O2 -g -pipe -march=i386 -mcpu=i686 -fno-strict-aliasing -Wno-pointer-sign + export CFLAGS + EXTENSION_DIR=/usr/lib/php/modules + export EXTENSION_DIR + PEAR_INSTALLDIR=/usr/share/pear + export PEAR_INSTALLDIR + pushd build-cgi /usr/src/redhat/BUILD/php-5.1.2/build-cgi /usr/src/redhat/BUILD/php-5.1.2 + build --enable-force-cgi-redirect --enable-pcntl --with-imap=shared --with-imap-ssl --enable-mbstring=shared --enable-mbstr-enc-trans --enable-mbregex --with-ncurses=shared --with-gd=shared --enable-bcmath=shared --enable-dba=shared --with-db4=/usr --with-xmlrpc=shared --with-ldap=shared --with-mysql=shared,/usr --with-mysqli=shared,/usr/bin/mysql_config --enable-d
#36419 [Opn->Bgs]: rpmbuild -bb php.spec fails
ID: 36419 Updated by: [EMAIL PROTECTED] Reported By: michael at stellarent dot com -Status: Open +Status: Bogus Bug Type: *Compile Issues Operating System: Fedora Core 2 PHP Version: 5.1.2 New Comment: We do not support any third-party packages. And yes, your gcc is b0rked, see config.log for details. Previous Comments: [2006-02-16 15:55:13] michael at stellarent dot com Description: Downloaded the latest fedora core source rpm (php-5.1.2-4.3.src.rpm), installed using rpm -ivh, and invoked rpmbuild -bb. Build fails with message: checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. error: Bad exit status from /var/tmp/rpm-tmp.21471 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.21471 (%build) I have tried earlier versions, but same problem. The only version which builds, is 5.0.4-3. Curiously, compiling php from tar.gz distrubution works fine. Expected result: php to build all rpms in /usr/src/redhat/RPMS/i386 Actual result: -- [EMAIL PROTECTED] php-5.1.2]# rpmbuild -bb /usr/src/redhat/SPECS/php-5.1.2-4.3.spec Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.68654 + umask 022 + cd /usr/src/redhat/BUILD + LANG=C + export LANG + unset DISPLAY + cd /usr/src/redhat/BUILD + rm -rf php-5.1.2 + /usr/bin/gzip -dc /usr/src/redhat/SOURCES/php-5.1.2.tar.gz + tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd php-5.1.2 ++ /usr/bin/id -u + '[' 0 = 0 ']' + /bin/chown -Rhf root . ++ /usr/bin/id -u + '[' 0 = 0 ']' + /bin/chgrp -Rhf root . + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + echo 'Patch #5 (php-4.3.3-install.patch):' Patch #5 (php-4.3.3-install.patch): + patch -p1 -b --suffix .install -s + echo 'Patch #6 (php-5.0.4-norpath.patch):' Patch #6 (php-5.0.4-norpath.patch): + patch -p1 -b --suffix .norpath -s + echo 'Patch #7 (php-4.3.2-libtool15.patch):' Patch #7 (php-4.3.2-libtool15.patch): + patch -p1 -b --suffix .libtool15 -s + echo 'Patch #13 (php-5.0.2-phpize64.patch):' Patch #13 (php-5.0.2-phpize64.patch): + patch -p1 -b --suffix .phpize64 -s + echo 'Patch #21 (php-4.3.1-odbc.patch):' Patch #21 (php-4.3.1-odbc.patch): + patch -p1 -b --suffix .odbc -s + echo 'Patch #22 (php-4.3.11-shutdown.patch):' Patch #22 (php-4.3.11-shutdown.patch): + patch -p1 -b --suffix .shutdown -s + echo 'Patch #30 (php-5.0.4-dlopen.patch):' Patch #30 (php-5.0.4-dlopen.patch): + patch -p1 -b --suffix .dlopen -s + echo 'Patch #31 (php-5.0.0-easter.patch):' Patch #31 (php-5.0.0-easter.patch): + patch -p1 -b --suffix .easter -s + echo 'Patch #50 (php-5.0.4-tests-dashn.patch):' Patch #50 (php-5.0.4-tests-dashn.patch): + patch -p1 -b --suffix .tests-dashn -s + echo 'Patch #51 (php-5.0.4-tests-wddx.patch):' Patch #51 (php-5.0.4-tests-wddx.patch): + patch -p1 -b --suffix .tests-wddx -s + cp Zend/LICENSE Zend/ZEND_LICENSE + cp TSRM/LICENSE TSRM_LICENSE + cp regex/COPYRIGHT regex_COPYRIGHT + cp ext/gd/libgd/README gd_README + mkdir build-cgi build-apache + rm -f ext/standard/tests/file/bug21131.phpt + rm -f ext/standard/tests/file/bug22414.phpt ext/iconv/tests/bug16069.phpt + exit 0 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.21471 + umask 022 + cd /usr/src/redhat/BUILD + cd php-5.1.2 + LANG=C + export LANG + unset DISPLAY + libtoolize --force --copy ++ aclocal --print-ac-dir + cat /usr/share/aclocal/libtool.m4 + ./buildconf --force Forcing buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.59 (ok) buildconf: Your version of autoconf likely contains buggy cache code. Running cvsclean for you. To avoid this, install autoconf-2.13. rebuilding aclocal.m4 rebuilding configure aclocal.m4:2054: PHP_PROG_LEX is expanded from... rebuilding main/php_config.h.in autoheader: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' autoheader: WARNING: and `config.h.top', to define templates for `config.h.in' autoheader: WARNING: is deprecated and discouraged. autoheader: autoheader: WARNING: Using the third argument of `AC_DEFINE' and autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without autoheader: WARNING: `acconfig.h': autoheader: autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1, autoheader: [Define if a function `main' is needed.]) autoheader: autoheader: WARNING: More sophisticated templates can also be produced, see the autoheader: WARNING: documentation. aclocal.m4:2054: PHP_PROG_LEX is expanded from... + CFLAGS=-O2 -g -pipe -march=i386 -mcpu=i686 -fno-strict-aliasing -Wno-pointer-sign + export CFLAGS + EXTENSION_DIR=/usr/lib/php/modules + export EXTENSION_DIR + PEAR_INSTALLDIR=/usr/share/pear + export PEAR_INSTALLDIR + pushd build-cgi /usr/src/redhat/BUILD/php-5.1.2/build-cgi /usr/src/redhat/BUILD/php-5.1.2 + build --enable-force-cgi-redirect -
#36418 [Opn->Fbk]: Graphics errors on multiple processes
ID: 36418
Updated by: [EMAIL PROTECTED]
Reported By: jraben at alstermedia dot de
-Status: Open
+Status: Feedback
Bug Type: *Graphics related
Operating System: Win XP
PHP Version: 5.1.2
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
Previous Comments:
[2006-02-16 15:31:17] jraben at alstermedia dot de
Description:
It's a script that joins a background .gif picture with transparent png
24-bit pictures to a thumb jpg. It actually no the complete script.
$bfile is always the same. $file and $target may vary.
Some files have corrupted backgrounds, if the script is started in
multiple instances at the same time. Seems to be a memory allocation
bug.
Reproduce code:
---
$img = @imagecreatefromgif("$bfile");
$imgobj = @imagecreatefrompng("$file");
imagealphablending ( $imgobj, true );
$width = imagesx($imgobj);
$height = imagesy($imgobj);
$imgnew = imagecreatetruecolor($width, $height);
imagecopyresampled($imgnew,$img,0,0,$x,$y,$width,$height,$width,$height);
imagecopyresampled($imgnew,$imgobj,0,0,0,0,$width,$height,$width,$height);
imagejpeg($imgnew, $target, 90);
Expected result:
Not currupted pictures as .jpg with $bfile gif as background and $file
.png as foreground.
Actual result:
--
Some files have corrupted backgrounds, if this script is started in
multiple instances at the same time. Seems to be a memory allocation
bug or something with loading the same picture multiple times at the
same time.
--
Edit this bug report at http://bugs.php.net/?id=36418&edit=1
#36418 [Fbk]: Graphics errors on multiple processes
ID: 36418
Updated by: [EMAIL PROTECTED]
Reported By: jraben at alstermedia dot de
Status: Feedback
Bug Type: GD related
Operating System: Win XP
PHP Version: 5.1.2
New Comment:
Please provide a set of source images and a valid script to reproduce
the problems. That means a working script, valid filenames, source
images, etc.
Previous Comments:
[2006-02-16 16:10:18] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-02-16 15:31:17] jraben at alstermedia dot de
Description:
It's a script that joins a background .gif picture with transparent png
24-bit pictures to a thumb jpg. It actually no the complete script.
$bfile is always the same. $file and $target may vary.
Some files have corrupted backgrounds, if the script is started in
multiple instances at the same time. Seems to be a memory allocation
bug.
Reproduce code:
---
$img = @imagecreatefromgif("$bfile");
$imgobj = @imagecreatefrompng("$file");
imagealphablending ( $imgobj, true );
$width = imagesx($imgobj);
$height = imagesy($imgobj);
$imgnew = imagecreatetruecolor($width, $height);
imagecopyresampled($imgnew,$img,0,0,$x,$y,$width,$height,$width,$height);
imagecopyresampled($imgnew,$imgobj,0,0,0,0,$width,$height,$width,$height);
imagejpeg($imgnew, $target, 90);
Expected result:
Not currupted pictures as .jpg with $bfile gif as background and $file
.png as foreground.
Actual result:
--
Some files have corrupted backgrounds, if this script is started in
multiple instances at the same time. Seems to be a memory allocation
bug or something with loading the same picture multiple times at the
same time.
--
Edit this bug report at http://bugs.php.net/?id=36418&edit=1
#36347 [Opn->Bgs]: PDO::exec() fails if the query returns results
ID: 36347
Updated by: [EMAIL PROTECTED]
Reported By: david at acz dot org
-Status: Open
+Status: Bogus
Bug Type: PDO related
Operating System: SuSE Linux 9.3
PHP Version: 5.1.2
Assigned To: george
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
In new version of PDO mysql you can safely use exec() method. It
returns 0 because now rows were affected, but the operation is
successful (on failure FALSE is returned).
Previous Comments:
[2006-02-14 16:05:57] david at acz dot org
See my previous comment. There is no way to execute "OPTIMIZE TABLE"
with MySQL using PDO.
[2006-02-14 15:13:23] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
exec() method is intended only for one time execution of queries that
do not return any records. There is no bug here.
[2006-02-10 15:18:11] [EMAIL PROTECTED]
Assigned to the maintainer.
[2006-02-10 02:34:48] david at acz dot org
This bug is similar to #34499. I can't comment on that, so I'm
commenting here:
"OPTIMIZE TABLE is a query that returns rows.
You should use PDO::query() instead.
I'll see about handling this user error more gracefully."
You actually can't use PDO::query() with OPTIMIZE TABLE:
HY000:2030:This command is not supported in the prepared statement
protocol yet
What is the solution?
[2006-02-10 01:24:25] david at acz dot org
Description:
[Note: I am actually testing this on PHP 5.1.1. If this bug was fixed
in PHP 5.1.2, please add a note to the manual page for PDO::exec()].
The manual says:
"PDO::exec() does not return results from a SELECT statement. For a
SELECT statement that you only need to issue once during your program,
consider issuing PDO::query()."
Either the manual needs to be changed, or, ideally, PDO::exec() needs
to be fixed to discard results.
This issue has bit me multiple times. It's easy to forget that a
certain query (such as MySQL's OPTIMIZE TABLE) will return a result.
Using PDO::exec() in such cases causes an error later that can be
difficult to track down.
Reproduce code:
---
exec("SELECT 1");
$st = $db->prepare("SELECT NOW()");
if ($st === false)
{
$e = $db->errorInfo();
echo "$e[0]:$e[1]: $e[2]\n";
}
?>
Expected result:
[nothing]
Actual result:
--
HY000:2014: Cannot execute queries while other unbuffered queries are
active. Consider using PDOStatement::fetchAll(). Alternatively, if your
code is only ever going to run against mysql, you may enable query
buffering by setting the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute.
--
Edit this bug report at http://bugs.php.net/?id=36347&edit=1
#36405 [Bgs]: Enhanced expression reduction before function call
ID: 36405
User updated by: thom at genx dot net
-Summary: inline assignment of a variable used as a reference
fails
Reported By: thom at genx dot net
Status: Bogus
Bug Type: Feature/Change Request
Operating System: Linux (gentoo)
PHP Version: 5.1.2
New Comment:
According to the documentation, PHP supports function arguments that
are passed by value (default), reference, value with default, and
variable argument lists (> PHP 4). It does not say that passing by
expression is supported.
funcByValue($a++);
funcByValue($a + 9);
funcByValue($a = $b + 1);
I would like to think that PHP will continue to support the current
behavior of the above examples because it understands that expressions
can be reduced to a more base form. In the examples above, it is
assumed that PHP reduces the expressions to a value and that resulting
value is then used in the function call since it supports "passing by
value" (and not passing by expression).
With that in mind, an assignment expression can be reduced to a
variable. In the more general scenario, expressions whose outer most
component (based on the rules of precedence) is of assignment type can
be reduced to a variable. A variable is the required form for "passing
by reference".
Yes, an expression is an expression as you so nicely stated, but they
can be reduced. If expressions are reduced to a value so they can be
passed by value, why can't an assigment expression be reduced to a
variable so it can be passed by reference?
I understand that there is a workaround, but please do acknowledge the
fact that expressions work in the case of passing by value because they
are first reduced to a value (and continued support is planned). In the
case of an assignment expression and passing by reference, it would
require applying another rule of reduction and may still yield a
consistent interface within PHP.
PHP does still consider itself a scripting language and a change like
this might be a nuance meant for a programming language, but other
changes seem to imply that the PHP development team is open to such
suggestions (e.g. argument type hinting).
Thank you for considering this.
Previous Comments:
[2006-02-16 07:26:09] [EMAIL PROTECTED]
No, it won't change.
Expressions are expressions, you can't pass them by reference.
[2006-02-16 02:17:39] thom at genx dot net
Sorry, I left it as 'Bogus' this time. I thought that meant it was
closed and that any further responses were ignored.
This is changed to a Feature/Change request in hopes that it will
receive some attention and/or debate.
Thanks.
[2006-02-16 01:58:35] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Read the manual, the definition of an expression and a variable are
clearly explained. And keep it this bug as bogus it is not a bug (and
the behavior is documented).
[2006-02-16 01:43:39] thom at genx dot net
Maybe this is not a good argument, but other languages still interpret
that as passing $x by reference, but to do the assigment first. I am
going to use C++ as an example (since PHP has tried to model some of
its behavior from):
#include
using namespace std;
void
foo(int &x)
{
x = 9;
}
int
main()
{
int x;
foo(x = 1);
cout << x << "\n";
}
The output is: 9
There are no compiler warnings or errors (at the highest reporting
level). I understand that this is not C++, but previous versions of
PHP (< 5.1.2) behaved consistently with other programming languages in
the way that inline assignments were handled.
Is it something the PHP development team would consider (reverting back
to a more consistent behavior)?
Thanks,
thom
[2006-02-16 01:15:45] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
$x = 'foo' is an expression and cannot be passed by reference. Enable
E_STRICT to see the message.
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/36405
--
Edit this bug report at http://bugs.php.net/?id=36405&edit=1
#36420 [NEW]: segfault when access result->num_rows after calling result->close()
From: grikdotnet at aim dot com
Operating system: Linux
PHP version: 5.1.2
PHP Bug Type: MySQLi related
Bug description: segfault when access result->num_rows after calling
result->close()
Description:
I think, the bug #29656 (closed for 5.0.1) persists in 5.1.2
Segfault when trying to access
$result->num_rows
after calling $result->close() method
Reproduce code:
---
query('select 1');
$result->close();
echo $result->num_rows;
$mysqli->close();
?>
Expected result:
1
Actual result:
--
segmentation fault
I can post backtrace a bit later when recompile PHP with debugging if
required.
--
Edit bug report at http://bugs.php.net/?id=36420&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36420&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36420&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36420&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36420&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36420&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36420&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36420&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36420&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36420&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36420&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36420&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36420&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36420&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36420&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36420&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36420&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36420&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36420&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36420&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36420&r=mysqlcfg
#36360 [Opn->Asn]: PHP crashes when accessing an object that was just create by parent object
ID: 36360
Updated by: [EMAIL PROTECTED]
Reported By: karsten dot hohmeier at bbz-fulda dot de
-Status: Open
+Status: Assigned
Bug Type: COM related
Operating System: Windows Server 2003 SP1
PHP Version: 5CVS-2006-02-10 (snap)
-Assigned To:
+Assigned To: wez
Previous Comments:
[2006-02-10 17:59:21] karsten dot hohmeier at bbz-fulda dot de
Description:
I'm trying to automate MS ISA Server 2000 destination-set and
filter-rule generation by using its COM Objects. The creation and
modification processes perfectly works in VBS. When trying to implement
those mechanisms with PHP the Script crashes whenever i try to modify
newly created objects. The creation and modification is carried out and
the rules are visible in ISA Managment afterwards, but the PHP Script
does not cleanly exit. There are application errors (see below) logged
in the system log when running from commandline and as apache module
(apache crashes too).
If i do not try to modify any new objects the script terminates as
expected.
I tried any available 5.x Version of PHP below
php5.1-win32-200602101130.zip but no change in behavior.
Reproduce code:
---
$FilterRuleName = "TestRule";
$objFPC = new COM("FPC.Root") or die("Unable to create FPC Objekt");
$MyFPCRuleSets =
$objFPC->Arrays->GetContainingArray->ArrayPolicy->SiteAndContentRules;
$MyFPCRuleSets->Add($FilterRuleName);
$MyFPCRuleSets->Save();
unset($objFPC, $MyFPCRuleSets);
$objFPC = NULL;
$MyFPCRuleSets = NULL;
$objFPC = new COM("FPC.Root") or die("Unable to create FPC Objekt");
$MyFPCRule =
$objFPC->Arrays->GetContainingArray->ArrayPolicy->SiteAndContentRules->Item($FilterRuleName);
echo $MyFPCRule->Name."\r\n";
$MyFPCRule->Description = "TestDesc"; <--- Crash on modification
$MyFPCRule->Save();
unset($objFPC, $MyFPCRule);
$objFPC = NULL;
$MyFPCRule = NULL;
Expected result:
Clean exit of Script
Actual result:
--
PHP Crashes (commandline as well as Apache Module) and Logs 1 Event in
the Applicationlog
Application Failure php.exe 5.1.3.3 in php5ts.dll 5.1.3.3 at offset
8fea
or
Application Failure php.exe 5.1.3.3 in php5ts.dll 5.1.3.3 at offset
93a9
or
Application Failure php.exe 5.1.3.3 in php5ts.dll 5.1.3.3 at offset
9b9aa
--
Edit this bug report at http://bugs.php.net/?id=36360&edit=1
#36420 [Opn->Csd]: segfault when access result->num_rows after calling result->close()
ID: 36420
Updated by: [EMAIL PROTECTED]
Reported By: grikdotnet at aim dot com
-Status: Open
+Status: Closed
Bug Type: MySQLi related
Operating System: Linux
PHP Version: 5.1.2
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:
[2006-02-16 16:32:22] grikdotnet at aim dot com
Description:
I think, the bug #29656 (closed for 5.0.1) persists in 5.1.2
Segfault when trying to access
$result->num_rows
after calling $result->close() method
Reproduce code:
---
query('select 1');
$result->close();
echo $result->num_rows;
$mysqli->close();
?>
Expected result:
1
Actual result:
--
segmentation fault
I can post backtrace a bit later when recompile PHP with debugging if
required.
--
Edit this bug report at http://bugs.php.net/?id=36420&edit=1
#36418 [Fbk->Opn]: Graphics errors on multiple processes
ID: 36418
User updated by: jraben at alstermedia dot de
Reported By: jraben at alstermedia dot de
-Status: Feedback
+Status: Open
Bug Type: GD related
Operating System: Win XP
PHP Version: 5.1.2
New Comment:
Ok! Try this script:
http://www.alstermedia.de/phpbug.zip
Give 777 to out and script. For for finish and check all pics. Almost
on every run there are 3-4 pics with corrupted background. If you do
not see a bug try to refresh serveral times.
I included a corrupted pic called "1.jpg".
Previous Comments:
[2006-02-16 16:19:39] [EMAIL PROTECTED]
Please provide a set of source images and a valid script to reproduce
the problems. That means a working script, valid filenames, source
images, etc.
[2006-02-16 16:10:18] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-02-16 15:31:17] jraben at alstermedia dot de
Description:
It's a script that joins a background .gif picture with transparent png
24-bit pictures to a thumb jpg. It actually no the complete script.
$bfile is always the same. $file and $target may vary.
Some files have corrupted backgrounds, if the script is started in
multiple instances at the same time. Seems to be a memory allocation
bug.
Reproduce code:
---
$img = @imagecreatefromgif("$bfile");
$imgobj = @imagecreatefrompng("$file");
imagealphablending ( $imgobj, true );
$width = imagesx($imgobj);
$height = imagesy($imgobj);
$imgnew = imagecreatetruecolor($width, $height);
imagecopyresampled($imgnew,$img,0,0,$x,$y,$width,$height,$width,$height);
imagecopyresampled($imgnew,$imgobj,0,0,0,0,$width,$height,$width,$height);
imagejpeg($imgnew, $target, 90);
Expected result:
Not currupted pictures as .jpg with $bfile gif as background and $file
.png as foreground.
Actual result:
--
Some files have corrupted backgrounds, if this script is started in
multiple instances at the same time. Seems to be a memory allocation
bug or something with loading the same picture multiple times at the
same time.
--
Edit this bug report at http://bugs.php.net/?id=36418&edit=1
#36418 [Opn]: Graphics errors on multiple processes
ID: 36418
User updated by: jraben at alstermedia dot de
Reported By: jraben at alstermedia dot de
Status: Open
Bug Type: GD related
Operating System: Win XP
PHP Version: 5.1.2
New Comment:
btw I also tried the recent snapshot of php 5. Same bug.
Previous Comments:
[2006-02-16 17:10:29] jraben at alstermedia dot de
Ok! Try this script:
http://www.alstermedia.de/phpbug.zip
Give 777 to out and script. For for finish and check all pics. Almost
on every run there are 3-4 pics with corrupted background. If you do
not see a bug try to refresh serveral times.
I included a corrupted pic called "1.jpg".
[2006-02-16 16:19:39] [EMAIL PROTECTED]
Please provide a set of source images and a valid script to reproduce
the problems. That means a working script, valid filenames, source
images, etc.
[2006-02-16 16:10:18] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-02-16 15:31:17] jraben at alstermedia dot de
Description:
It's a script that joins a background .gif picture with transparent png
24-bit pictures to a thumb jpg. It actually no the complete script.
$bfile is always the same. $file and $target may vary.
Some files have corrupted backgrounds, if the script is started in
multiple instances at the same time. Seems to be a memory allocation
bug.
Reproduce code:
---
$img = @imagecreatefromgif("$bfile");
$imgobj = @imagecreatefrompng("$file");
imagealphablending ( $imgobj, true );
$width = imagesx($imgobj);
$height = imagesy($imgobj);
$imgnew = imagecreatetruecolor($width, $height);
imagecopyresampled($imgnew,$img,0,0,$x,$y,$width,$height,$width,$height);
imagecopyresampled($imgnew,$imgobj,0,0,0,0,$width,$height,$width,$height);
imagejpeg($imgnew, $target, 90);
Expected result:
Not currupted pictures as .jpg with $bfile gif as background and $file
.png as foreground.
Actual result:
--
Some files have corrupted backgrounds, if this script is started in
multiple instances at the same time. Seems to be a memory allocation
bug or something with loading the same picture multiple times at the
same time.
--
Edit this bug report at http://bugs.php.net/?id=36418&edit=1
#36418 [Opn->Bgs]: Graphics errors on multiple processes
ID: 36418
Updated by: [EMAIL PROTECTED]
Reported By: jraben at alstermedia dot de
-Status: Open
+Status: Bogus
Bug Type: GD related
Operating System: Win XP
PHP Version: 5.1.2
-Assigned To:
+Assigned To: pajoye
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.
You should consider to check concurrent accesses before writing the
images.
Previous Comments:
[2006-02-16 17:13:27] jraben at alstermedia dot de
btw I also tried the recent snapshot of php 5. Same bug.
[2006-02-16 17:10:29] jraben at alstermedia dot de
Ok! Try this script:
http://www.alstermedia.de/phpbug.zip
Give 777 to out and script. For for finish and check all pics. Almost
on every run there are 3-4 pics with corrupted background. If you do
not see a bug try to refresh serveral times.
I included a corrupted pic called "1.jpg".
[2006-02-16 16:19:39] [EMAIL PROTECTED]
Please provide a set of source images and a valid script to reproduce
the problems. That means a working script, valid filenames, source
images, etc.
[2006-02-16 16:10:18] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-02-16 15:31:17] jraben at alstermedia dot de
Description:
It's a script that joins a background .gif picture with transparent png
24-bit pictures to a thumb jpg. It actually no the complete script.
$bfile is always the same. $file and $target may vary.
Some files have corrupted backgrounds, if the script is started in
multiple instances at the same time. Seems to be a memory allocation
bug.
Reproduce code:
---
$img = @imagecreatefromgif("$bfile");
$imgobj = @imagecreatefrompng("$file");
imagealphablending ( $imgobj, true );
$width = imagesx($imgobj);
$height = imagesy($imgobj);
$imgnew = imagecreatetruecolor($width, $height);
imagecopyresampled($imgnew,$img,0,0,$x,$y,$width,$height,$width,$height);
imagecopyresampled($imgnew,$imgobj,0,0,0,0,$width,$height,$width,$height);
imagejpeg($imgnew, $target, 90);
Expected result:
Not currupted pictures as .jpg with $bfile gif as background and $file
.png as foreground.
Actual result:
--
Some files have corrupted backgrounds, if this script is started in
multiple instances at the same time. Seems to be a memory allocation
bug or something with loading the same picture multiple times at the
same time.
--
Edit this bug report at http://bugs.php.net/?id=36418&edit=1
#35582 [Csd]: Socket Timeout on SOAP request causes program termination
ID: 35582
Updated by: [EMAIL PROTECTED]
Reported By: s dot strampelli at isinet dot it
Status: Closed
Bug Type: SOAP related
Operating System: Windows
PHP Version: 5.1.1
Assigned To: dmitry
New Comment:
Some news about this??
Previous Comments:
[2005-12-07 15:01:01] [EMAIL PROTECTED]
The same as #33394.
[2005-12-07 14:37:31] [EMAIL PROTECTED]
Assigned to the maintainer.
[2005-12-07 14:26:43] s dot strampelli at isinet dot it
Description:
If a soap request timeout waiting http header, the program terminate
abnormally.
I think the bug is the call of efree without checking if http_headers
is not null in ext/soap/php_http.c , function http_connect about line
182:
if (!get_http_headers(stream, &http_headers, &http_header_size
TSRMLS_CC) || http_headers == NULL) {
php_stream_close(stream);
stream = NULL;
}
efree(http_headers);
Reproduce code:
---
$dati = "test";
$client = new SoapClient($wsdl);
$res = $client->test($dati);
If the execution time of test method is more than
default_socket_timeout seconds, the php interpret terminate with a dr
watson stack trace.
Expected result:
A SoapException would be thrown ?
Certainly, the PHP script could be expected to continue rather than
die.
Actual result:
--
PHP interpret (php.exe) dies with a dr watson stack trace.
--
Edit this bug report at http://bugs.php.net/?id=35582&edit=1
#33047 [Com]: glob() doesn't work inside directories with brackets [ ]
ID: 33047
Comment by: ian at res-alian dot com
Reported By: wiseman1024 at gmail dot com
Status: No Feedback
Bug Type: Directory function related
Operating System: Windows 2000
PHP Version: 4.3.9
New Comment:
I get the same problem with glob() using PHP 5.0.2 and 5.1.2 in Windows
2000 (my work computer, NTFS) and in Windows XP (notebook, 5.0.5, NTFS)
but not Linux (server, 5.0.2, ext3). Sorry I can't offer a solution
other than using Linux. I'm not sure if it has to do with the NTFS file
system.
It took me a while to figure out why some folders didn't work, and I
thought it was a permission thing. When I noticed the folder that
worked had no bracket, I tried adding brackets, and that made it not
work. (Also removing the brackets made ones with brackets suddenly
work.) Then I knew what to look for and found this bug entry with
Google.
What's strange is that glob() has no problem returning a list with some
entries containing brackets, but not any entries at all when within a
folder with brackets.
The other strange thing is the opendir() and readdir() work fine in the
same situation under Windows. It's more inconvenient but serves as a
workaround.
--i;
Previous Comments:
[2005-05-25 01:00:04] 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-05-17 20:47:36] [EMAIL PROTECTED]
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
[2005-05-17 18:09:30] wiseman1024 at gmail dot com
Description:
glob() won't work (with any pattern and options whatsoever) when one
directory in the current working path has matching brackets [ and ]
with characters between the brackets.
This means glob() will fail if the current working directory is one
of:
C:\php\[hello]
C:\php\[hello]\hello
C:\php\xxx[hello]xxx
C:\php\[hello][
It will work, for example, if the current working directory is one of:
C:\php
C:\php\[hello
C:\php\hello]
C:\php\hello[]
This seems to be a problem when using regular expressions in the
implementation of glob.
Reproduce code:
---
/* Returns a list of files and directories, unless inside a directory
with something between brackets*/
print_r(glob('*',FALSE));
Expected result:
Should always return an array with the files (assuming there are files
in the current directory)
Actual result:
--
Nothing, because glob() returned false
--
Edit this bug report at http://bugs.php.net/?id=33047&edit=1
#36421 [NEW]: Empty fields are retrieved by odbc_result on jions
From: michael dot rachow at gmail dot com Operating system: XP Pro PHP version: 4.4.2 PHP Bug Type: MSSQL related Bug description: Empty fields are retrieved by odbc_result on jions Description: Two tables A and B. A is left joined to B on one integer column. For all records where joined column of table A contains a null value all fields of the record in resultset are empty. The resultset usually containes more than one record. The records are retrieved by odbc_result. This is observed only on SQL Server 2005 Express. Checked with PHP 4.4.2 and 4.4.1 I have the original Windows build of PHP 4.4.2 Reproduce code: --- Table A cint integer cstr char ... Table B cint integer cstr char ... ... A left join B on A.cint = B.cint ... Expected result: If A.cint is null only B.cstr should be empty. Actual result: -- All selected fields A.cint, A.cstr, B.cint, B.cstr are empty when retrieving them with odbc_result. When A.cint cotains an integer where a record with A.cint = B.cint exists all data are retrieved. -- Edit bug report at http://bugs.php.net/?id=36421&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36421&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36421&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36421&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36421&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36421&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36421&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36421&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36421&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36421&r=support Expected behavior:http://bugs.php.net/fix.php?id=36421&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36421&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36421&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36421&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36421&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36421&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36421&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36421&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36421&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36421&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36421&r=mysqlcfg
#36421 [Opn->Fbk]: Empty fields are retrieved by odbc_result on jions
ID: 36421 Updated by: [EMAIL PROTECTED] Reported By: michael dot rachow at gmail dot com -Status: Open +Status: Feedback -Bug Type: MSSQL related +Bug Type: ODBC related Operating System: XP Pro PHP Version: 4.4.2 New Comment: 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. Previous Comments: [2006-02-16 18:41:50] michael dot rachow at gmail dot com Description: Two tables A and B. A is left joined to B on one integer column. For all records where joined column of table A contains a null value all fields of the record in resultset are empty. The resultset usually containes more than one record. The records are retrieved by odbc_result. This is observed only on SQL Server 2005 Express. Checked with PHP 4.4.2 and 4.4.1 I have the original Windows build of PHP 4.4.2 Reproduce code: --- Table A cint integer cstr char ... Table B cint integer cstr char ... ... A left join B on A.cint = B.cint ... Expected result: If A.cint is null only B.cstr should be empty. Actual result: -- All selected fields A.cint, A.cstr, B.cint, B.cstr are empty when retrieving them with odbc_result. When A.cint cotains an integer where a record with A.cint = B.cint exists all data are retrieved. -- Edit this bug report at http://bugs.php.net/?id=36421&edit=1
#36422 [NEW]: unserialize() __autoloads invalid objects
From: tomas_matousek at hotmail dot com
Operating system: WinXP
PHP version: 5.1.2
PHP Bug Type: Class/Object related
Bug description: unserialize() __autoloads invalid objects
Description:
When unserialize calls __autoload() and this dosn't load the required
class unserialize returns an object that doesn't behave like object;
var_dump displays it as an object but is_object gives false.
Reproduce code:
---
function __autoload($class_name)
{
}
var_dump($o = unserialize('O:1:"X":0:{}'));
var_dump(is_object($o));
Expected result:
object(__PHP_Incomplete_Class)#1 (1) {
["__PHP_Incomplete_Class_Name"]=>
string(1) "X"
}
bool(true)
Actual result:
--
object(__PHP_Incomplete_Class)#1 (1) {
["__PHP_Incomplete_Class_Name"]=>
string(1) "X"
}
bool(false)
--
Edit bug report at http://bugs.php.net/?id=36422&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36422&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36422&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36422&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36422&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36422&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36422&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36422&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36422&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36422&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36422&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36422&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36422&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36422&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36422&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36422&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36422&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36422&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36422&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36422&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36422&r=mysqlcfg
#16263 [Com]: session.start() create new empty session file and not resume existing session
ID: 16263 Comment by: optikey at gmail dot com Reported By: kur at natur dot cuni dot cz Status: No Feedback Bug Type: Session related Operating System: ANY PHP Version: 4.3.0-dev New Comment: Same problem with 5.0.5 running on Debian x86_64... Only I.E. does this 2 cookies thing and scroolled my code... Digging the net, i found that those bugs started only in the browsers that executes windows update automatically... So i find that the day that the problems started matches the day of the release of one Microsoft Bugfix that affects I.E. 14/feb/2006 Only the updated browsers behave incorrectly Might we need to blame M$ Any workarounds??? Am i right??? MS did not return the bug report... Previous Comments: [2006-02-15 17:05:12] bohn at netbuild dot net got same problem under using php 4.3.10 :( on heavy load, php creates a new session... fc3, apache2, php4.3.10, lvs [2006-01-30 22:21:11] geso at inmail dot sk I've got same problem with 5.1.2 (and previously with 4.3.8). Both clean install, Win2k, IIS 5.0. Everytime I enter (reload) a page, it creates a new file in my sessions directory. [2005-11-15 16:25:07] f dot schiappelli at enpam dot it Same problem with PHP 5.0.2, Apache 2.0.52, Windows XP. Did anybody solved the problem? Thanks in advance, Faith [2005-10-26 17:21:19] beny dot eleeas at gmail dot com I got the same problem in PHP 4.3.10. What should I do? System Linux Build Date Dec 18 2004 22:24:47 Server API CGI Virtual Directory Support disabled Configuration File (php.ini) Path /home/lib/php/php.ini PHP API 20020918 PHP Extension 20020429 Zend Extension 20021010 Debug Build no Thread Safety disabled Registered PHP Streams php, http, ftp, https, ftps session.cache_limiter nocache session.cookie_domain no value session.cookie_lifetime 0 session.cookie_path / session.cookie_secure Off session.entropy_file /dev/urandom session.entropy_length 64 session.gc_divisor 100 session.gc_maxlifetime 1440 session.gc_probability 1 session.name PHPSESSID session.referer_check no value session.save_handler files session.save_path /home/var/state/php session.serialize_handler php session.use_cookies On session.use_only_cookies Off session.use_trans_sid Off [2005-09-19 17:34:10] bananen_007 at hotmail dot com Just wanted to say that I got the same problem in PHP 5.0.5 clean installation with Apache 2.x.x. Reading\Writing to session works in the same page but the server loses the session when going between different pages or reloading the page. 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/16263 -- Edit this bug report at http://bugs.php.net/?id=16263&edit=1
#36404 [Opn->Fbk]: configure script cannot complete libxml build
ID: 36404
Updated by: [EMAIL PROTECTED]
Reported By: davecenker at cfl dot rr dot com
-Status: Open
+Status: Feedback
Bug Type: *Compile Issues
Operating System: Solaris 8
PHP Version: 5.1.2
New Comment:
Please upload whole config.log somewhere and provide the link here.
Previous Comments:
[2006-02-15 22:20:48] davecenker at cfl dot rr dot com
Description:
I am having difficulties getting past the libxml build check when
configuring PHP. I have installed libxml version 2.6.23 and am
attempting to run the configure script for PHP version 5.1.2. I have
seen other bug reports similar to this, but none of the recommended
fixes seem to address my problem.
Below is the complete configure commandline:
./configure --with-apxs=/home/dcenker/AMP/apache/bin/apxs
--with-mysqli=/home/dcenker/AMP/mysql/bin/mysql_config
--enable-mbstring --enable-soap --with-libxml-dir=/home/dcenker/libxml
where /home/dcenker/libxml/bin contains the xml2-config executable.
The last few lines of the config.log file are as follows:
Any help in resolving this installation issue would be greatly
appreciated. If you need any additional information, please let me
know. Thank you.
Actual result:
--
<<>>
configure:18440: checking whether to enable LIBXML support
configure:18487: checking libxml2 install dir
configure:18647: checking whether libxml build works
configure:18674: gcc -o conftest -g -O2 -D_POSIX_PTHREAD_SEMANTICS
-R/usr/ucbli
b -L/usr/ucblib
-R/apps/gcc-3.0.4/lib/gcc-lib/sparc-sun-solaris2.7/3.0.4 -L/apps/
gcc-3.0.4/lib/gcc-lib/sparc-sun-solaris2.7/3.0.4
-R/home/dcenker/libxml/lib -L/ho
me/dcenker/libxml/lib conftest.c
-lresolv -lm -ldl -lnsl -lsocket -lgcc -lxml2 -lz -lm
-lsocket -lnsl 1>
&5
configure: failed program was:
#line 18663 "configure"
#include "confdefs.h"
char xmlInitParser();
int main() {
xmlInitParser();
return 0;
}
<<>>
--
Edit this bug report at http://bugs.php.net/?id=36404&edit=1
#36423 [NEW]: Suggestion for FTP functions
From: bholbrook at servillian dot com Operating system: Red Hat v? PHP version: 4.4.2 PHP Bug Type: *General Issues Bug description: Suggestion for FTP functions Description: Suggestion for additional FTP functions ftp_is_dir(), ftp_file_exists(), ftp_is_file(). Currently can be accomplished by if(!ftp_chdir()), if(!ftp_mdtm()) but has some effects on true that can cause additional coding. Sorry if this is the wrong place for it (please let me know where to send these so that I dont repeat this mistake) Thanks. -- Edit bug report at http://bugs.php.net/?id=36423&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36423&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36423&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36423&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36423&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36423&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36423&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36423&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36423&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36423&r=support Expected behavior:http://bugs.php.net/fix.php?id=36423&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36423&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36423&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36423&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36423&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36423&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36423&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36423&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36423&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36423&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36423&r=mysqlcfg
#33047 [Com]: glob() doesn't work inside directories with brackets [ ]
ID: 33047
Comment by: ian at res-alian dot com
Reported By: wiseman1024 at gmail dot com
Status: No Feedback
Bug Type: Directory function related
Operating System: Windows 2000
PHP Version: 4.3.9
New Comment:
Here's my workaround code, using opendir() and readdir() (using code
from the readdir() page on this site):
if ($dirh = opendir("."))
{
$picfns = 0;
while (false !== ($file = readdir($dirh)))
{
if (preg_match("/^_.*jpg$/", $file))
{
$file = preg_replace("/^_/", "", $file);
if ($picfns)
{
array_push($picfns, $file);
}
else
{
$picfns = array($file);
}
}
}
closedir($dirh);
}
replaces this code:
$thumbfns = glob("_*.jpg");
$jpgfns = glob("*.jpg");
$picfns = array_diff($jpgfns, $thumbfns);
--i;
Previous Comments:
[2006-02-16 18:41:20] ian at res-alian dot com
I get the same problem with glob() using PHP 5.0.2 and 5.1.2 in Windows
2000 (my work computer, NTFS) and in Windows XP (notebook, 5.0.5, NTFS)
but not Linux (server, 5.0.2, ext3). Sorry I can't offer a solution
other than using Linux. I'm not sure if it has to do with the NTFS file
system.
It took me a while to figure out why some folders didn't work, and I
thought it was a permission thing. When I noticed the folder that
worked had no bracket, I tried adding brackets, and that made it not
work. (Also removing the brackets made ones with brackets suddenly
work.) Then I knew what to look for and found this bug entry with
Google.
What's strange is that glob() has no problem returning a list with some
entries containing brackets, but not any entries at all when within a
folder with brackets.
The other strange thing is the opendir() and readdir() work fine in the
same situation under Windows. It's more inconvenient but serves as a
workaround.
--i;
[2005-05-25 01:00:04] 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-05-17 20:47:36] [EMAIL PROTECTED]
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
[2005-05-17 18:09:30] wiseman1024 at gmail dot com
Description:
glob() won't work (with any pattern and options whatsoever) when one
directory in the current working path has matching brackets [ and ]
with characters between the brackets.
This means glob() will fail if the current working directory is one
of:
C:\php\[hello]
C:\php\[hello]\hello
C:\php\xxx[hello]xxx
C:\php\[hello][
It will work, for example, if the current working directory is one of:
C:\php
C:\php\[hello
C:\php\hello]
C:\php\hello[]
This seems to be a problem when using regular expressions in the
implementation of glob.
Reproduce code:
---
/* Returns a list of files and directories, unless inside a directory
with something between brackets*/
print_r(glob('*',FALSE));
Expected result:
Should always return an array with the files (assuming there are files
in the current directory)
Actual result:
--
Nothing, because glob() returned false
--
Edit this bug report at http://bugs.php.net/?id=33047&edit=1
#33047 [Com]: glob() doesn't work inside directories with brackets [ ]
ID: 33047
Comment by: ian at res-alian dot com
Reported By: wiseman1024 at gmail dot com
Status: No Feedback
Bug Type: Directory function related
Operating System: Windows 2000
PHP Version: 4.3.9
New Comment:
Argh. I forgot to add sort($picfns) for good measure, since readdir()
returns entries in the order they appear on the hard drive while glob()
returns them sorted (unless using the GLOB_NOSORT flag). If the PHP
developers fix the glob() Win32 bug, I can stop ranting =)
--i;
Previous Comments:
[2006-02-16 23:19:14] ian at res-alian dot com
Here's my workaround code, using opendir() and readdir() (using code
from the readdir() page on this site):
if ($dirh = opendir("."))
{
$picfns = 0;
while (false !== ($file = readdir($dirh)))
{
if (preg_match("/^_.*jpg$/", $file))
{
$file = preg_replace("/^_/", "", $file);
if ($picfns)
{
array_push($picfns, $file);
}
else
{
$picfns = array($file);
}
}
}
closedir($dirh);
}
replaces this code:
$thumbfns = glob("_*.jpg");
$jpgfns = glob("*.jpg");
$picfns = array_diff($jpgfns, $thumbfns);
--i;
[2006-02-16 18:41:20] ian at res-alian dot com
I get the same problem with glob() using PHP 5.0.2 and 5.1.2 in Windows
2000 (my work computer, NTFS) and in Windows XP (notebook, 5.0.5, NTFS)
but not Linux (server, 5.0.2, ext3). Sorry I can't offer a solution
other than using Linux. I'm not sure if it has to do with the NTFS file
system.
It took me a while to figure out why some folders didn't work, and I
thought it was a permission thing. When I noticed the folder that
worked had no bracket, I tried adding brackets, and that made it not
work. (Also removing the brackets made ones with brackets suddenly
work.) Then I knew what to look for and found this bug entry with
Google.
What's strange is that glob() has no problem returning a list with some
entries containing brackets, but not any entries at all when within a
folder with brackets.
The other strange thing is the opendir() and readdir() work fine in the
same situation under Windows. It's more inconvenient but serves as a
workaround.
--i;
[2005-05-25 01:00:04] 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-05-17 20:47:36] [EMAIL PROTECTED]
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
[2005-05-17 18:09:30] wiseman1024 at gmail dot com
Description:
glob() won't work (with any pattern and options whatsoever) when one
directory in the current working path has matching brackets [ and ]
with characters between the brackets.
This means glob() will fail if the current working directory is one
of:
C:\php\[hello]
C:\php\[hello]\hello
C:\php\xxx[hello]xxx
C:\php\[hello][
It will work, for example, if the current working directory is one of:
C:\php
C:\php\[hello
C:\php\hello]
C:\php\hello[]
This seems to be a problem when using regular expressions in the
implementation of glob.
Reproduce code:
---
/* Returns a list of files and directories, unless inside a directory
with something between brackets*/
print_r(glob('*',FALSE));
Expected result:
Should always return an array with the files (assuming there are files
in the current directory)
Actual result:
--
Nothing, because glob() returned false
--
Edit this bug report at http://bugs.php.net/?id=33047&edit=1
#19909 [NoF->Bgs]: No PCRE support for mbstring
ID: 19909 Updated by: [EMAIL PROTECTED] Reported By: paul at honeylocust dot com -Status: No Feedback +Status: Bogus Bug Type: mbstring related Operating System: any PHP Version: 4.3.0-pre1 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: [2002-11-10 18:20:41] [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-10-14 16:22:40] [EMAIL PROTECTED] Since when has PCRE been a multibyte string encoding? Can you be more specific about what you need? PHP ships with UTF-8 enabled PCRE by default (if you use the bundled PCRE), and has done since before 4.2 for unix (4.2 and later for windows). mbstring != PCRE; their functions are completely different. [2002-10-14 14:48:41] paul at honeylocust dot com Mbstring doesn't provide support for PCRE. This is unfortunate since there is (experimental) UTF-8 support in PCRE which is as simple to turn on as flipping a compile flag and specifying an option to pcre_compile() -- Edit this bug report at http://bugs.php.net/?id=19909&edit=1
#32062 [NoF->Bgs]: mbstring fails to match encoding with some locale settings
ID: 32062 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Bogus Bug Type: mbstring related Operating System: * PHP Version: 5CVS, 4CVS (2005-02-22) Assigned To: hirokawa 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-12-31 01:00:04] 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-12-23 15:43:27] [EMAIL PROTECTED] mbstring (libmbfl) uses strcasecmp() which depends on the locale. If the specified locale is not supported in the system, encoding match fails. It is not the problem of mbstring, but it is the problem of system setting. [2005-12-21 23:24:01] [EMAIL PROTECTED] Rui, check this too if you don't mind. :) [2005-02-22 16:17:51] [EMAIL PROTECTED] Right, there were typos. The reproduce code should've been [2005-02-22 15:25:03] [EMAIL PROTECTED] tr_TR == Turkish, and ISO-8859-1 is not a valid character set of that locale, no? 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/32062 -- Edit this bug report at http://bugs.php.net/?id=32062&edit=1
#34119 [NoF->Csd]: mb_ereg chokes on \x80-\xF7
ID: 34119
Updated by: [EMAIL PROTECTED]
Reported By: ondrej at sury dot org
-Status: No Feedback
+Status: Closed
Bug Type: mbstring related
Operating System: Linux
PHP Version: 4.4.0
Assigned To: hirokawa
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:
[2006-01-01 01:00:06] 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-12-24 06:20:10] [EMAIL PROTECTED]
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
It works fine for me.
Please check it by CVS snapshot of PHP 4.4.
Code:
Result in PHP 4.4.2RC2-dev (Linux FedoraCore4):
The username contains an illegal character.
[2005-12-24 02:32:29] [EMAIL PROTECTED]
Rui, check this out please.
[2005-08-13 20:29:39] [EMAIL PROTECTED]
Moriyoshi, I guess you need to backport something..?
[2005-08-13 13:12:22] ondrej at sury dot org
Description:
mb_ereg prints invalid regular expression error on certain characters.
This is fixed in php 5.0.4.
More information could be found at:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=278044
Reproduce code:
---
$name = "user/1/viewuser/1/edit";
if (mb_ereg("[^\x80-\xF7 [:alnum:[EMAIL PROTECTED]", $name)) print('The username
contains an illegal character.');
Expected result:
The username contains an illegal character.
Actual result:
--
Warning: mb_ereg(): mbregex compile err: invalid regular expression in
/var/www/mb_ereg.php on line 4
--
Edit this bug report at http://bugs.php.net/?id=34119&edit=1
#36424 [NEW]: Serializable interface breaks object references
From: mastabog at hotmail dot com
Operating system: *nix, win32
PHP version: 5.1.2
PHP Bug Type: SPL related
Bug description: Serializable interface breaks object references
Description:
First of all, I know this is very new and undocumented.
The Serializable interface serialize() method breaks reference of objects
that are properties of the serialized object and that they themselves
implement the Serializable interface. See the reproduceable code below.
an echo over $ser yields:
C:1:"C":85:{a:2:{s:1:"A";C:1:"A":6:{a:0:{}}s:1:"B";C:1:"B":32:{a:1:{s:1:"A";C:1:"A":6:{a:0:{}}
It's visible that the last A is not a reference but a new class instance.
I know that Serializable::unserialize() acts as a constructor, but
shouldn't object references be honored by Serializable::serialize() the
same way unserialize() does when the class does not implement the
Serializable interface.
If we remove the Serializable interface from class A and leave it like
this:
class A {}
then $ser looks like the following:
O:1:"C":2:{s:1:"A";O:1:"A":0:{}s:1:"B";O:1:"B":1:{s:1:"A";r:2;}}
And it's visible that the last A is a reference.
If this is all intended behavior for the Serializable interface to break
object references then you can ignore this bug report. I hope it's not
though, because it would have provided a better alternative to the
__sleep() and __wakeup() (e.g. classes extending the PDO class cannot be
serialized using __sleep() and __wakeup(), neither by overloading nor by
default)
Reproduce code:
---
class A implements Serializable
{
public function serialize ()
{
$serialized = array();
foreach($this as $prop => $val) {
$serialized[$prop] = $val;
}
return serialize($serialized);
//return serialize(get_object_vars($this));
}
function unserialize($serialized)
{
foreach(unserialize($serialized) as $prop => $val) {
$this->$prop = $val;
}
return true;
}
}
class B extends A
{
public $A;
}
class C extends A
{
public $A;
public $B;
}
$oC = new C();
$oC->A = new A();
$oC->B = new B();
$oC->B->A = $oC->A;
echo $oC->A === $oC->B->A ? "yes" : "no", "\n";
$ser = serialize($oC);
$new_oC = unserialize($ser);
echo $new_oC->A === $new_oC->B->A ? "yes" : "no", "\n";
Expected result:
yes
yes
Actual result:
--
yes
no
--
Edit bug report at http://bugs.php.net/?id=36424&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36424&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36424&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36424&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36424&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36424&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36424&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36424&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36424&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36424&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36424&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36424&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36424&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36424&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36424&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36424&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36424&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36424&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36424&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36424&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36424&r=mysqlcfg
#36398 [Opn]: "make test" should be fully scriptable [Do not prompt for email address]
ID: 36398
User updated by: nickj-phpbugs at nickj dot org
Reported By: nickj-phpbugs at nickj dot org
Status: Open
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 5.1.2
New Comment:
No worries! There is a patch now available for this at:
http://www.files.nickj.org/php/run-tests-patch.txt
Also, the run-test.php script is not currently E_STRICT clean. I have
included in the patch some simple changes I had to make to get it to
run with E_STRICT enabled.
Note that there are 3 remaining things I did not know how to fix for
clean E_STRICT output, so even with this patch run-tests.php is still
not totally E_STRICT clean. The three remaining things were:
1) Was this error:
Error! type: 8; File:
/root/php-5.1-dev/php5.1-200602150330/run-tests.php; Line: 93; Message:
ob_end_clean(): failed to delete buffer. No buffer to delete.
... which was generated by this line under E_STRICT:
while(@ob_end_clean());
2) Was the use of date() in this line:
$output_file = $CUR_DIR . '/php_test_results_' . date('Ymd_Hi') .
'.txt';
Which gives this error under E_STRICT:
Error! type: 2048; File:
/root/php-5.1-dev/php5.1-200602150330/run-tests.php; Line: 246;
Message: date(): It is not safe to rely on the system's timezone
settings. Please use the date.timezone setting, the TZ environment
variable or the date_default_timezone_set() function. In case you used
any of those methods and you are still getting this warning, you most
likely misspelled the timezone identifier. We selected
'Australia/Melbourne' for 'EST/11.0/DST' instead
Not sure how to say "just use the system default" nowadays, given that
we probably shouldn't hard-code a timezone, as users from anywhere
could be running this test script.
3) Was the "select_stream" call in the "system_with_timeout" function,
which generates this error under E_STRICT:
Error! type: 2; File:
/root/php-5.1-dev/php5.1-200602150330/run-tests.php; Line: 893;
Message: stream_select(): 230 is not a valid stream resource
Previous Comments:
[2006-02-16 07:35:06] [EMAIL PROTECTED]
Thanks, I've just fixed the typo.
As for the request - I'm pretty sure you can add it to run-tests.php
and send a patch for us to review.
Though, I don't know if we really want php-qa list to get filled with
results of the tests executed automatically every X minutes.
[2006-02-16 06:19:59] nickj-phpbugs at nickj dot org
Thank you - that sort of helps, and I realise now that I should have
phrased my request better (so I have reopened, and rephrased it to
hopefully be clearer).
What I mostly wanted was to run the tests, and then email the results
off, without prompting.
I can enable/disable the prompt now with:
TEST_PHP_ARGS="-q" make test
And I can see the available options with:
TEST_PHP_EXECUTABLE="/root/tmp/php-5.1-dev/php5.1-200602150330/sapi/cli/php"
sapi/cli/php run-tests.php --help
However, unless I am mistaken, I can't see any option to specify the
email address to use, such as for example:
TEST_PHP_ARGS="--email-results [EMAIL PROTECTED]" make test
My underlying assumption here is that you folks want and use the output
of "make test" in some way. If that's not the case, then of course,
don't make it an option. However, if you are using this, then wouldn't
it be good to be able to script it so that it could automatically email
off the results of make test, without having to prompt the user? Then
you could (for example) have the build farm automatically email the
qa.php.net list with the results of "make test" after every build of
every snapshot. Maybe you already do this in some other way, but if
not, it seems like it could be useful to me.
You could also update http://qa.php.net/running-tests.php with this
information, so that people could "set and forget" to run the tests and
email the results, without prompting them.
P.s. there is a very small typo in the help for "make test". It says
"-q Quite, no user interaction"; but you want it to say "Quiet", not
"Quite".
[2006-02-15 08:48:46] [EMAIL PROTECTED]
You can already do this, set the env variable TEST_PHP_ARGS to "-q" and
it should skip the question. Use -h to get all available options.
[2006-02-15 06:56:06] nickj-phpbugs at nickj dot org
Description:
I have a little shell script to download PHP snapshots, extract them,
configure them, and build them. I would like to add automatically
running "make test" on them.
However, it does not appear that this can be done at the moment,
because "make test" prompts the user for information after running
tests, like so:
You may have found a problem in PHP.
We would like to send t
