[PHP-BUG] Req #51629 [NEW]: CURLOPT_FOLLOWLOCATION error message is misleading
From: Operating system: N/A PHP version: 5.3.2 Package: Safe Mode/open_basedir Bug Type: Feature/Change Request Bug description:CURLOPT_FOLLOWLOCATION error message is misleading Description: The following error message is semantically wrong (and for the "newbies" that aren't familiar with PHP, very misleading/confusing): Warning: curl_setopt() [function.curl-setopt]: CURLOPT_FOLLOWLOCATION can not be activated when in safe_mode or an open_basedir is set in on line >From a purely grammatical standpoint, that error message is saying that one of the following conditions caused the error: either you're in safe_mode, or an open_basedir option was set in . The "in on line " that directly follows the open_basedir bit makes it sound like one should look for something dealing with "open_basedir" in in order to resolve the error (assuming they aren't in safe mode). This situation actually happened on a PHP support community I'm a member of. I only mention this to show that I'm not simply quibbling over semantics/grammar but rather trying to clarify a misleading error message. Test script: --- http://bugs.php.net/bug.php?id=51629&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51629&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51629&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51629&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51629&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51629&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51629&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51629&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51629&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51629&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51629&r=support Expected behavior: http://bugs.php.net/fix.php?id=51629&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51629&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51629&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51629&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51629&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51629&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51629&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51629&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51629&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51629&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51629&r=mysqlcfg
Bug #45786 [Com]: FastCGI process exited unexpectedly
Edit report at http://bugs.php.net/bug.php?id=45786&edit=1 ID: 45786 Comment by: sejo at iteontech dot com Reported by: karelevzen at gmail dot com Summary: FastCGI process exited unexpectedly Status: Closed Type: Bug Package: CGI related Operating System: Windows Vista Ultimate x64 SP1 PHP Version: 5.3CVS-2008-08-10 (CVS) Assigned To: dmitry New Comment: After debugging IIS and a bunch of other crazy things, this is what worked for me. I have PHP 5.3.2 on Windows 7 and IIS 7. Try to execute PHP-CGI.EXE (BY DOUBLECLICKING ON IT). See if you get any error messages/ pop-ups. I got a ton of them and it all boiled down on having a bunch of extensions turned on, but not being available in my ext folder. Clear the PHP.INI of those invalid extensions and the problem should go away. Previous Comments: [2010-04-12 19:36:05] paj...@php.net Did you enable mbstring as well? And put it before exif in the list? Exif requires mbstring. However that's unrelated to this bug, please ask for support on the PHP windows mailing list (or any other support channel). [2010-04-12 19:11:02] differentpk at gmail dot com I had the same problem like error 500, I set all extentions off and the problem was gone. Then i uncommented extentions one by one and found that the problems occures at ;extension=php_exif.dll. Though i removed the error message but i am still unable to find the solution yet. [2008-08-26 09:59:12] dmi...@php.net 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. [2008-08-18 18:45:10] karelevzen at gmail dot com If this helps, I have created a dump 6 seconds after executing the page. Thread 0: ntdll!NtDelayExecution+15 kernel32!SleepEx+62 kernel32!Sleep+f php5ts!php_get_inf+1eaf php5ts!execute+cc5 php5ts!execute+6130 Thread 1: user32!NtUserGetMessage+15 user32!GetMessageA+a2 php5ts!zend_timeout+1a8 Another thing I found interesting is, that upon the request, a php-cgi.exe is created and does nothing. After the timeout, in the same exact moment, a new php-cgi.exe is created, the old php-cgi.exe is destroyed and the page is rendered. Is this behaviour normal or should I futher investigate this strange process? This second php-cgi.exe process is destroyed upon refresh and the display of the IIS error message. [2008-08-18 15:58:20] karelevzen at gmail dot com No succes, sorry. It behaves the same, eg. it loads the content, then keeps "loading" for some time (faulty php module). This time, the GUI error message DOES NOT APPER, but when I hit refresh, it displays a IIS error message stating: HTTP Error 500.0 - Internal Server Error Module FastCgiModule NotificationExecuteRequestHandler Handler PHP Error Code 0x8007000d After another refresh the page again loads, keeps on loading for a while, than, after another refresh the same error appears. IMHO it's the same problem, but this time IIS realizes that an error had occured when the second request is received. Due to the GUI error not showing, I cannot send you a crushdump. 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/bug.php?id=45786 -- Edit this bug report at http://bugs.php.net/bug.php?id=45786&edit=1
Bug #51604 [Asn->Csd]: newline in end of header is shown in start of message
Edit report at http://bugs.php.net/bug.php?id=51604&edit=1 ID: 51604 Updated by: ahar...@php.net Reported by: pavol at klacansky dot com Summary: newline in end of header is shown in start of message -Status: Assigned +Status: Closed Type: Bug Package: Mail related Operating System: Ubuntu PHP Version: 5.3.2 Assigned To: aharvey New Comment: This bug has been fixed in SVN. 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. Thanks for the patch, Daniel. Previous Comments: [2010-04-22 04:22:51] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&revision=298291 Log: Fix for bug #51604 (newline in end of header is shown in start of message). Patch by Daniel Egeberg. [2010-04-21 16:01:58] degeb...@php.net The attached patch will fix this issue. I don't have php-src karma, so I can't commit it myself. [2010-04-21 16:00:42] degeb...@php.net The following patch has been added/updated: Patch Name: php_bug51604.diff Revision: 1271858442 URL: http://bugs.php.net/patch-display.php?bug=51604&patch=php_bug51604.diff&revision=1271858442 [2010-04-19 20:50:47] pavol at klacansky dot com Actual result: -- \nHallo [2010-04-19 20:49:55] pavol at klacansky dot com Description: if I have a newline (\n) at the end of last header, it will show to start of message of mail Test script: --- Expected result: Hallo Actual result: -- Hallo -- Edit this bug report at http://bugs.php.net/bug.php?id=51604&edit=1
Bug #51604 [Opn->Asn]: newline in end of header is shown in start of message
Edit report at http://bugs.php.net/bug.php?id=51604&edit=1 ID: 51604 Updated by: ahar...@php.net Reported by: pavol at klacansky dot com Summary: newline in end of header is shown in start of message -Status: Open +Status: Assigned Type: Bug Package: Mail related Operating System: Ubuntu PHP Version: 5.3.2 -Assigned To: +Assigned To: aharvey Previous Comments: [2010-04-21 16:01:58] degeb...@php.net The attached patch will fix this issue. I don't have php-src karma, so I can't commit it myself. [2010-04-21 16:00:42] degeb...@php.net The following patch has been added/updated: Patch Name: php_bug51604.diff Revision: 1271858442 URL: http://bugs.php.net/patch-display.php?bug=51604&patch=php_bug51604.diff&revision=1271858442 [2010-04-19 20:50:47] pavol at klacansky dot com Actual result: -- \nHallo [2010-04-19 20:49:55] pavol at klacansky dot com Description: if I have a newline (\n) at the end of last header, it will show to start of message of mail Test script: --- Expected result: Hallo Actual result: -- Hallo -- Edit this bug report at http://bugs.php.net/bug.php?id=51604&edit=1
Bug #51601 [Fbk->Opn]: Segmentation fault when using the 2-argument form of mysql_fetch_array
Edit report at http://bugs.php.net/bug.php?id=51601&edit=1
ID: 51601
User updated by: pcarter at jhu dot edu
Reported by: pcarter at jhu dot edu
Summary: Segmentation fault when using the 2-argument form of
mysql_fetch_array
-Status: Feedback
+Status: Open
Type: Bug
Package: MySQL related
Operating System: FreeBSD 6.2-RELEASE
PHP Version: 5.3.2
New Comment:
The problem persists with php5.3-201004220030. The backtrace is
identical save instruction addresses.
Previous Comments:
[2010-04-22 02:19:19] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-04-19 17:04:44] pcarter at jhu dot edu
I missed on the package dropdown when submitting the bug. This belongs
with the MySQL package, not the MSSQL package.
[2010-04-19 17:03:06] pcarter at jhu dot edu
Description:
When using the two-argument form of mysql_fetch_array PHP experiences a
segmentation fault in zend_fetch_resource, attempting to dereference a
null pointer. (specifically *passed_id is ((* zval)(0x0)) when
performing the IS_RESOURCE check). This happens regardless of which of
the three MYSQL_{BOTH|ASSOC|NUM} constants are used as the second
argument (the given script uses MYSQL_BOTH). This problem does not
occur when using the single argument form of mysql_fetch_array, and it
does not occur when using the mysql_fetch_assoc() or mysql_fetch_row()
functions.
Test environment is FreeSBD 6.2-RELEASE on amd64, with the MySQL 5.0
client library installed.
Test script:
---
Expected result:
The script should print an array (numerically and associatively indexed)
of the tables in the database "test".
Actual result:
--
Segmentation fault as noted above. Backtrace:
Backtrace:
#0 0x00638ed3 in zend_fetch_resource (passed_id=0x7fffce30,
default_id=-1, resource_type_name=0x72fa51 "MySQL result",
found_resource_type=0x0, num_resource_types=1)
at /usr/local/src/php-5.3.2/Zend/zend_list.c:127
#1 0x004d76a6 in php_mysql_fetch_hash (ht=2,
return_value=0x9240a0, return_value_ptr=0x638ddf, this_ptr=0x0,
return_value_used=1, result_type=3, expected_args=2, into_object=0)
at /usr/local/src/php-5.3.2/ext/mysql/php_mysql.c:1944
#2 0x004d7c2b in zif_mysql_fetch_array (ht=-12752,
return_value=0x, return_value_ptr=0x638ddf, this_ptr=0x0,
return_value_used=1) at
/usr/local/src/php-5.3.2/ext/mysql/php_mysql.c:2105
#3 0x0064e192 in zend_do_fcall_common_helper_SPEC
(execute_data=0xb45040) at zend_vm_execute.h:313
#4 0x0064d5b9 in execute (op_array=0x9248c8) at
zend_vm_execute.h:104
#5 0x0062b765 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/local/src/php-5.3.2/Zend/zend.c:1194
#6 0x005d955b in php_execute_script
(primary_file=0x7fffeb00) at
/usr/local/src/php-5.3.2/main/main.c:2260
#7 0x006b2bca in main (argc=2, argv=0x7fffec00) at
/usr/local/src/php-5.3.2/sapi/cli/php_cli.c:1192
--
Edit this bug report at http://bugs.php.net/bug.php?id=51601&edit=1
Bug #51625 [Opn]: php: threads.c:321: krb5int_key_register: Assertion `keynum >= 0 && keynum < K5
Edit report at http://bugs.php.net/bug.php?id=51625&edit=1 ID: 51625 Updated by: s...@php.net Reported by: Eduards dot Samersovs at inbox dot lv Summary: php: threads.c:321: krb5int_key_register: Assertion `keynum >= 0 && keynum < K5 Status: Open Type: Bug Package: OCI8 related Operating System: Ubuntu 9.10 PHP Version: 5.3.2 -Assigned To: +Assigned To: sixd New Comment: I haven't been able to set up an enviroment to test your options. One thought is to build PHP without OCI8 & PDO_OCI, and then install them later as shared extensions. There are a couple of potential inconsistencies in the bug report. Why install Instant Client if the DB libraries are available and used by the configure options? Were you using RPMs on Ubuntu, or the ZIP files? Some of the configuration options mentioned don't exist in PHP 5.3. The syntax for --with-pdo-oci is missing the version number. Previous Comments: [2010-04-21 15:14:42] Eduards dot Samersovs at inbox dot lv Description: Installed last Oracle 11gR2 database + oracle-instantclient11.2-basic-11.2.0.1.0-1.i386.rpm oracle-instantclient11.2-devel-11.2.0.1.0-1.i386.rpm I try also previous version of oracle-instantclient from 10gR2 - the result was ne same. Without "--with-oci8=/home/oracle/product/11.2.0/db_home1 --with-pdo-oci=/home/oracle/product/11.2.0/db_home1" options compilation is successfull! Compiling using "root" user with full access. ./configure \ --with-apxs2=$PREFIX/bin/apxs \ --with-openssl \ --with-bz2 \ --with-zlib=/usr/local/zlib \ --enable-sigchild \ --without-sqlite \ --without-pdo-sqlite \ --with-xml --with-dom \ --with-gettext \ --with-iconv \ --enable-mbstring=all \ --enable-mbregex \ --with-ftp \ --with-mysql \ --with-mcrypt=/usr \ --with-gd --with-png-dir=/usr/lib --with-jpeg-dir=/usr/lib \ --with-imap=/usr --with-kerberos=/usr --with-imap-ssl \ --with-oci8=/home/oracle/product/11.2.0/db_home1 \ --with-pdo-oci=/home/oracle/product/11.2.0/db_home1 Error: php: threads.c:321: krb5int_key_register: Assertion `keynum >= 0 && keynum < K5_KEY_MAX' failed. Actual result: -- Generating phar.php php: threads.c:321: krb5int_key_register: Assertion `keynum >= 0 && keynum < K5_KEY_MAX' failed. /bin/sh: line 1: 26736 Aborted ` if test -x "/home/www/www-config/resource/php-5.3.2/sapi/cli/php"; then /home/www/www-config/resource/php-5.3.2/build/shtool echo -n -- "/home/www/www-config/resource/php-5.3.2/sapi/cli/php -n"; if test "x" != "x"; then /home/www/www-config/resource/php-5.3.2/build/shtool echo -n -- " -d extension_dir=/home/www/www-config/resource/php-5.3.2/modules"; for i in bz2 zlib phar; do if test -f "/home/www/www-config/resource/php-5.3.2/modules/$i.la"; then . /home/www/www-config/resource/php-5.3.2/modules/$i.la; /home/www/www-config/resource/php-5.3.2/build/shtool echo -n -- " -d extension=$dlname"; fi; done; fi; else /home/www/www-config/resource/php-5.3.2/build/shtool echo -n -- "/home/www/www-config/resource/php-5.3.2/sapi/cli/php"; fi;` -d 'open_basedir=' -d 'output_buffering=0' -d 'memory_limit=-1' -d phar.readonly=0 -d 'safe_mode=0' /home/www/www-config/resource/php-5.3.2/ext/phar/build_precommand.php > ext/phar/phar.php make: *** [ext/phar/phar.php] Error 134 -- Edit this bug report at http://bugs.php.net/bug.php?id=51625&edit=1
Bug #51605 [Opn]: Mysqli - zombie links
Edit report at http://bugs.php.net/bug.php?id=51605&edit=1
ID: 51605
User updated by: bastard dot internets at gmail dot com
Reported by: bastard dot internets at gmail dot com
Summary: Mysqli - zombie links
Status: Open
Type: Bug
Package: MySQLi related
Operating System: vistax64
PHP Version: 5.3.2
New Comment:
Just to clarify - this is a closed server and db dev environment, and
I'm the only one running the above script or connecting to the Mysql
server. The 'too many links' PHP error would be expected if multiple
users were hitting the page at the exact same time. But not expected if
it's just me hitting refresh every once in a while.
Previous Comments:
[2010-04-19 21:45:14] bastard dot internets at gmail dot com
Correction on what software I'm using. I'm using these packages...
mysql-noinstall-5.1.45-winx64.zip (via mysql.com)
php-5.3.2-Win32-VC6-x86.zip (via php.net)
httpd-2.2.15-win32-x86-openssl-0.9.8m-r2.msi (via apache.org)
[2010-04-19 21:27:58] bastard dot internets at gmail dot com
Description:
Mysqli generated links appear to be persistent regardless of settings as
long as the PHP process (or Apache server process if PHP is loaded as a
module as in my case) is running. Any new connections just add to the
total link count, and neither closing or unsetting the link nor garbage
collection has any effect on removing them. Restarting mysqld has no
effect.
I'm using Vista x64, Apache 2.2, PHP5.3.2 as a module (thread-safe
download), and Mysql 5.1.45.
The below code produces no Mysql error, but after the second page
reload, PHP generates a 'Too many open links (1)' error from that point
on until the PHP server process is restarted. Mysql shows no connection
attempts on its end. No further db links can be established because of
mysqli.max_links being reached. The only way to solve this that I've
found so far is to set mysqli.max_links=-1 and just ignore the
ever-growing number of zombie links. Either that or restart the Apache
server every few seconds.
Also of note, no matter how high max_links is set and the script is ran,
get_connection_stats() will only show 1 active_connections, 0
active_persistent_connections, 0 connection_reused, 0 reconnect, 0
*_close.
Also, when using mysqli::real_connect method after mysqli_init(), it
establishes 1 active_persistent_connections according to
get_connection_stats() even though I have mysqli.allow_persistent=Off,
where as mysqli::__construct does not.
Test script:
---
php.ini...
mysqli.max_links = 1
mysqli.allow_persistent = Off
mysqli.max_persistent = 0
mysqli.reconnect = Off
my.ini...
max_connections=1
max_user_connections=1
connect_timeout=10
// just hit browser refresh once or twice
options(MYSQLI_OPT_CONNECT_TIMEOUT, 5);
$mysqli->real_connect($m_host, $m_user, $m_pass, $m_db);
echo $mysqli->error."";
var_dump($mysqli->get_connection_stats());
mysqli_close($mysqli);
die("finished");
?>
Expected result:
The above code should never generate a PHP error. Link in PHP memory
should actually be deleted either on close() or on script end.
If this behavior is intended for another purpose, in order to free up
memory and available connection/link slots in PHP, can a function or
setting be added or tweaked to actually delete the link from memory
either on demand or after some user specified time limit, or
automatically on script end? Or is there another method of handling
this already? Should there be a mysql(i).connect_timeout setting in
php.ini? Is mysqli::real_connect disobeying
mysqli.allow_persistent=Off?
Actual result:
--
[19-Apr-2010 12:56:58] PHP Warning: mysqli::mysqli(): Too many open
links (1) in D:\Server\Scripts\mysql_benchmarks.php on line 15
[19-Apr-2010 12:56:58] PHP Warning: main(): Couldn't fetch mysqli in
D:\Server\Scripts\mysql_benchmarks.php on line 16
[19-Apr-2010 12:56:58] PHP Warning: mysqli::get_connection_stats():
Couldn't fetch mysqli in D:\Server\Scripts\mysql_benchmarks.php on line
17
--
Edit this bug report at http://bugs.php.net/bug.php?id=51605&edit=1
Bug #51601 [Opn->Fbk]: Segmentation fault when using the 2-argument form of mysql_fetch_array
Edit report at http://bugs.php.net/bug.php?id=51601&edit=1
ID: 51601
Updated by: fel...@php.net
Reported by: pcarter at jhu dot edu
Summary: Segmentation fault when using the 2-argument form of
mysql_fetch_array
-Status: Open
+Status: Feedback
Type: Bug
Package: MySQL related
Operating System: FreeBSD 6.2-RELEASE
PHP Version: 5.3.2
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2010-04-19 17:04:44] pcarter at jhu dot edu
I missed on the package dropdown when submitting the bug. This belongs
with the MySQL package, not the MSSQL package.
[2010-04-19 17:03:06] pcarter at jhu dot edu
Description:
When using the two-argument form of mysql_fetch_array PHP experiences a
segmentation fault in zend_fetch_resource, attempting to dereference a
null pointer. (specifically *passed_id is ((* zval)(0x0)) when
performing the IS_RESOURCE check). This happens regardless of which of
the three MYSQL_{BOTH|ASSOC|NUM} constants are used as the second
argument (the given script uses MYSQL_BOTH). This problem does not
occur when using the single argument form of mysql_fetch_array, and it
does not occur when using the mysql_fetch_assoc() or mysql_fetch_row()
functions.
Test environment is FreeSBD 6.2-RELEASE on amd64, with the MySQL 5.0
client library installed.
Test script:
---
Expected result:
The script should print an array (numerically and associatively indexed)
of the tables in the database "test".
Actual result:
--
Segmentation fault as noted above. Backtrace:
Backtrace:
#0 0x00638ed3 in zend_fetch_resource (passed_id=0x7fffce30,
default_id=-1, resource_type_name=0x72fa51 "MySQL result",
found_resource_type=0x0, num_resource_types=1)
at /usr/local/src/php-5.3.2/Zend/zend_list.c:127
#1 0x004d76a6 in php_mysql_fetch_hash (ht=2,
return_value=0x9240a0, return_value_ptr=0x638ddf, this_ptr=0x0,
return_value_used=1, result_type=3, expected_args=2, into_object=0)
at /usr/local/src/php-5.3.2/ext/mysql/php_mysql.c:1944
#2 0x004d7c2b in zif_mysql_fetch_array (ht=-12752,
return_value=0x, return_value_ptr=0x638ddf, this_ptr=0x0,
return_value_used=1) at
/usr/local/src/php-5.3.2/ext/mysql/php_mysql.c:2105
#3 0x0064e192 in zend_do_fcall_common_helper_SPEC
(execute_data=0xb45040) at zend_vm_execute.h:313
#4 0x0064d5b9 in execute (op_array=0x9248c8) at
zend_vm_execute.h:104
#5 0x0062b765 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/local/src/php-5.3.2/Zend/zend.c:1194
#6 0x005d955b in php_execute_script
(primary_file=0x7fffeb00) at
/usr/local/src/php-5.3.2/main/main.c:2260
#7 0x006b2bca in main (argc=2, argv=0x7fffec00) at
/usr/local/src/php-5.3.2/sapi/cli/php_cli.c:1192
--
Edit this bug report at http://bugs.php.net/bug.php?id=51601&edit=1
Bug #51594 [Opn->Fbk]: open_basedir reports fatal error within allowed path
Edit report at http://bugs.php.net/bug.php?id=51594&edit=1 ID: 51594 Updated by: fel...@php.net Reported by: daniel at produktion203 dot se Summary: open_basedir reports fatal error within allowed path -Status: Open +Status: Feedback Type: Bug Package: Safe Mode/open_basedir Operating System: FreeBSD 8.0-RELEASE-p2 PHP Version: 5.3.2 New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2010-04-19 00:01:37] daniel at produktion203 dot se Description: There seems to be some problem with open_basedir in php 5.3.2 for freebsd, i used the 5.2 branch before and the exact same config worked fine then. open_basedir reports failure eventhough im within the allowed paths Include paths in php.ini: include_path = ".:/usr/local/share/pear:/usr/local/lib/php/include" Testhost in apache: DocumentRoot "/home/customers/produktion203/testin.se" ServerName testin.se php_admin_value open_basedir /home/customers/produktion203/testin.se:/usr/local/share/pear:/usr/local/lib/php/include:/var/tmp Test script: --- http://bugs.php.net/bug.php?id=51594&edit=1
Bug #51576 [Opn]: compile failure on zend_float.c
Edit report at http://bugs.php.net/bug.php?id=51576&edit=1 ID: 51576 Updated by: ka...@php.net Reported by: i2r at pacbell dot net Summary: compile failure on zend_float.c Status: Open Type: Bug Package: Compile Failure Operating System: AIX 5.3 PHP Version: 5.3.2 -Assigned To: +Assigned To: cseiler New Comment: Christian, here is some feedback for the rounding patch ;-) Previous Comments: [2010-04-16 23:02:21] i2r at pacbell dot net version of zend_float.c /* $Id: zend_float.c 293155 2010-01-05 20:46:53Z sebastian $ */ [2010-04-16 21:39:59] i2r at pacbell dot net Description: Compiler IBM visual age ver 6 ".../php-5.3.2/Zend/zend_float.c", line 33.9: 1506-579 (W) The __asm directive is ignored. ".../php-5.3.2/Zend/zend_float.c", line 34.9: 1506-579 (W) The __asm directive is ignored. ".../php-5.3.2/Zend/zend_float.c", line 44.10: 1506-276 (S) Syntax error: possible missing 'while'? ".../php-5.3.2/Zend/zend_float.c", line 48.17: 1506-579 (W) The __asm directive is ignored. ".../php-5.3.2/Zend/zend_float.c", line 51.9: 1506-276 (S) Syntax error: possible missing 'while'? ".../php-5.3.2/Zend/zend_float.c", line 55.1: 1506-276 (S) Syntax error: possible missing 'while'? ".../php-5.3.2/Zend/zend_float.c", line 62.9: 1506-579 (W) The __asm directive is ignored. ".../php-5.3.2/Zend/zend_float.c", line 64.10: 1506-204 (S) Unexpected end of file. make: *** [Zend/zend_float.lo] Error 1 -- Edit this bug report at http://bugs.php.net/bug.php?id=51576&edit=1
Bug #51479 [Opn->Bgs]: property_exists now wrong
Edit report at http://bugs.php.net/bug.php?id=51479&edit=1
ID: 51479
Updated by: fel...@php.net
Reported by: ian at ianhobson dot co dot uk
Summary: property_exists now wrong
-Status: Open
+Status: Bogus
Type: Bug
Package: Class/Object related
Operating System: Windows
PHP Version: 5.3.2
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:
[2010-04-09 07:44:38] abca_b_cabcom at hotmail dot com
Hi ivan, i think you could use the reflection api to handle it
http://www.php.net/manual/en/reflectionproperty.isprivate.php
[2010-04-05 15:26:42] ian at ianhobson dot co dot uk
Description:
Now that property_exists returns true for all private properties, there
is no way (I know) to test that a property is private before writing to
it and causing a fatal error.
The previous behaviour was wrong - private properties that are in scope
should return true - but the new code is worse.
See Bug #50810: property_exists does not work for private
I think property_exists should return true for writable properties...
which implies a scope...
if the user coded $this then the scope is the current scope.
If the use gives a class name, then the scope is that class.
I have not managed to re-code the routine below to work in 5.3.0 (let
alone both 5.3.? and 5.2.?).
Test script:
---
public function setField($fld, $value) {
// set the fld to the value
if (property_exists($this,$fld)) {
$this->$fld = $value; // handles public and protected fields
return;
}
$this->setMapped($fld,$value); // for private vars.
}
Create a class with the above function. Create a sub-class with a
private variable. Call it on the sub-class with fldname and value.
In 5.3.0 this crashes with a fatal error.
In 5.2.9 it calls setMapped.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51479&edit=1
Bug #51490 [Opn->Asn]: html_entity_encode() doesn't work with windows-1251
Edit report at http://bugs.php.net/bug.php?id=51490&edit=1 ID: 51490 Updated by: fel...@php.net Reported by: sandel at ukr dot net Summary: html_entity_encode() doesn't work with windows-1251 -Status: Open +Status: Assigned Type: Bug Package: *Spelling functions Operating System: linux SuSE 11.2 PHP Version: 5.3.2 -Assigned To: +Assigned To: moriyoshi Previous Comments: [2010-04-06 23:20:51] sandel at ukr dot net Description: html_entity_encode() doesn't work with windows-1251 with php 5.3.2 BUT It works with latest PHP 5.2.X Test script: --- -- Edit this bug report at http://bugs.php.net/bug.php?id=51490&edit=1
Bug #51610 [Com]: 1 second+ needed for OCI8 versus PDO/oci to open/close connection and exit
Edit report at http://bugs.php.net/bug.php?id=51610&edit=1 ID: 51610 Comment by: marioroy at verizon dot net Reported by: marioroy at verizon dot net Summary: 1 second+ needed for OCI8 versus PDO/oci to open/close connection and exit Status: Wont fix Type: Bug Package: OCI8 related Operating System: Linux & Snow Leopard PHP Version: 5.3SVN-2010-04-20 (snap) Assigned To: sixd New Comment: Thank you for the feedback. Previous Comments: [2010-04-21 18:31:34] s...@php.net This is expected. There is a shutdown cost at process termination from closing a timer thread needed by the connection rearchitecture of OCI8 1.3. Most deployments either do not start and stop PHP processes frequently, or are not sensitive to the time between completing the work of the script and the termination of the process. It's possible that PDO_OCI may be changed in future and might get the same behaviour. [2010-04-20 05:24:44] marioroy at verizon dot net Description: Is this normal to see the native OCI8 1.3.5 or later requiring additional time to run code snippet shown below when accessing Oracle 10.2.0.4. I'm seeing this at work as well (SUSE Linux). Therefore, I have stayed with OCI8 1.2.5 for the moment. Notice how the time is the same when using the PDO/OCI interface. Test script: --- # Native OCI8 Performance: # # PHP 5.2.14 201004191430, OCI8 1.2.5: ~ 0.15 seconds ;this is nice # # PHP 5.3.3 201004191430, OCI8 1.2.5: ~ 0.25 seconds ;takes 0.1 extra here # PHP 5.3.3 201004191430, OCI8 1.3.5: ~ 1.20 seconds ;slowness begins when # PHP 5.3.3 201004191430, OCI8 1.4.1: ~ 1.20 seconds ;script exits for 1.3.5+ # PHP 5.3.3 201004191430, OCI8 1.4.2: ~ 1.20 seconds # PDO/OCI Performance: # # PHP 5.2.14 201004191430, OCI8 1.2.5: ~ 0.15 seconds ;very fast # # PHP 5.3.3 201004191430, OCI8 1.2.5: ~ 0.15 seconds ;same as PHP 5.2.14 :) # PHP 5.3.3 201004191430, OCI8 1.3.5: ~ 0.15 seconds ;very happy to see this # PHP 5.3.3 201004191430, OCI8 1.4.1: ~ 0.15 seconds ;with 1.3.5+ # PHP 5.3.3 201004191430, OCI8 1.4.2: ~ 0.15 seconds getMessage(), E_USER_ERROR); } $conn = NULL; exit; ?> Expected result: I'm hoping that PHP 5.3.2+ with OCI8 1.4.1+ can perform as fast as PHP 5.2.13 with OCI8 1.2.5 when using the native driver. This is why I have stayed with 1.2.5 at work. It wasn't until tonight that I saw the times the same via the PDO interface. That made my day. Actual result: -- The native OCI8 1.3.5+ requires extra time to open/close and exit. The time delta is 1 second for such a small code snippet. -- Edit this bug report at http://bugs.php.net/bug.php?id=51610&edit=1
Bug #51627 [Opn->Csd]: script path not correctly evaluated
Edit report at http://bugs.php.net/bug.php?id=51627&edit=1 ID: 51627 Updated by: fel...@php.net Reported by: russell dot tempero at rightnow dot com Summary: script path not correctly evaluated -Status: Open +Status: Closed Type: Bug Package: CGI related Operating System: Linux PHP Version: 5.3.2 -Assigned To: +Assigned To: felipe New Comment: This bug has been fixed in SVN. 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. Thanks for the patch! Previous Comments: [2010-04-22 00:22:33] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revision&revision=298277 Log: - Fixed bug #51627 (script path not correctly evaluated) Patch by: russell dot tempero at rightnow dot com [2010-04-21 23:28:42] russell dot tempero at rightnow dot com Description: Using PHP as CGI (not FastCGI). Pertinent php.ini values: include_path="/home/httpd/cgi-bin/rcttrunk1.cfg/scripts:." doc_root="/home/httpd/cgi-bin/rcttrunk1.cfg/scripts" Path to file: /home/httpd/cgi-bin/rcttrunk1.cfg/scripts/admin/launch.php When I hit the following URL, I get a "file not found" error: http:///cgi-bin/rcttrunk1.cfg/php/admin/launch.php Please see my patch below to fix the issue. The problem is that length is evaluating to 1, rather than string length, because of operator precedence. The solution is to wrap (length = strlen(...)) in its own set of parentheses. Test script: --- Happens for any script. Expected result: The page loads. Actual result: -- "File not found." Error -- Edit this bug report at http://bugs.php.net/bug.php?id=51627&edit=1
[PHP-BUG] Bug #51627 [NEW]: script path not correctly evaluated
From: Operating system: Linux PHP version: 5.3.2 Package: CGI related Bug Type: Bug Bug description:script path not correctly evaluated Description: Using PHP as CGI (not FastCGI). Pertinent php.ini values: include_path="/home/httpd/cgi-bin/rcttrunk1.cfg/scripts:." doc_root="/home/httpd/cgi-bin/rcttrunk1.cfg/scripts" Path to file: /home/httpd/cgi-bin/rcttrunk1.cfg/scripts/admin/launch.php When I hit the following URL, I get a "file not found" error: http:///cgi-bin/rcttrunk1.cfg/php/admin/launch.php Please see my patch below to fix the issue. The problem is that length is evaluating to 1, rather than string length, because of operator precedence. The solution is to wrap (length = strlen(...)) in its own set of parentheses. Test script: --- Happens for any script. Expected result: The page loads. Actual result: -- "File not found." Error -- Edit bug report at http://bugs.php.net/bug.php?id=51627&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51627&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51627&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51627&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51627&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51627&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51627&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51627&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51627&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51627&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51627&r=support Expected behavior: http://bugs.php.net/fix.php?id=51627&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51627&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51627&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51627&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51627&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51627&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51627&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51627&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51627&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51627&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51627&r=mysqlcfg
Bug #51612 [Opn->Bgs]: array_push($_SESSION) does not work
Edit report at http://bugs.php.net/bug.php?id=51612&edit=1 ID: 51612 Updated by: paj...@php.net Reported by: php dot workspace at gmail dot com Summary: array_push($_SESSION) does not work -Status: Open +Status: Bogus Type: Bug Package: Arrays related Operating System: Windows PHP Version: 5.3.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. Previous Comments: [2010-04-20 10:10:49] php dot workspace at gmail dot com Description: Test script: --- Notice: Unknown: Skipping numeric key 0 in Unknown on line 0 Expected result: just push that "foo" into _SESSION -- Edit this bug report at http://bugs.php.net/bug.php?id=51612&edit=1
Bug #51575 [Opn]: S modifier causes preg_match to behave incorrectly
Edit report at http://bugs.php.net/bug.php?id=51575&edit=1 ID: 51575 Updated by: fel...@php.net Reported by: pretender at design dot ru Summary: S modifier causes preg_match to behave incorrectly Status: Open Type:Bug Package: PCRE related PHP Version: 5.2.13 New Comment: This is a probable PCRE lib bug. I've reported this issue to a open recent bug report: http://bugs.exim.org/show_bug.cgi?id=976 Previous Comments: [2010-04-16 19:29:05] pretender at design dot ru Description: With some UTF-8 letters of Cyrillic block preg_match behaves incorrectly with S modifier. Test script: --- Expected result: "passed" Actual result: -- "failed" -- Edit this bug report at http://bugs.php.net/bug.php?id=51575&edit=1
Bug #51610 [Opn->Wfx]: 1 second+ needed for OCI8 versus PDO/oci to open/close connection and exit
Edit report at http://bugs.php.net/bug.php?id=51610&edit=1 ID: 51610 Updated by: s...@php.net Reported by: marioroy at verizon dot net Summary: 1 second+ needed for OCI8 versus PDO/oci to open/close connection and exit -Status: Open +Status: Wont fix Type: Bug Package: OCI8 related Operating System: Linux & Snow Leopard PHP Version: 5.3SVN-2010-04-20 (snap) -Assigned To: +Assigned To: sixd New Comment: This is expected. There is a shutdown cost at process termination from closing a timer thread needed by the connection rearchitecture of OCI8 1.3. Most deployments either do not start and stop PHP processes frequently, or are not sensitive to the time between completing the work of the script and the termination of the process. It's possible that PDO_OCI may be changed in future and might get the same behaviour. Previous Comments: [2010-04-20 05:24:44] marioroy at verizon dot net Description: Is this normal to see the native OCI8 1.3.5 or later requiring additional time to run code snippet shown below when accessing Oracle 10.2.0.4. I'm seeing this at work as well (SUSE Linux). Therefore, I have stayed with OCI8 1.2.5 for the moment. Notice how the time is the same when using the PDO/OCI interface. Test script: --- # Native OCI8 Performance: # # PHP 5.2.14 201004191430, OCI8 1.2.5: ~ 0.15 seconds ;this is nice # # PHP 5.3.3 201004191430, OCI8 1.2.5: ~ 0.25 seconds ;takes 0.1 extra here # PHP 5.3.3 201004191430, OCI8 1.3.5: ~ 1.20 seconds ;slowness begins when # PHP 5.3.3 201004191430, OCI8 1.4.1: ~ 1.20 seconds ;script exits for 1.3.5+ # PHP 5.3.3 201004191430, OCI8 1.4.2: ~ 1.20 seconds # PDO/OCI Performance: # # PHP 5.2.14 201004191430, OCI8 1.2.5: ~ 0.15 seconds ;very fast # # PHP 5.3.3 201004191430, OCI8 1.2.5: ~ 0.15 seconds ;same as PHP 5.2.14 :) # PHP 5.3.3 201004191430, OCI8 1.3.5: ~ 0.15 seconds ;very happy to see this # PHP 5.3.3 201004191430, OCI8 1.4.1: ~ 0.15 seconds ;with 1.3.5+ # PHP 5.3.3 201004191430, OCI8 1.4.2: ~ 0.15 seconds getMessage(), E_USER_ERROR); } $conn = NULL; exit; ?> Expected result: I'm hoping that PHP 5.3.2+ with OCI8 1.4.1+ can perform as fast as PHP 5.2.13 with OCI8 1.2.5 when using the native driver. This is why I have stayed with 1.2.5 at work. It wasn't until tonight that I saw the times the same via the PDO interface. That made my day. Actual result: -- The native OCI8 1.3.5+ requires extra time to open/close and exit. The time delta is 1 second for such a small code snippet. -- Edit this bug report at http://bugs.php.net/bug.php?id=51610&edit=1
Bug #51624 [Opn->Fbk]: Gallery2 causing segfault when trying to update.
Edit report at http://bugs.php.net/bug.php?id=51624&edit=1
ID: 51624
Updated by: fel...@php.net
Reported by: zulcss at ubuntu dot com
Summary: Gallery2 causing segfault when trying to update.
-Status: Open
+Status: Feedback
Type: Bug
Package: Reproducible crash
Operating System: Ubuntu/Linux
PHP Version: 5.3.2
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2010-04-21 14:10:18] zulcss at ubuntu dot com
Description:
Hi,
This bug was recently reported on launchpad at
http://bugs.launchpad.net/bugs/567043. I have included the gdb backtrace
with this bug report.
Regards
chuck
Expected result:
Not to crash.
Actual result:
--
#0 0x7fe478493d02 in memcpy () from /lib/libc.so.6
No symbol table info available.
#1 0x00677ff8 in _estrndup (s=0x4d0050 , length=90) at
/usr/include/bits/string3.h:52
No locals.
#2 0x0069459b in _zval_copy_ctor_func (zvalue=0x1f84ca8) at
/build/buildd/php5-5.3.2/Zend/zend_variables.c:126
tmp = 0x1ecb470
original_ht = 0x1ecb470
#3 0x7fe4752b0f68 in zif_mysqli_options (ht=33049848,
return_value=0x1f84c58, return_value_ptr=0x5a, this_ptr=0x4d0050,
return_value_used=17) at
/build/buildd/php5-5.3.2/Zend/zend_variables.h:45
mysql_link = 0x1f84ca8
mysql_value = 0x5
mysql_option = 33049648
l_value = 0
expected_type = 33049848
#4 0x006e598a in zend_do_fcall_common_helper_SPEC
(execute_data=0x142a390) at
/build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:313
opline = 0x15c7698
should_change_scope = 0 '\000'
#5 0x006bcc70 in execute (op_array=0x11d7080) at
/build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:104
ret = 33049848
execute_data = 0x142a390
nested = 0 '\000'
original_in_execution = 1 '\001'
#6 0x0068ab94 in zend_call_function (fci=0x7fff6ab02fd0,
fci_cache=0x141f840) at
/build/buildd/php5-5.3.2/Zend/zend_execute_API.c:947
i = 17
original_return_value = 0x141f6f0
calling_symbol_table = 0x1938398
original_op_array = 0x19cf630
original_opline_ptr =
current_scope = 0x1db96c0
current_called_scope = 0x1938398
calling_scope = 0x0
called_scope = 0x141f6f0
current_this = 0x0
execute_data = {opline = 0x0, function_state = {function = 0x0,
arguments = 0x1949408}, fbc = 0x141fe68, called_scope = 0x0, op_array =
0x0, object = 0x0, Ts = 0x1956490, CVs = 0x141f938, symbol_table =
0x141f8d8,
prev_execute_data = 0x0, old_error_reporting = 0x141f840,
nested = 0 '\000', original_return_value = 0x1, current_scope =
0x141e228, current_called_scope = 0x1938398, current_this = 0x1938398,
current_object = 0x1db92d0,
call_opline = 0x0}
#7 0x005cd107 in zif_call_user_func_array (ht=33049848,
return_value=0x1db8eb8, return_value_ptr=0x5a, this_ptr=0x1,
return_value_used=17) at
/build/buildd/php5-5.3.2/ext/standard/basic_functions.c:4782
params = 0x0
retval_ptr = 0x141f840
fci = {size = 6082823, function_table = 0x48, function_name =
0x1927c28, symbol_table = 0x1a58120, retval_ptr_ptr = 0x0, param_count =
1789931600, params = 0x3, object_ptr = 0x1da2868, no_separation = 144
'\220'}
fci_cache = {initialized = 176 '\260', function_handler = 0x1,
calling_scope = 0x1949408, called_scope = 0x1927bf8, object_ptr =
0x1927bf8}
#8 0x006e598a in zend_do_fcall_common_helper_SPEC
(execute_data=0x141f840) at
/build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:313
opline = 0x19d4418
should_change_scope = 0 '\000'
#9 0x006bcc70 in execute (op_array=0x19cf630) at
/build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:104
ret = 33049848
execute_data = 0x141f840
nested = 0 '\000'
original_in_execution = 0 '\000'
#10 0x0069499d in zend_execute_scripts (type=0,
retval=0x7fff6ab03210, file_count=3) at
/build/buildd/php5-5.3.2/Zend/zend.c:1266
files = 0x7fff6ab031e8
i = 1
file_handle = 0x7fff6ab05810
orig_op_array = 0x0
orig_retval_ptr_ptr = 0xd8fd30
#11 0x00640608 in php_execute_script (primary_file=0x1888) at
/build/buildd/php5-5.3.2/main/main.c:2288
__orig_bailout = 0x0
__bailout = {{__jmpbuf = {0, 0, 0, 0, 2, 0, 6040, 0},
__mask_was_saved = 0, __saved_mask = {__val = {0, 0, 1, 0, 27843312, 0,
12, 0, 11235408, 0, 1789928576, 32767, 24063528, 0, 0, 0
prepend_file_p = 0x0
append_file_p = 0x0
prepend_file = {type = 1789930876, filename = 0x7fff6ab027b0
"\367\002\033\003\060", opened_path = 0x0,
Bug #51570 [Opn->Fbk]: is_subclass_of fails to autoload the classes
Edit report at http://bugs.php.net/bug.php?id=51570&edit=1
ID: 51570
Updated by: fel...@php.net
Reported by: ealexs at gmail dot com
Summary: is_subclass_of fails to autoload the classes
-Status: Open
+Status: Feedback
Type: Bug
Package: Reproducible crash
Operating System: Debian
PHP Version: 5.2.13
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
Previous Comments:
[2010-04-16 15:56:25] ealexs at gmail dot com
Description:
is_subclass_of fails to autoload the classes causing PHP do die and
apache returns an empty page. NO error is triggered ! It was very hard
to find the cause
My php config it's here:
http://alex.softdev.ro/info.php
Failing function:
function ClassIsA($object_class, $class)
{
if ($object_class == $class)
return true;
return (is_subclass_of($object_class, $class));
}
If changed it works:
function ClassIsA($object_class, $class)
{
// use this to force the load of the classes
if (!class_exists($object_class))
throw new Exception("Class $object_class not found");
// use this to force the load of the classes
if (!class_exists($class))
throw new Exception("Class $class not found");
if ($object_class == $class)
return true;
return (is_subclass_of($object_class, $class));
}
looks like calling class_exists calls autoload and works fine
Thanks,
Alex
Test script:
---
Failing function:
function ClassIsA($object_class, $class)
{
if ($object_class == $class)
return true;
return (is_subclass_of($object_class, $class));
}
If changed it works:
function ClassIsA($object_class, $class)
{
// use this to force the load of the classes
if (!class_exists($object_class))
throw new Exception("Class $object_class not found");
// use this to force the load of the classes
if (!class_exists($class))
throw new Exception("Class $class not found");
if ($object_class == $class)
return true;
return (is_subclass_of($object_class, $class));
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=51570&edit=1
Bug #51626 [Opn->Bgs]: Strange fputcsv reaction
Edit report at http://bugs.php.net/bug.php?id=51626&edit=1
ID: 51626
Updated by: fel...@php.net
Reported by: marhei at mac dot com
Summary: Strange fputcsv reaction
-Status: Open
+Status: Bogus
Type: Bug
Package: Filesystem function related
Operating System: Ubuntu 9.10
PHP Version: 5.3.2
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
Read about the 'mode' parameter:
http://docs.php.net/manual/en/function.fopen.php
Previous Comments:
[2010-04-21 15:45:42] marhei at mac dot com
Description:
$handle = open('test.csv','r+');
fputcsv($handle,$content);
overwrite the last already in the file standing line.
If i write this, the last line is not overwritten:
$handle = open('test.csv','r+');
while($current = fgetcsv(handle)) {
//Nothing
}
fputcsv($handle,$content);
Test script:
---
//Does not work
$handle = open('test.csv','r+');
fputcsv($handle,$content);
//Work
$handle = open('test.csv','r+');
while($current = fgetcsv(handle)) {
//Nothing
}
fputcsv($handle,$content);
--
Edit this bug report at http://bugs.php.net/bug.php?id=51626&edit=1
Bug #51562 [Opn->Csd]: query timeout in mssql can not be changed per query
Edit report at http://bugs.php.net/bug.php?id=51562&edit=1
ID: 51562
Updated by: fel...@php.net
Reported by: ejsmont dot artur at gmail dot com
Summary: query timeout in mssql can not be changed per query
-Status: Open
+Status: Closed
Type: Bug
Package: MSSQL related
Operating System: linux debian lenny
PHP Version: 5.2.13
-Assigned To:
+Assigned To: felipe
New Comment:
This bug has been fixed in SVN.
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:
[2010-04-21 16:19:29] fel...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revision&revision=298255
Log: - Fixed bug #51562 (query timeout in mssql can not be changed per
query)
Patch by: ejsmont dot artur at gmail dot com
[2010-04-15 15:57:20] ejsmont dot artur at gmail dot com
Description:
im not sure if its a bug or missing functionality but i cant set query
timeout per query. I want to be able to do ini_set('mssql.timeout', 6);
before query to set its timeout to 6 seconds and then
ini_set('mssql.timeout', 20); to set 20s timeout for following query.
This seems to be possible with patch i attach just one line needs to be
added. but im not sure if this would not break anything (seems to work
for me on lenny).
Test script:
---
// connect
$connection = mssql_connect($dbhost, $dbuser, $dbpass);
mssql_select_db($dbname, $connection);
// does not have affect if called after connect
ini_set('default_socket_timeout', 1);
ini_set('mssql.connect_timeout',1);
ini_set('mssql.timeout',3);
// call sproc with results and no delay
$start = microtime(true);
$rid = mssql_query("exec timeout_test 0, 0, 'Y';");
while ($rec = mssql_fetch_assoc($rid)) {
$row[] = $rec;
}
echo "=".print_r( $row, true )."= in
".(microtime(true)-$start)." with ".mssql_get_last_message()."\n";
Expected result:
i think it would be good if you could set query timeout at any time and
it would affect the following queries (until you change the timeout
value)
Actual result:
--
timeout set after connection is established does not have effect
--
Edit this bug report at http://bugs.php.net/bug.php?id=51562&edit=1
Bug #51604 [Opn]: newline in end of header is shown in start of message
Edit report at http://bugs.php.net/bug.php?id=51604&edit=1 ID: 51604 Updated by: degeb...@php.net Reported by: pavol at klacansky dot com Summary: newline in end of header is shown in start of message Status: Open Type: Bug Package: Mail related Operating System: Ubuntu PHP Version: 5.3.2 New Comment: The attached patch will fix this issue. I don't have php-src karma, so I can't commit it myself. Previous Comments: [2010-04-21 16:00:42] degeb...@php.net The following patch has been added/updated: Patch Name: php_bug51604.diff Revision: 1271858442 URL: http://bugs.php.net/patch-display.php?bug=51604&patch=php_bug51604.diff&revision=1271858442 [2010-04-19 20:50:47] pavol at klacansky dot com Actual result: -- \nHallo [2010-04-19 20:49:55] pavol at klacansky dot com Description: if I have a newline (\n) at the end of last header, it will show to start of message of mail Test script: --- Expected result: Hallo Actual result: -- Hallo -- Edit this bug report at http://bugs.php.net/bug.php?id=51604&edit=1
Bug #51604 [PATCH]: newline in end of header is shown in start of message
Edit report at http://bugs.php.net/bug.php?id=51604&edit=1 ID: 51604 Patch added by: degeb...@php.net Reported by: pavol at klacansky dot com Summary: newline in end of header is shown in start of message Status: Open Type: Bug Package: Mail related Operating System: Ubuntu PHP Version: 5.3.2 New Comment: The following patch has been added/updated: Patch Name: php_bug51604.diff Revision: 1271858442 URL: http://bugs.php.net/patch-display.php?bug=51604&patch=php_bug51604.diff&revision=1271858442 Previous Comments: [2010-04-19 20:50:47] pavol at klacansky dot com Actual result: -- \nHallo [2010-04-19 20:49:55] pavol at klacansky dot com Description: if I have a newline (\n) at the end of last header, it will show to start of message of mail Test script: --- Expected result: Hallo Actual result: -- Hallo -- Edit this bug report at http://bugs.php.net/bug.php?id=51604&edit=1
Bug #22624 [Com]: Mulitple PHP processes launched using 100% CPU
Edit report at http://bugs.php.net/bug.php?id=22624&edit=1 ID: 22624 Comment by: gggsty at gmail dot com Reported by: webmaster at enterzone dot com Summary: Mulitple PHP processes launched using 100% CPU Status: No Feedback Type: Bug Package: Performance problem Operating System: WinNT4 PHP Version: 4.3.1 New Comment: thank u for this page httl://ragbarg.com Previous Comments: [2009-01-05 17:41:33] oedipean at gmail dot com http://gheymatha.com http://gheymatha.com/forum.php [2008-11-28 10:43:23] fhggfj at hg dot fd http://www.forex.co.ir";>ÝÇÑÓ یÓÊ ÇیÑÇä فارکس ایران http://www.forex.co.ir";>http://www.forex.co.ir/forex.gif"; alt="ÝÇÑÓ یÓÊ ÇیÑÇä" width="32" height="32" border="0"> http://www.forex.co.ir";>http://www.forex.co.ir [2003-03-15 18:47:40] sni...@php.net 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. [2003-03-10 12:25:17] mag...@php.net 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. A reproduce script is needed, and if it is more then 10 lines, please put a link here to it. [2003-03-10 11:57:58] webmaster at enterzone dot com WinNT 4 SP6a, all of the latest patches (yea, yea I know). PHP 4.3.1 I am getting 1,2,4, or more process instances of PHP running using 100% CPU. Cannot narrow it down to bad programming code by users or a php.exe problem. Most PHP is running fine. I have a few PHP forums running. I cannot reproduce the problem, but it is increasing. Concerned that it may be a attack. This is now occurring 4 or more times a day. Only option is to kill the errant processes. Sometimes a reboot of the server is mandatory. After killing the processes, normal PHP code in our forums runs fine. There are not any consistent instances of PHP runing in the background unless this problem reoccurs. The PHP.INI is set as follows; max_execution_tim = 30; max_imput_time = 60; memory_limit = 8M . It has now effect on this problem, we have seen it run over 4 hours without a sign of stopping on its own. I don't have the memory usage noted, there is not any unusually high traffic across our network during the instance. Most dynamic pages fail, only static pages are served from IIS, due to the high CPU load. PHP request run, but very slowly as do all request during this time. -- Edit this bug report at http://bugs.php.net/bug.php?id=22624&edit=1
Bug #49503 [Com]: "failed to open semaphore file"
Edit report at http://bugs.php.net/bug.php?id=49503&edit=1 ID: 49503 Comment by: tsisaruk dot v at gmail dot com Reported by: mike at fuelsaver-mpg dot com Summary: "failed to open semaphore file" Status: Closed Type: Bug Package: Session related Operating System: Linux 2.6.9-023stab048.6-enterpr PHP Version: 5.2.11 New Comment: I added patch which fix trouble with creating semaphore file in / directory, if sessions.save_path is undefined. It behaviour now is like file session handle Previous Comments: [2009-10-08 17:57:56] mike at fuelsaver-mpg dot com Thank you. [2009-10-08 10:34:48] j...@php.net Thanks for digging this. I have absolutely no idea why I had added this warning there. Might have been either some debug code I put there while testing or simply copy'n'paste error gone wild.. :( I removed it now. And you can of course avoid the warning by setting the session.save_path properly. :) [2009-10-08 10:33:26] s...@php.net Automatic comment from SVN on behalf of jani Revision: http://svn.php.net/viewvc/?view=revision&revision=289338 Log: - Fixed bug #49503 (invalid warning for failed semaphore file creation) # I have no idea why I had added this. Might have been some debug code.. :( [2009-10-02 01:06:00] sriram dot natarajan at gmail dot com i am just curious - how does this affect writing session to memcached ? [2009-10-01 12:36:22] senker at gmail dot com It also disables writing sessions to memcached, so if you are using memcached, you have to stick to 5.2.9. Please escalate this to higher priority, it's unbelievable such important bug spans over two PHP versions already. 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/bug.php?id=49503 -- Edit this bug report at http://bugs.php.net/bug.php?id=49503&edit=1
[PHP-BUG] Bug #51626 [NEW]: Strange fputcsv reaction
From:
Operating system: Ubuntu 9.10
PHP version: 5.3.2
Package: Filesystem function related
Bug Type: Bug
Bug description:Strange fputcsv reaction
Description:
$handle = open('test.csv','r+');
fputcsv($handle,$content);
overwrite the last already in the file standing line.
If i write this, the last line is not overwritten:
$handle = open('test.csv','r+');
while($current = fgetcsv(handle)) {
//Nothing
}
fputcsv($handle,$content);
Test script:
---
//Does not work
$handle = open('test.csv','r+');
fputcsv($handle,$content);
//Work
$handle = open('test.csv','r+');
while($current = fgetcsv(handle)) {
//Nothing
}
fputcsv($handle,$content);
--
Edit bug report at http://bugs.php.net/bug.php?id=51626&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51626&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51626&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51626&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51626&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51626&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51626&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51626&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51626&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51626&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51626&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51626&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51626&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51626&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51626&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51626&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51626&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51626&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51626&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51626&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51626&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51626&r=mysqlcfg
[PHP-BUG] Bug #51625 [NEW]: php: threads.c:321: krb5int_key_register: Assertion `keynum >= 0 && keynum < K5
From: Operating system: Ubuntu 9.10 PHP version: 5.3.2 Package: Compile Failure Bug Type: Bug Bug description:php: threads.c:321: krb5int_key_register: Assertion `keynum >= 0 && keynum < K5 Description: Installed last Oracle 11gR2 database + oracle-instantclient11.2-basic-11.2.0.1.0-1.i386.rpm oracle-instantclient11.2-devel-11.2.0.1.0-1.i386.rpm I try also previous version of oracle-instantclient from 10gR2 - the result was ne same. Without "--with-oci8=/home/oracle/product/11.2.0/db_home1 --with-pdo-oci=/home/oracle/product/11.2.0/db_home1" options compilation is successfull! Compiling using "root" user with full access. ./configure \ --with-apxs2=$PREFIX/bin/apxs \ --with-openssl \ --with-bz2 \ --with-zlib=/usr/local/zlib \ --enable-sigchild \ --without-sqlite \ --without-pdo-sqlite \ --with-xml --with-dom \ --with-gettext \ --with-iconv \ --enable-mbstring=all \ --enable-mbregex \ --with-ftp \ --with-mysql \ --with-mcrypt=/usr \ --with-gd --with-png-dir=/usr/lib --with-jpeg-dir=/usr/lib \ --with-imap=/usr --with-kerberos=/usr --with-imap-ssl \ --with-oci8=/home/oracle/product/11.2.0/db_home1 \ --with-pdo-oci=/home/oracle/product/11.2.0/db_home1 Error: php: threads.c:321: krb5int_key_register: Assertion `keynum >= 0 && keynum < K5_KEY_MAX' failed. Actual result: -- Generating phar.php php: threads.c:321: krb5int_key_register: Assertion `keynum >= 0 && keynum < K5_KEY_MAX' failed. /bin/sh: line 1: 26736 Aborted ` if test -x "/home/www/www-config/resource/php-5.3.2/sapi/cli/php"; then /home/www/www-config/resource/php-5.3.2/build/shtool echo -n -- "/home/www/www-config/resource/php-5.3.2/sapi/cli/php -n"; if test "x" != "x"; then /home/www/www-config/resource/php-5.3.2/build/shtool echo -n -- " -d extension_dir=/home/www/www-config/resource/php-5.3.2/modules"; for i in bz2 zlib phar; do if test -f "/home/www/www-config/resource/php-5.3.2/modules/$i.la"; then . /home/www/www-config/resource/php-5.3.2/modules/$i.la; /home/www/www-config/resource/php-5.3.2/build/shtool echo -n -- " -d extension=$dlname"; fi; done; fi; else /home/www/www-config/resource/php-5.3.2/build/shtool echo -n -- "/home/www/www-config/resource/php-5.3.2/sapi/cli/php"; fi;` -d 'open_basedir=' -d 'output_buffering=0' -d 'memory_limit=-1' -d phar.readonly=0 -d 'safe_mode=0' /home/www/www-config/resource/php-5.3.2/ext/phar/build_precommand.php > ext/phar/phar.php make: *** [ext/phar/phar.php] Error 134 -- Edit bug report at http://bugs.php.net/bug.php?id=51625&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51625&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51625&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51625&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51625&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51625&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51625&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51625&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51625&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51625&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51625&r=support Expected behavior: http://bugs.php.net/fix.php?id=51625&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51625&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51625&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51625&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51625&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51625&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51625&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51625&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51625&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51625&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51625&r=mysqlcfg
[PHP-BUG] Bug #51624 [NEW]: Gallery2 causing segfault when trying to update.
From:
Operating system: Ubuntu/Linux
PHP version: 5.3.2
Package: Reproducible crash
Bug Type: Bug
Bug description:Gallery2 causing segfault when trying to update.
Description:
Hi,
This bug was recently reported on launchpad at
http://bugs.launchpad.net/bugs/567043. I have included the gdb backtrace
with this bug report.
Regards
chuck
Expected result:
Not to crash.
Actual result:
--
#0 0x7fe478493d02 in memcpy () from /lib/libc.so.6
No symbol table info available.
#1 0x00677ff8 in _estrndup (s=0x4d0050 , length=90) at /usr/include/bits/string3.h:52
No locals.
#2 0x0069459b in _zval_copy_ctor_func (zvalue=0x1f84ca8) at
/build/buildd/php5-5.3.2/Zend/zend_variables.c:126
tmp = 0x1ecb470
original_ht = 0x1ecb470
#3 0x7fe4752b0f68 in zif_mysqli_options (ht=33049848,
return_value=0x1f84c58, return_value_ptr=0x5a, this_ptr=0x4d0050,
return_value_used=17) at /build/buildd/php5-5.3.2/Zend/zend_variables.h:45
mysql_link = 0x1f84ca8
mysql_value = 0x5
mysql_option = 33049648
l_value = 0
expected_type = 33049848
#4 0x006e598a in zend_do_fcall_common_helper_SPEC
(execute_data=0x142a390) at
/build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:313
opline = 0x15c7698
should_change_scope = 0 '\000'
#5 0x006bcc70 in execute (op_array=0x11d7080) at
/build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:104
ret = 33049848
execute_data = 0x142a390
nested = 0 '\000'
original_in_execution = 1 '\001'
#6 0x0068ab94 in zend_call_function (fci=0x7fff6ab02fd0,
fci_cache=0x141f840) at
/build/buildd/php5-5.3.2/Zend/zend_execute_API.c:947
i = 17
original_return_value = 0x141f6f0
calling_symbol_table = 0x1938398
original_op_array = 0x19cf630
original_opline_ptr =
current_scope = 0x1db96c0
current_called_scope = 0x1938398
calling_scope = 0x0
called_scope = 0x141f6f0
current_this = 0x0
execute_data = {opline = 0x0, function_state = {function = 0x0,
arguments = 0x1949408}, fbc = 0x141fe68, called_scope = 0x0, op_array =
0x0, object = 0x0, Ts = 0x1956490, CVs = 0x141f938, symbol_table =
0x141f8d8,
prev_execute_data = 0x0, old_error_reporting = 0x141f840, nested
= 0 '\000', original_return_value = 0x1, current_scope = 0x141e228,
current_called_scope = 0x1938398, current_this = 0x1938398, current_object
= 0x1db92d0,
call_opline = 0x0}
#7 0x005cd107 in zif_call_user_func_array (ht=33049848,
return_value=0x1db8eb8, return_value_ptr=0x5a, this_ptr=0x1,
return_value_used=17) at
/build/buildd/php5-5.3.2/ext/standard/basic_functions.c:4782
params = 0x0
retval_ptr = 0x141f840
fci = {size = 6082823, function_table = 0x48, function_name =
0x1927c28, symbol_table = 0x1a58120, retval_ptr_ptr = 0x0, param_count =
1789931600, params = 0x3, object_ptr = 0x1da2868, no_separation = 144
'\220'}
fci_cache = {initialized = 176 '\260', function_handler = 0x1,
calling_scope = 0x1949408, called_scope = 0x1927bf8, object_ptr =
0x1927bf8}
#8 0x006e598a in zend_do_fcall_common_helper_SPEC
(execute_data=0x141f840) at
/build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:313
opline = 0x19d4418
should_change_scope = 0 '\000'
#9 0x006bcc70 in execute (op_array=0x19cf630) at
/build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:104
ret = 33049848
execute_data = 0x141f840
nested = 0 '\000'
original_in_execution = 0 '\000'
#10 0x0069499d in zend_execute_scripts (type=0,
retval=0x7fff6ab03210, file_count=3) at
/build/buildd/php5-5.3.2/Zend/zend.c:1266
files = 0x7fff6ab031e8
i = 1
file_handle = 0x7fff6ab05810
orig_op_array = 0x0
orig_retval_ptr_ptr = 0xd8fd30
#11 0x00640608 in php_execute_script (primary_file=0x1888) at
/build/buildd/php5-5.3.2/main/main.c:2288
__orig_bailout = 0x0
__bailout = {{__jmpbuf = {0, 0, 0, 0, 2, 0, 6040, 0},
__mask_was_saved = 0, __saved_mask = {__val = {0, 0, 1, 0, 27843312, 0, 12,
0, 11235408, 0, 1789928576, 32767, 24063528, 0, 0, 0
prepend_file_p = 0x0
append_file_p = 0x0
prepend_file = {type = 1789930876, filename = 0x7fff6ab027b0
"\367\002\033\003\060", opened_path = 0x0, handle = {fd = 0, fp = 0x0,
stream = {handle = 0x0, isatty = 1789928092, mmap = {len = 1789928096, pos
= 1789928624,
map = 0x7fff6ab02270, buf = 0x7fff6ab02294 "\004",
old_handle = 0x0, old_closer = 0x7fff6ab02298}, reader = 0x7fff6ab022b1,
fsizer = 0x, closer = 0}}, free_filename = 0 '\000'}
append_file = {type = 32270416, filename = 0x81 , opened_path = 0x0, handle = {fd = 11259128, fp = 0xabccf8,
stream = {handle = 0xabccf8, isatty = 178992
Req #51623 [Opn->Wfx]: Upgrade utf8_enc/decode to Windows-1252
Edit report at http://bugs.php.net/bug.php?id=51623&edit=1 ID: 51623 Updated by: paj...@php.net Reported by: nicolas dot grekas+php at gmail dot com Summary: Upgrade utf8_enc/decode to Windows-1252 -Status: Open +Status: Wont fix Type:Feature/Change Request Package: Unknown/Other Function PHP Version: Irrelevant New Comment: Please use mbstring or iconv instead. Previous Comments: [2010-04-21 13:47:22] nicolas dot grekas+php at gmail dot com Description: utf8_enc/decode enc/decodes an ISO-8859-1 string to UTF-8 and vice versa I think it would be a good improvement to use Windows-1252 instead of ISO-8859-1 Windows-1252 is a superset of ISO-8859-1, which only adds some glyphs to unused ISO-8859-1 code point. Added to the fact that Windows-1252 is a de facto world wide standard, that HTML5 is standardizing on UTF-8/Windows-1252 "even if ISO-8859-1 it stated in the document". That would also fix a lot of scripts on the web, where we see some <92> "characters" instead of â (opening single quote, or apostrophe) for example -- Edit this bug report at http://bugs.php.net/bug.php?id=51623&edit=1
[PHP-BUG] Req #51623 [NEW]: Upgrade utf8_enc/decode to Windows-1252
From: Operating system: PHP version: Irrelevant Package: Unknown/Other Function Bug Type: Feature/Change Request Bug description:Upgrade utf8_enc/decode to Windows-1252 Description: utf8_enc/decode enc/decodes an ISO-8859-1 string to UTF-8 and vice versa I think it would be a good improvement to use Windows-1252 instead of ISO-8859-1 Windows-1252 is a superset of ISO-8859-1, which only adds some glyphs to unused ISO-8859-1 code point. Added to the fact that Windows-1252 is a de facto world wide standard, that HTML5 is standardizing on UTF-8/Windows-1252 "even if ISO-8859-1 it stated in the document". That would also fix a lot of scripts on the web, where we see some <92> "characters" instead of â (opening single quote, or apostrophe) for example -- Edit bug report at http://bugs.php.net/bug.php?id=51623&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51623&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51623&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51623&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51623&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51623&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51623&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51623&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51623&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51623&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51623&r=support Expected behavior: http://bugs.php.net/fix.php?id=51623&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51623&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51623&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51623&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51623&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51623&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51623&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51623&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51623&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51623&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51623&r=mysqlcfg
[PHP-BUG] Bug #51622 [NEW]: ArrayObject shows inconsistent behaviour
From: Operating system: PHP version: 5.2.13 Package: SPL related Bug Type: Bug Bug description:ArrayObject shows inconsistent behaviour Description: This bug refers to my report filed under http://bugs.php.net/bug.php?id=34783 which is now more than four years old. In the meantime I found out that using ArrayObject instead of the test class the $t['huba'][]='three'; actually works, thanks to the SPL using its "implemented in C advantage" to circumvent the problem. Actually, it works until the programmer decides to inherit from ArrayObject and overwrite offsetGet(). Then the problem of the offsetGet() method not returning by reference is back. Back in 2005 you were very quick to flag the report as BOGUS, but a look at the source code of "zend_interfaces.c" proves that there is in fact a problem: ZEND_BEGIN_ARG_INFO_EX(arginfo_arrayaccess_offset_get, 0, 0, 1) /* actually this should be return by ref but atm cannot be */ The best way of dealing with this is not to mark it as BOGUS and deny that there is a problem. It would be admitting the fault and perhaps introducing an alternative NewArrayAccess interface that defines &offsetGet(). So future code can use it without breaking old implementations. Test script: --- Array ( [0] => one [1] => two [2] => three ) ) Test2 Object ( [huba] => Array ( [0] => one [1] => two [2] => three ) ) Actual result: -- Test1 Object ( [huba] => Array ( [0] => one [1] => two [2] => three ) ) Notice: Indirect modification of overloaded element of Test2 has no effect in F:\huba.php on line 17 Test2 Object ( [huba] => Array ( [0] => one [1] => two ) ) -- Edit bug report at http://bugs.php.net/bug.php?id=51622&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51622&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51622&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51622&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51622&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51622&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51622&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51622&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51622&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51622&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51622&r=support Expected behavior: http://bugs.php.net/fix.php?id=51622&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51622&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51622&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51622&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51622&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51622&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51622&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51622&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51622&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51622&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51622&r=mysqlcfg
[PHP-BUG] Bug #51621 [NEW]: FILTER_VALIDATE_URL return true on invalid URLs
From: Operating system: MAC OS 10.6.3 PHP version: 5.2.13 Package: Filter related Bug Type: Bug Bug description:FILTER_VALIDATE_URL return true on invalid URLs Description: terq-2 workspace$ php -v PHP 5.2.13 (cli) (built: Mar 16 2010 11:04:48) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies terq-2 workspace$ php http://user:pas::qfas@@@.lol..com/~~/qwedd..php##qewg";, FILTER_VALIDATE_URL)); string(53) "http://user:pas::qfas@@@.lol..com/~~/qwedd..php##qewg"; Test script: --- http://user:pas::qfas@@@.lol..com/~~/qwedd..php##qewg";, FILTER_VALIDATE_URL)); Expected result: boll(false) Actual result: -- string(53) "http://user:pas::qfas@@@.lol..com/~~/qwedd..php##qewg"; -- Edit bug report at http://bugs.php.net/bug.php?id=51621&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51621&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51621&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51621&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51621&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51621&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51621&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51621&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51621&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51621&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51621&r=support Expected behavior: http://bugs.php.net/fix.php?id=51621&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51621&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51621&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51621&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51621&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51621&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51621&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51621&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51621&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51621&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51621&r=mysqlcfg
