#45985 [Asn->Csd]: touch() opened file
ID: 45985
Updated by: [EMAIL PROTECTED]
Reported By: david at grudl dot com
-Status: Assigned
+Status: Closed
Bug Type: Filesystem function related
Operating System: Windows XP SP3
PHP Version: 5.3.0alpha2
Assigned To: pajoye
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:
[2008-09-03 16:52:56] david at grudl dot com
Description:
Opened file can be touched in Windows succefully, but under PHP 5.3
alpha 2 it generates error message 'Utime failed'. I think error is
caused by new function win32_utime() in tsrm_virtual_cwd.c called from
virtual_utime().
Reproduce code:
---
$f = fopen('test.dat', 'r');
touch('test.dat');
fclose($f);
Expected result:
modification time of file test.dat is updated
Actual result:
--
Warning: touch(): Utime failed: Bad file descriptor
or
Warning: touch(): Utime failed: No such file or directory
--
Edit this bug report at http://bugs.php.net/?id=45985&edit=1
#45991 [NEW]: parse_ini_file returns empty array if config.ini is saved as UTF-8
From: ckl at ecw dot de Operating system: Windows XP SP 3 PHP version: 5.3.0alpha2 PHP Bug Type: Filesystem function related Bug description: parse_ini_file returns empty array if config.ini is saved as UTF-8 Description: parse_ini_file returns an empty array while trying to parse any ini-file which is saved as UTF-8. ISO-8859-1 saved ini-files works as expected. Reproduce code: --- ; Saved as UTF-8 [production] application.base_url = application.data_url = "data" database.type = pdo_mysql database.host = 192.168.0.78 database.username = root database.password = database.name = blog Expected result: Get an array.. Actual result: -- array() -- Edit bug report at http://bugs.php.net/?id=45991&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45991&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45991&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45991&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45991&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45991&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45991&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45991&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45991&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45991&r=support Expected behavior:http://bugs.php.net/fix.php?id=45991&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45991&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45991&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45991&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45991&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45991&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45991&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45991&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45991&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45991&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45991&r=mysqlcfg
#45992 [NEW]: \t in include_path is parsed as tabulator
From: ckl at ecw dot de Operating system: Windows XP SP 3 PHP version: 5.3.0alpha2 PHP Bug Type: PHP options/info functions Bug description: \t in include_path is parsed as tabulator Description: I know that the include_path should contain forward slashes, but PHP 5.2.x still accepted backslashes in path. If you use a backslash in your path, the next character is interpreted as an metachar (\trunk is interpreted as \t => tab). Reproduce code: --- include_path = ".;C:\ckl\dev\lang\php\lib\trunk" Expected result: echo get_include_path() => .;C:\ckl\dev\lang\php\lib\trunk Actual result: -- echo get_include_path() => .;C:\ckl\dev\lang\php\lib runk -- Edit bug report at http://bugs.php.net/?id=45992&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45992&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45992&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45992&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45992&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45992&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45992&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45992&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45992&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45992&r=support Expected behavior:http://bugs.php.net/fix.php?id=45992&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45992&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45992&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45992&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45992&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45992&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45992&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45992&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45992&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45992&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45992&r=mysqlcfg
#45993 [NEW]: mb_detect_encoding and mb_check_encoding results are dissonant
From: mtrojan at transline dot de
Operating system: Windows XP
PHP version: 5.2.6
PHP Bug Type: mbstring related
Bug description: mb_detect_encoding and mb_check_encoding results are dissonant
Description:
mb_detect_encoding does not seem to recognize UTF-16 encoded files
properly. Even if it is assured by using mb_check_encoding that a file is
truly UTF-16LE, mb_detect_encoding does not detect the same file as UTF-16
and is returning ISO-8859-1 instead. Activating/deactivating strict mode
has no influence on the result.
Reproduce code:
---
$content = file_get_contents($src_path);
$encodings = array('UTF-16', 'UTF-16LE', 'UTF-16BE', 'UTF-8', 'UNICODE',
'ISO-8859-1');
$enc = mb_detect_encoding($content, $encodings);
print "encoding: $enc\n";
print 'checked: ' . intval(mb_check_encoding($content, 'UTF-16LE'));
Expected result:
encoding: UTF-16LE
checked: 1
Actual result:
--
encoding: ISO-8859-1
checked: 1
--
Edit bug report at http://bugs.php.net/?id=45993&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45993&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45993&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45993&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45993&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45993&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45993&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45993&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45993&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45993&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45993&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45993&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45993&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45993&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45993&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45993&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45993&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45993&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45993&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45993&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45993&r=mysqlcfg
#45992 [Opn->Bgs]: \t in include_path is parsed as tabulator
ID: 45992 Updated by: [EMAIL PROTECTED] Reported By: ckl at ecw dot de -Status: Open +Status: Bogus Bug Type: PHP options/info functions Operating System: Windows XP SP 3 PHP Version: 5.3.0alpha2 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 \t is still a special-character: the tab. Just like \r is a Carriage-Return and \n is a newline. It has always been this way, and is completely expected. These characters simply need to be escaped in double-quoted strings: ".;C:\\ckl\\dev\\lang\\php\\lib\\trunk" Previous Comments: [2008-09-04 11:45:50] ckl at ecw dot de Description: I know that the include_path should contain forward slashes, but PHP 5.2.x still accepted backslashes in path. If you use a backslash in your path, the next character is interpreted as an metachar (\trunk is interpreted as \t => tab). Reproduce code: --- include_path = ".;C:\ckl\dev\lang\php\lib\trunk" Expected result: echo get_include_path() => .;C:\ckl\dev\lang\php\lib\trunk Actual result: -- echo get_include_path() => .;C:\ckl\dev\lang\php\lib runk -- Edit this bug report at http://bugs.php.net/?id=45992&edit=1
#45992 [Bgs]: \t in include_path is parsed as tabulator
ID: 45992 Updated by: [EMAIL PROTECTED] Reported By: ckl at ecw dot de Status: Bogus Bug Type: PHP options/info functions Operating System: Windows XP SP 3 PHP Version: 5.3.0alpha2 New Comment: Or don't use double quotes. Previous Comments: [2008-09-04 12:54:51] [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 \t is still a special-character: the tab. Just like \r is a Carriage-Return and \n is a newline. It has always been this way, and is completely expected. These characters simply need to be escaped in double-quoted strings: ".;C:\\ckl\\dev\\lang\\php\\lib\\trunk" [2008-09-04 11:45:50] ckl at ecw dot de Description: I know that the include_path should contain forward slashes, but PHP 5.2.x still accepted backslashes in path. If you use a backslash in your path, the next character is interpreted as an metachar (\trunk is interpreted as \t => tab). Reproduce code: --- include_path = ".;C:\ckl\dev\lang\php\lib\trunk" Expected result: echo get_include_path() => .;C:\ckl\dev\lang\php\lib\trunk Actual result: -- echo get_include_path() => .;C:\ckl\dev\lang\php\lib runk -- Edit this bug report at http://bugs.php.net/?id=45992&edit=1
#45994 [NEW]: upload_tmp_dir directive in php.ini, DISABLES ALL non-built-in php extensions
From: ipseno at yahoo dot com Operating system: Windows XP SP3 PHP version: 5.3.0alpha2 PHP Bug Type: *Configuration Issues Bug description: upload_tmp_dir directive in php.ini, DISABLES ALL non-built-in php extensions Description: upload_tmp_dir directive in php.ini, DISABLES ALL non-built-in php extensions To recreate this: In php.ini set: upload_tmp_dir = "E:\" create .php file Under windows xp sp3 Apache/2.2.9b, parse it by php-cgi.exe Now skip to upload_tmp_dir section, of generated page and look at a HUGE part of php.ini copied in that filed! That is..., everything from line upload_tmp_dir = "E:\", till the end of php.ini Commenting it out in php.ini. ;upload_tmp_dir = "E:\" OR shifting slash!!! upload_tmp_dir = "E:/" ...fixes it and enables all extensions again! Actual result: -- This is VERY POSSIBLE SOLUTION to: Bug #13290 extension_dir directive is not working -- Edit bug report at http://bugs.php.net/?id=45994&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45994&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45994&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45994&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45994&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45994&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45994&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45994&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45994&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45994&r=support Expected behavior:http://bugs.php.net/fix.php?id=45994&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45994&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45994&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45994&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45994&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45994&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45994&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45994&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45994&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45994&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45994&r=mysqlcfg
#45994 [Opn->Bgs]: "\" directive in php.ini, DISABLES ALL non-built-in php extensions
ID: 45994 Updated by: [EMAIL PROTECTED] Reported By: ipseno at yahoo dot com -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: Windows XP SP3 PHP Version: 5.3.0alpha2 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php You're escaping your ending quote (\" is an escape sequence for a double-quote character). Compare the same to a php-script which does Under windows xp sp3 Apache/2.2.9b, parse it by php-cgi.exe Now skip to upload_tmp_dir section, of generated page and look at a HUGE part of php.ini copied in that filed! That is..., everything from line upload_tmp_dir = "E:\", till the end of php.ini Commenting it out in php.ini. ;upload_tmp_dir = "E:\" OR shifting slash!!! upload_tmp_dir = "E:/" ...fixes it and enables all extensions again! Actual result: -- This is VERY POSSIBLE SOLUTION to: Bug #13290 extension_dir directive is not working -- Edit this bug report at http://bugs.php.net/?id=45994&edit=1
#45994 [Bgs]: "\" directive in php.ini, DISABLES ALL non-built-in php extensions
ID: 45994 Updated by: [EMAIL PROTECTED] Reported By: ipseno at yahoo dot com Status: Bogus Bug Type: *Configuration Issues Operating System: Windows XP SP3 PHP Version: 5.3.0alpha2 New Comment: > Actually... "\" at the END of ANY directive in php.ini > breaks configuration under WinXP What do you not understand behind escape sequence? it IS an escape sequence and means that you escape the double quotes and do not close the string. There is no bug and please choose another channel to get support, thanks for your understanding. Previous Comments: [2008-09-04 14:28:04] [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 You're escaping your ending quote (\" is an escape sequence for a double-quote character). Compare the same to a php-script which does Under windows xp sp3 Apache/2.2.9b, parse it by php-cgi.exe Now skip to upload_tmp_dir section, of generated page and look at a HUGE part of php.ini copied in that filed! That is..., everything from line upload_tmp_dir = "E:\", till the end of php.ini Commenting it out in php.ini. ;upload_tmp_dir = "E:\" OR shifting slash!!! upload_tmp_dir = "E:/" ...fixes it and enables all extensions again! Actual result: -- This is VERY POSSIBLE SOLUTION to: Bug #13290 extension_dir directive is not working -- Edit this bug report at http://bugs.php.net/?id=45994&edit=1
#45991 [Opn->Fbk]: parse_ini_file returns empty array if config.ini is saved as UTF-8
ID: 45991 Updated by: [EMAIL PROTECTED] Reported By: ckl at ecw dot de -Status: Open +Status: Feedback Bug Type: Filesystem function related Operating System: Windows XP SP 3 PHP Version: 5.3.0alpha2 New Comment: Would that be UTF-8 with the BOM? or without? Previous Comments: [2008-09-04 10:13:38] ckl at ecw dot de Description: parse_ini_file returns an empty array while trying to parse any ini-file which is saved as UTF-8. ISO-8859-1 saved ini-files works as expected. Reproduce code: --- ; Saved as UTF-8 [production] application.base_url = application.data_url = "data" database.type = pdo_mysql database.host = 192.168.0.78 database.username = root database.password = database.name = blog Expected result: Get an array.. Actual result: -- array() -- Edit this bug report at http://bugs.php.net/?id=45991&edit=1
#45991 [Fbk]: parse_ini_file returns empty array if config.ini is saved as UTF-8
ID: 45991 Updated by: [EMAIL PROTECTED] Reported By: ckl at ecw dot de Status: Feedback -Bug Type: Filesystem function related +Bug Type: *Configuration Issues Operating System: Windows XP SP 3 PHP Version: 5.3.0alpha2 New Comment: changing to configuration issue Previous Comments: [2008-09-04 14:29:19] [EMAIL PROTECTED] Would that be UTF-8 with the BOM? or without? [2008-09-04 10:13:38] ckl at ecw dot de Description: parse_ini_file returns an empty array while trying to parse any ini-file which is saved as UTF-8. ISO-8859-1 saved ini-files works as expected. Reproduce code: --- ; Saved as UTF-8 [production] application.base_url = application.data_url = "data" database.type = pdo_mysql database.host = 192.168.0.78 database.username = root database.password = database.name = blog Expected result: Get an array.. Actual result: -- array() -- Edit this bug report at http://bugs.php.net/?id=45991&edit=1
#45994 [Opn]: "\" directive in php.ini, DISABLES ALL non-built-in php extensions
ID: 45994 User updated by: ipseno at yahoo dot com -Summary: upload_tmp_dir directive in php.ini, DISABLES ALL non-built-in php extensions Reported By: ipseno at yahoo dot com Status: Open Bug Type: *Configuration Issues Operating System: Windows XP SP3 PHP Version: 5.3.0alpha2 New Comment: Actually... "\" at the END of ANY directive in php.ini breaks configuration under WinXP Ie: error_log = "E:\php-5.3.0alpha2\error.log\" variables_order = "GPCS\" Previous Comments: [2008-09-04 13:54:00] ipseno at yahoo dot com Description: upload_tmp_dir directive in php.ini, DISABLES ALL non-built-in php extensions To recreate this: In php.ini set: upload_tmp_dir = "E:\" create .php file Under windows xp sp3 Apache/2.2.9b, parse it by php-cgi.exe Now skip to upload_tmp_dir section, of generated page and look at a HUGE part of php.ini copied in that filed! That is..., everything from line upload_tmp_dir = "E:\", till the end of php.ini Commenting it out in php.ini. ;upload_tmp_dir = "E:\" OR shifting slash!!! upload_tmp_dir = "E:/" ...fixes it and enables all extensions again! Actual result: -- This is VERY POSSIBLE SOLUTION to: Bug #13290 extension_dir directive is not working -- Edit this bug report at http://bugs.php.net/?id=45994&edit=1
#45994 [Bgs]: "\" directive in php.ini, DISABLES ALL non-built-in php extensions
ID: 45994 User updated by: ipseno at yahoo dot com Reported By: ipseno at yahoo dot com Status: Bogus Bug Type: *Configuration Issues Operating System: Windows XP SP3 PHP Version: 5.3.0alpha2 New Comment: Yes, I've found it out too. It escapes string in php.ini. Just 've been too tired I guess... Previous Comments: [2008-09-04 14:28:13] [EMAIL PROTECTED] > Actually... "\" at the END of ANY directive in php.ini > breaks configuration under WinXP What do you not understand behind escape sequence? it IS an escape sequence and means that you escape the double quotes and do not close the string. There is no bug and please choose another channel to get support, thanks for your understanding. [2008-09-04 14:28:04] [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 You're escaping your ending quote (\" is an escape sequence for a double-quote character). Compare the same to a php-script which does Under windows xp sp3 Apache/2.2.9b, parse it by php-cgi.exe Now skip to upload_tmp_dir section, of generated page and look at a HUGE part of php.ini copied in that filed! That is..., everything from line upload_tmp_dir = "E:\", till the end of php.ini Commenting it out in php.ini. ;upload_tmp_dir = "E:\" OR shifting slash!!! upload_tmp_dir = "E:/" ...fixes it and enables all extensions again! Actual result: -- This is VERY POSSIBLE SOLUTION to: Bug #13290 extension_dir directive is not working -- Edit this bug report at http://bugs.php.net/?id=45994&edit=1
#45994 [Bgs]: "\" directive in php.ini, DISABLES ALL non-built-in php extensions
ID: 45994 User updated by: ipseno at yahoo dot com Reported By: ipseno at yahoo dot com Status: Bogus Bug Type: *Configuration Issues Operating System: Windows XP SP3 PHP Version: 5.3.0alpha2 New Comment: Wait, wait... Now I know, why did I posted this question... Now I reverted PHP to version 5.2.6 And there is NO problems with: upload_tmp_dir = "E:\" BUT, when i copy that php.ini file to PHP 5.3 alpha2 THEN upload_tmp_dir = "E:\" causes behavior as explained above. That is a reason why did I cretaed this "bug" report In 5.2.6 "\" doesn't escape, but in 5.3 alpha2 it does! How come?! Previous Comments: [2008-09-04 14:35:58] ipseno at yahoo dot com Yes, I've found it out too. It escapes string in php.ini. Just 've been too tired I guess... [2008-09-04 14:28:13] [EMAIL PROTECTED] > Actually... "\" at the END of ANY directive in php.ini > breaks configuration under WinXP What do you not understand behind escape sequence? it IS an escape sequence and means that you escape the double quotes and do not close the string. There is no bug and please choose another channel to get support, thanks for your understanding. [2008-09-04 14:28:04] [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 You're escaping your ending quote (\" is an escape sequence for a double-quote character). Compare the same to a php-script which does Under windows xp sp3 Apache/2.2.9b, parse it by php-cgi.exe Now skip to upload_tmp_dir section, of generated page and look at a HUGE part of php.ini copied in that filed! That is..., everything from line upload_tmp_dir = "E:\", till the end of php.ini Commenting it out in php.ini. ;upload_tmp_dir = "E:\" OR shifting slash!!! upload_tmp_dir = "E:/" ...fixes it and enables all extensions again! Actual result: -- This is VERY POSSIBLE SOLUTION to: Bug #13290 extension_dir directive is not working -- Edit this bug report at http://bugs.php.net/?id=45994&edit=1
#45995 [NEW]: apache segmentation fault
From: obylan at gmail dot com Operating system: linux PHP version: 5.2.6 PHP Bug Type: Apache2 related Bug description: apache segmentation fault Description: i have a problem with >= apache-2.2.8 >= php-5.2 >= mysql-5.0 If i build php apache module without mysql support, apache start. But if i build php module with mysql support, apache exit with segmentation fault when i try to start it. I'm using Apache set with MPM prefork. -- Edit bug report at http://bugs.php.net/?id=45995&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45995&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45995&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45995&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45995&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45995&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45995&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45995&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45995&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45995&r=support Expected behavior:http://bugs.php.net/fix.php?id=45995&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45995&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45995&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45995&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45995&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45995&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45995&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45995&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45995&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45995&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45995&r=mysqlcfg
#45886 [Fbk->Opn]: ldap_bind fails with out of memory
ID: 45886 User updated by: rocko823 at gmail dot com Reported By: rocko823 at gmail dot com -Status: Feedback +Status: Open Bug Type: LDAP related Operating System: Solaris 10 SPARC PHP Version: 5.2.6 New Comment: sorry for the delay, I was on extended holiday vacation. I have confirmed that this problem does not occur when the Oracle oci8 is not compiled into PHP and all other factors stay the same. Previous Comments: [2008-08-28 21:27:52] [EMAIL PROTECTED] Could you please try with a PHP compiled without oracle just that we can rule out that from this? [2008-08-27 21:25:45] rocko823 at gmail dot com output from ldd libphp5.so librt.so.1 =>/usr/lib/librt.so.1 libmysqlclient.so.15 => /local/mysql32/lib/libmysqlclient.so.15 libmcrypt.so.4 =>/local/lib/libmcrypt.so.4 libltdl.so.3 => /local/lib/libltdl.so.3 libldap-2.3.so.0 => /local/lib/libldap-2.3.so.0 libpng12.so.0 => /usr/lib/libpng12.so.0 libssl.so.0.9.8 => /usr/local/ssl/lib/libssl.so.0.9.8 libcrypto.so.0.9.8 =>/usr/local/ssl/lib/libcrypto.so.0.9.8 libresolv.so.2 =>/usr/lib/libresolv.so.2 libm.so.2 => /usr/lib/libm.so.2 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libxml2.so.2 => /usr/lib/libxml2.so.2 libclntsh.so.10.1 => /local/instantclient_10_2/libclntsh.so.10.1 libc.so.1 => /usr/lib/libc.so.1 libgcc_s.so.1 => /usr/sfw/lib/libgcc_s.so.1 libaio.so.1 => /usr/lib/libaio.so.1 libmd.so.1 =>/usr/lib/libmd.so.1 libpthread.so.1 => /usr/lib/libpthread.so.1 libthread.so.1 =>/usr/lib/libthread.so.1 libgen.so.1 => /usr/lib/libgen.so.1 libm.so.1 => /usr/lib/libm.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 liblber-2.3.so.0 => /local/lib/liblber-2.3.so.0 libsasl2.so.2 => /local/lib/libsasl2.so.2 libucb.so.1 => /usr/ucblib/libucb.so.1 libelf.so.1 => /usr/lib/libelf.so.1 libz.so.1 => /usr/lib/libz.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 libscf.so.1 => /usr/lib/libscf.so.1 libnnz10.so => /local/lib/libnnz10.so libkstat.so.1 => /usr/lib/libkstat.so.1 libsched.so.1 => /usr/lib/libsched.so.1 libdoor.so.1 => /usr/lib/libdoor.so.1 libuutil.so.1 => /usr/lib/libuutil.so.1 /platform/SUNW,Sun-Fire-480R/lib/libc_psr.so.1 /platform/SUNW,Sun-Fire-480R/lib/libmd_psr.so.1 I checked the apache ldap modules and they are linking against the same versions of the ldap libs as reported above for libphp5.so [2008-08-27 21:10:21] [EMAIL PROTECTED] Check the libphp5.so what it's linked with. (ldd libphp5.so) [2008-08-27 20:45:59] rocko823 at gmail dot com I found the problem. This apparently occurs when the Apache LDAP modules (mod_authnz_ldap, and mod_ldap) are not loaded. I added these to my LoadModule section in httpd.conf and now ldap_connect and ldap_bind work perfectly. I'm not really sure why this would be as I've had previous set ups and not used the Apache LDAP module. [2008-08-22 17:05:53] [EMAIL PROTECTED] Because some oracle libs contain their own implementation of ldap functions and conflict with openldap ones. And IIRC, Solaris also has it's own ldap stuff (sometimes) so in worst case you have 3 different set of libs around and the mess is ready. You could try compiling PHP ldap using the oracle libs: --with-ldap=/local/instantclient_10_2/ I'm not sure if this instantclient thing has the ldap stuff, but I guess it's worth trying.. 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/45886 -- Edit this bug report at http://bugs.php.net/?id=45886&edit=1
#45994 [Bgs->Opn]: "\" directive in php.ini, DISABLES ALL non-built-in php extensions
ID: 45994 Updated by: [EMAIL PROTECTED] Reported By: ipseno at yahoo dot com -Status: Bogus +Status: Open Bug Type: *Configuration Issues Operating System: Windows XP SP3 PHP Version: 5.3.0alpha2 New Comment: We're talking about ini files here, we always had different rules in ini files than regular code! Not sure if this is caused by Jani's improvements in the parsing or by some re2c work, but it should certainly work as before else many Windows users will have this issue! Previous Comments: [2008-09-04 14:46:00] ipseno at yahoo dot com Wait, wait... Now I know, why did I posted this question... Now I reverted PHP to version 5.2.6 And there is NO problems with: upload_tmp_dir = "E:\" BUT, when i copy that php.ini file to PHP 5.3 alpha2 THEN upload_tmp_dir = "E:\" causes behavior as explained above. That is a reason why did I cretaed this "bug" report In 5.2.6 "\" doesn't escape, but in 5.3 alpha2 it does! How come?! [2008-09-04 14:35:58] ipseno at yahoo dot com Yes, I've found it out too. It escapes string in php.ini. Just 've been too tired I guess... [2008-09-04 14:28:13] [EMAIL PROTECTED] > Actually... "\" at the END of ANY directive in php.ini > breaks configuration under WinXP What do you not understand behind escape sequence? it IS an escape sequence and means that you escape the double quotes and do not close the string. There is no bug and please choose another channel to get support, thanks for your understanding. [2008-09-04 14:28:04] [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 You're escaping your ending quote (\" is an escape sequence for a double-quote character). Compare the same to a php-script which does http://bugs.php.net/45994 -- Edit this bug report at http://bugs.php.net/?id=45994&edit=1
#45996 [NEW]: libxml2 2.7.1 causes breakage with character data in xml_parse()
From: phpbugs at colin dot guthr dot ie Operating system: Mandriva Linux PHP version: 5.2.6 PHP Bug Type: *XML functions Bug description: libxml2 2.7.1 causes breakage with character data in xml_parse() Description: With libxml2 2.7.1, When using the expat type xml parsing routines in PHP, the characater data seems to silently drop any encoded text e.g. > < and friends. Please see Mandriva bug for details: https://qa.mandriva.com/show_bug.cgi?id=43486 And also please note the thread on the libxml mailing list: http://thread.gmane.org/gmane.comp.gnome.lib.xml.general/14610 And most notably the reply to the above thread: Can you report this as a PHP bug? It looks like some really old hack code in the PHP extension in order to mimic some specific expat functionality. The behavior change you see though resulting from a code changes in libxml2 is really due to the hackish code in the extension doing things it wasnt meant to be doing. Reproduce code: --- Please see this code: https://qa.mandriva.com/attachment.cgi?id=10757 Expected result: < foo > wibble < /foo > Actual result: -- foo wibble /foo -- Edit bug report at http://bugs.php.net/?id=45996&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45996&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45996&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45996&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45996&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45996&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45996&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45996&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45996&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45996&r=support Expected behavior:http://bugs.php.net/fix.php?id=45996&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45996&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45996&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45996&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45996&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45996&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45996&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45996&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45996&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45996&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45996&r=mysqlcfg
#45988 [Opn->Bgs]: usort assumes comparison operation is transitive
ID: 45988
User updated by: php at sameprecision dot org
Reported By: php at sameprecision dot org
-Status: Open
+Status: Bogus
Bug Type: Arrays related
Operating System: irrelevant
PHP Version: 5.2.6
New Comment:
I think I have made a mistake in trying to use a generalized sorting
algorithm with a comparison operation that is not transitive.
The operation HAS to be transitive or there will always be an example
that doesn't work.
sorry!
Previous Comments:
[2008-09-03 20:38:01] php at sameprecision dot org
Description:
Using usort, not all pairs of elements are compared. If a comparison
operation is not transitive, this leads to unexpected ordering, even
though every pair of elements are comparable.
This should probably be mentioned in the documentation.
Reproduce code:
---
//goal: sort $array so that an element is not a substring of any
subsequent elements
$array = array('aa','b','a');
//if $a is a substring of $b, return 1. Else return -1
function compare($a,$b){
return strpos($b,$a)===false ? -1 : 1;
}
usort($array,'compare');
print_r($array);
Expected result:
Array ( [0] => aa [1] => b [2] => a )
Actual result:
--
Array ( [0] => a [1] => b [2] => aa )
--
Edit this bug report at http://bugs.php.net/?id=45988&edit=1
#45997 [NEW]: safe_mode bypass
From: johannesdahse at gmx dot de
Operating system: Windows
PHP version: 5.2.6
PHP Bug Type: Safe Mode/open_basedir
Bug description: safe_mode bypass
Description:
safe_mode bypass with a preceding backslash. tested with exec(), system()
and passthru(). on windows only.
Sorry, I do feel this bug concerns a security issue but I got no response
from [EMAIL PROTECTED] after sending 2 emails from 2 different accounts
about 6 weeks ago.
Reproduce code:
---
on commandline:
php -n -d safe_mode=on -r "exec('\ping 192.168.222.1');"
with PHP script and enabled safe_mode in php.ini:
Expected result:
safe_mode turned on should block code execution from exec() and other
functions.
Actual result:
--
By adding a backslash infront of the command the command got executed
anyhow.
--
Edit bug report at http://bugs.php.net/?id=45997&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45997&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45997&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45997&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45997&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45997&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45997&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45997&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45997&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45997&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45997&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45997&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45997&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45997&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45997&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45997&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45997&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45997&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45997&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45997&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45997&r=mysqlcfg
#45995 [Opn->Fbk]: apache segmentation fault
ID: 45995 Updated by: [EMAIL PROTECTED] Reported By: obylan at gmail dot com -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: linux PHP Version: 5.2.6 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: [2008-09-04 15:11:24] obylan at gmail dot com Description: i have a problem with >= apache-2.2.8 >= php-5.2 >= mysql-5.0 If i build php apache module without mysql support, apache start. But if i build php module with mysql support, apache exit with segmentation fault when i try to start it. I'm using Apache set with MPM prefork. -- Edit this bug report at http://bugs.php.net/?id=45995&edit=1
#45994 [Opn]: "\" directive in php.ini, DISABLES ALL non-built-in php extensions
ID: 45994 Updated by: [EMAIL PROTECTED] Reported By: ipseno at yahoo dot com Status: Open Bug Type: *Configuration Issues Operating System: Windows XP SP3 PHP Version: 5.3.0alpha2 New Comment: As mentioned on the internals list, this should cause a syntax error. Much like in PHP code this would not work: Previous Comments: [2008-09-04 16:22:54] [EMAIL PROTECTED] We're talking about ini files here, we always had different rules in ini files than regular code! Not sure if this is caused by Jani's improvements in the parsing or by some re2c work, but it should certainly work as before else many Windows users will have this issue! [2008-09-04 14:46:00] ipseno at yahoo dot com Wait, wait... Now I know, why did I posted this question... Now I reverted PHP to version 5.2.6 And there is NO problems with: upload_tmp_dir = "E:\" BUT, when i copy that php.ini file to PHP 5.3 alpha2 THEN upload_tmp_dir = "E:\" causes behavior as explained above. That is a reason why did I cretaed this "bug" report In 5.2.6 "\" doesn't escape, but in 5.3 alpha2 it does! How come?! [2008-09-04 14:35:58] ipseno at yahoo dot com Yes, I've found it out too. It escapes string in php.ini. Just 've been too tired I guess... [2008-09-04 14:28:13] [EMAIL PROTECTED] > Actually... "\" at the END of ANY directive in php.ini > breaks configuration under WinXP What do you not understand behind escape sequence? it IS an escape sequence and means that you escape the double quotes and do not close the string. There is no bug and please choose another channel to get support, thanks for your understanding. [2008-09-04 14:28:04] [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 You're escaping your ending quote (\" is an escape sequence for a double-quote character). Compare the same to a php-script which does http://bugs.php.net/45994 -- Edit this bug report at http://bugs.php.net/?id=45994&edit=1
#45973 [Opn->Fbk]: segfault when setting include_path to concat. of non-defined ${include_path}
ID: 45973
Updated by: [EMAIL PROTECTED]
Reported By: olivier dot berger at it-sudparis dot eu
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Debian lenny
PHP Version: 5.2.6
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.3-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.3-win32-installer-latest.msi
Please test with 5.3, the ini scanner/parser has been rewritten in it
and I'd like to know if this happens there too. (can't test myself right
now...)
Previous Comments:
[2008-09-02 13:00:01] olivier dot berger at it-sudparis dot eu
Description:
If include_path wasn't set already, setting it to some concatenation of
${include_path} causes a segfault.
Seems different from #37002, AFAICT
More details in Debian bug :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497453
Reproduce code:
---
For instance, if /etc/php5/apache2/php.ini doesn't contain any
include_path definition, like is by default in Debian :
; UNIX: "/path1:/path2"
;include_path = ".:/usr/share/php"
then setting the following in for instance /etc/php5/conf.d/zend.ini :
[Zend]
include_path = ${include_path}
":/usr/share/php/libzend-framework-php"
leads to segmentation fault.
Expected result:
I guess referencing variables no yet explicitely set, but having
default values should return their default value.
Uncommenting the default include_path in /etc/php5/apache2/php.ini
allows it to work.
Actual result:
--
Apache segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=45973&edit=1
#45886 [Opn->Fbk]: ldap_bind fails with out of memory
ID: 45886 Updated by: [EMAIL PROTECTED] Reported By: rocko823 at gmail dot com -Status: Open +Status: Feedback Bug Type: LDAP related Operating System: Solaris 10 SPARC PHP Version: 5.2.6 New Comment: Ok, so it's most likely the old issue with Oracle libs containing their own ldap API which conflicts with openldap. In this case, you should configure PHP to use the oracle libs for ldap too. ie. pass --with-ldap the proper path to the oracle libs. Previous Comments: [2008-09-04 16:01:31] rocko823 at gmail dot com sorry for the delay, I was on extended holiday vacation. I have confirmed that this problem does not occur when the Oracle oci8 is not compiled into PHP and all other factors stay the same. [2008-08-28 21:27:52] [EMAIL PROTECTED] Could you please try with a PHP compiled without oracle just that we can rule out that from this? [2008-08-27 21:25:45] rocko823 at gmail dot com output from ldd libphp5.so librt.so.1 =>/usr/lib/librt.so.1 libmysqlclient.so.15 => /local/mysql32/lib/libmysqlclient.so.15 libmcrypt.so.4 =>/local/lib/libmcrypt.so.4 libltdl.so.3 => /local/lib/libltdl.so.3 libldap-2.3.so.0 => /local/lib/libldap-2.3.so.0 libpng12.so.0 => /usr/lib/libpng12.so.0 libssl.so.0.9.8 => /usr/local/ssl/lib/libssl.so.0.9.8 libcrypto.so.0.9.8 =>/usr/local/ssl/lib/libcrypto.so.0.9.8 libresolv.so.2 =>/usr/lib/libresolv.so.2 libm.so.2 => /usr/lib/libm.so.2 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libxml2.so.2 => /usr/lib/libxml2.so.2 libclntsh.so.10.1 => /local/instantclient_10_2/libclntsh.so.10.1 libc.so.1 => /usr/lib/libc.so.1 libgcc_s.so.1 => /usr/sfw/lib/libgcc_s.so.1 libaio.so.1 => /usr/lib/libaio.so.1 libmd.so.1 =>/usr/lib/libmd.so.1 libpthread.so.1 => /usr/lib/libpthread.so.1 libthread.so.1 =>/usr/lib/libthread.so.1 libgen.so.1 => /usr/lib/libgen.so.1 libm.so.1 => /usr/lib/libm.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 liblber-2.3.so.0 => /local/lib/liblber-2.3.so.0 libsasl2.so.2 => /local/lib/libsasl2.so.2 libucb.so.1 => /usr/ucblib/libucb.so.1 libelf.so.1 => /usr/lib/libelf.so.1 libz.so.1 => /usr/lib/libz.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 libscf.so.1 => /usr/lib/libscf.so.1 libnnz10.so => /local/lib/libnnz10.so libkstat.so.1 => /usr/lib/libkstat.so.1 libsched.so.1 => /usr/lib/libsched.so.1 libdoor.so.1 => /usr/lib/libdoor.so.1 libuutil.so.1 => /usr/lib/libuutil.so.1 /platform/SUNW,Sun-Fire-480R/lib/libc_psr.so.1 /platform/SUNW,Sun-Fire-480R/lib/libmd_psr.so.1 I checked the apache ldap modules and they are linking against the same versions of the ldap libs as reported above for libphp5.so [2008-08-27 21:10:21] [EMAIL PROTECTED] Check the libphp5.so what it's linked with. (ldd libphp5.so) [2008-08-27 20:45:59] rocko823 at gmail dot com I found the problem. This apparently occurs when the Apache LDAP modules (mod_authnz_ldap, and mod_ldap) are not loaded. I added these to my LoadModule section in httpd.conf and now ldap_connect and ldap_bind work perfectly. I'm not really sure why this would be as I've had previous set ups and not used the Apache LDAP module. 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/45886 -- Edit this bug report at http://bugs.php.net/?id=45886&edit=1
#45998 [NEW]: in_array returning true for values not in the array
From: raven990862 at gmail dot com Operating system: Windows Vista PHP version: 5.2.6 PHP Bug Type: Arrays related Bug description: in_array returning true for values not in the array Description: in_array is returning true for needles that are not in the haystack. The problem is with with large needles that are similar except for least significant digits. Yes, it does work correctly when you set strict to true in in_array, however I would expect this to work correctly with out it. Reproduce code: --- Expected result: This should return nothing. Actual result: -- in_array returns true and the echo occurs. -- Edit bug report at http://bugs.php.net/?id=45998&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45998&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45998&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45998&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45998&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45998&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45998&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45998&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45998&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45998&r=support Expected behavior:http://bugs.php.net/fix.php?id=45998&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45998&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45998&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45998&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45998&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45998&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45998&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45998&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45998&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45998&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45998&r=mysqlcfg
#45999 [NEW]: MySQL/PDF clash
From: markem at airmail dot net
Operating system: Windows XP
PHP version: 5.2.6
PHP Bug Type: PDF related
Bug description: MySQL/PDF clash
Description:
I'm unsure if I have the actual cause - but
I'm working on a large report. They would like for it to be in PDF. So
I'm using PDFLIB. If all of the code is together - the PDF is generated
with no problems. Unfortunately, between the pdf_new() and then other pdf
commands there is an SQL call to MySQL. When that is finished the error I
get back is:
PHP Fatal error: Uncaught exception 'PDFlibException' with message
'pdf_open_file(): 6 is not a valid pdf object resource'
The #6 is the resource ID (if I put in echo statements to print out $myPDF
it prints "6") of the PDF document. So it is like PHP is closing out the
PDF document (or maybe just dumping the resource info).
Reproduce code:
---
$myPDF = pdf_new();
pdf_open_file( $myPDF, "" );# We use a
"" if the output is coming
pdf_begin_page( $myPDF, 11 * 72, 8.5 * 72 );# Paper
resolution is 72dpi. Always use inches.
pdf_translate( $myPDF, 0, 8.5 * 72 ); # Translate
where the origin is to the top-left.
pdf_scale( $myPDF, 1, -1 ); # Rescale
everything.
pdf_set_value( $myPDF, "horizscaling", -100 ); # Set the
horizontal scaling to -100%.
$font = pdf_load_font( $myPDF, "Helvetica","iso8859-1", "" );
if( $font ){ pdf_setfont( $myPDF, $font, -18.0 ); }
$theString = "Palliative and Supportive Care Inpatient | Consult
List";
pdf_show_boxed( $myPDF, $theString, 20, 50, 500, 20, "center", ""
);
pdf_setcolor( $myPDF, "fill", "rgb", 0.9, 0.9, 0.9, 0.0 );
pdf_rect( $myPDF, 20, 50, 300, 20 );
pdf_fill_stroke( $myPDF );
pdf_end_page( $myPDF );
pdf_set_parameter( $myPDF, "openaction", "fitpage" );
pdf_close( $myPDF );
$buf = pdf_get_buffer( $myPDF );
$len = strlen( $buf );
header( "Content-Type:application/pdf" );
header( "Content-Length:$len" );
header( "Content-Disposition:inline; filename=DailyRpt.pdf" );
echo $buf;
pdf_delete( $myPDF );
Expected result:
The above code works so long as it is all together. I get a single PDF
page which reads "Palliative and Supportive Care Inpatient | Consult List".
Actual result:
--
However, if an SQL command is sent to the database between the "pdf_new()"
and the "pdf_open_file()" commands, no PDF document is generated and Apache
gives the above error.
Example SQL command:
$sql = <
#45996 [Opn]: libxml2 2.7.1 causes breakage with character data in xml_parse()
ID: 45996 Updated by: [EMAIL PROTECTED] Reported By: phpbugs at colin dot guthr dot ie Status: Open Bug Type: XML related Operating System: Mandriva Linux PHP Version: 5.2.6 -Assigned To: +Assigned To: rrichards New Comment: assign to self Previous Comments: [2008-09-04 17:29:21] phpbugs at colin dot guthr dot ie Description: With libxml2 2.7.1, When using the expat type xml parsing routines in PHP, the characater data seems to silently drop any encoded text e.g. > < and friends. Please see Mandriva bug for details: https://qa.mandriva.com/show_bug.cgi?id=43486 And also please note the thread on the libxml mailing list: http://thread.gmane.org/gmane.comp.gnome.lib.xml.general/14610 And most notably the reply to the above thread: Can you report this as a PHP bug? It looks like some really old hack code in the PHP extension in order to mimic some specific expat functionality. The behavior change you see though resulting from a code changes in libxml2 is really due to the hackish code in the extension doing things it wasnt meant to be doing. Reproduce code: --- Please see this code: https://qa.mandriva.com/attachment.cgi?id=10757 Expected result: < foo > wibble < /foo > Actual result: -- foo wibble /foo -- Edit this bug report at http://bugs.php.net/?id=45996&edit=1
#45998 [Opn->Bgs]: in_array returning true for values not in the array
ID: 45998 Updated by: [EMAIL PROTECTED] Reported By: raven990862 at gmail dot com -Status: Open +Status: Bogus Bug Type: Arrays related Operating System: Windows Vista PHP Version: 5.2.6 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 Use the third parameter: - http://docs.php.net/in-array Previous Comments: [2008-09-04 23:41:56] raven990862 at gmail dot com Description: in_array is returning true for needles that are not in the haystack. The problem is with with large needles that are similar except for least significant digits. Yes, it does work correctly when you set strict to true in in_array, however I would expect this to work correctly with out it. Reproduce code: --- Expected result: This should return nothing. Actual result: -- in_array returns true and the echo occurs. -- Edit this bug report at http://bugs.php.net/?id=45998&edit=1
#42434 [Com]: ImageLine w/ antialias = 1px shorter
ID: 42434
Comment by: abc at abc dot abc
Reported By: wojjie at gmail dot com
Status: Assigned
Bug Type: GD related
Operating System: *
PHP Version: 5.2.3
Assigned To: pajoye
New Comment:
reproduced on PHP 5.2.6 / windows. problem is still there
Previous Comments:
[2007-08-27 11:04:46] [EMAIL PROTECTED]
Assigned to the maintainer.
[2007-08-27 04:50:47] wojjie at gmail dot com
Description:
This bug looks fixed in the GD library, but for some reason the GD
included in PHP still has this.
What happens is when drawing a line with anti aliasing enabled, the
resulting line is 1 pixel shorter than it should be.
Fix (using snapshot: php5.2-200708270430.tar.gz):
--- gd.c 2007-08-26 23:44:04.0 -0500
+++ gd.c2007-08-26 23:44:28.0 -0500
@@ -1351,7 +1351,7 @@
x = x1 << 16;
y = y1 << 16;
inc = (dy * 65536) / dx;
- while ((x >> 16) < x2) {
+ while ((x >> 16) <= x2) {
gdImageSetAAPixelColor(im, x >> 16, y >> 16,
col, (y >> 8) & 0xFF);
if ((y >> 16) + 1 < im->sy) {
gdImageSetAAPixelColor(im, x >> 16, (y
>> 16) + 1,col, (~y >> 8) & 0xFF);
@@ -1373,7 +1373,7 @@
x = x1 << 16;
y = y1 << 16;
inc = (dx * 65536) / dy;
- while ((y>>16) < y2) {
+ while ((y>>16) <= y2) {
gdImageSetAAPixelColor(im, x >> 16, y >> 16,
col, (x >> 8) & 0xFF);
if ((x >> 16) + 1 < im->sx) {
gdImageSetAAPixelColor(im, (x >> 16) +
1, (y >> 16),col, (~x >> 8) & 0xFF);
Reproduce code:
---
Expected result:
Two lines of equal length
Actual result:
--
Top line is longer than bottom line by 1 pixel.
--
Edit this bug report at http://bugs.php.net/?id=42434&edit=1
#40695 [Com]: odbc_execute/prepared statements does not work with Access
ID: 40695
Comment by: geoff dot brisbine at gmail dot com
Reported By: a at bc dot de
Status: Open
Bug Type: ODBC related
Operating System: Windows
PHP Version: 5.2.1
New Comment:
It's happening for me on Windows XP Pro SP2 w/Apache 2.2 and PHP 5.2.6
(php5apache2_2.dll).
Previous Comments:
[2007-03-02 18:34:29] a at bc dot de
Description:
[repost of bug 6275]
Hello,
My problem is odbc_execute fails with the following error message:
Warning: SQL error: [Microsoft][ODBC Microsoft Access Driver]COUNT
field
incorrect , SQL state 07001 in SQLExecute in
d:\Inetpub\wwwroot\php\adodb\index.php on line 77
The odbc_exec INSERT works fine. I am using a plain vanilla NorthWind
MS
Access database and am using the ISAPI version of PHP, with ODBC built
in.
Reproduce code:
---
$conn = odbc_connect("nwind","","");
odbc_exec($conn,"drop table ADOXYZ");
odbc_exec($conn,"create table ADOXYZ (id int, firstname char(24),
lastname char(24))");
odbc_exec($conn,"insert into ADOXYZ (id,firstname,lastname) values
(0,'Zend','PHP')");
$stmt = odbc_prepare($conn,"insert into ADOXYZ (id,firstname,lastname)
values (?,?,?)");
if ($stmt) {
print "Trying execute";
$stmt = odbc_execute($stmt,array(1,"John","Lim"));
}
Actual result:
--
Warning: SQL error: [Microsoft][ODBC Microsoft Access Driver]COUNT
field
incorrect , SQL state 07001 in SQLExecute in
d:\Inetpub\wwwroot\php\adodb\index.php on line 77
--
Edit this bug report at http://bugs.php.net/?id=40695&edit=1
#40695 [Com]: odbc_execute/prepared statements does not work with Access
ID: 40695
Comment by: geoff dot brisbine at gmail dot com
Reported By: a at bc dot de
Status: Open
Bug Type: ODBC related
Operating System: Windows
PHP Version: 5.2.1
New Comment:
Forgot in last post, this is accessing Paradox 4.x tables.
Previous Comments:
[2008-09-05 02:48:31] geoff dot brisbine at gmail dot com
It's happening for me on Windows XP Pro SP2 w/Apache 2.2 and PHP 5.2.6
(php5apache2_2.dll).
[2007-03-02 18:34:29] a at bc dot de
Description:
[repost of bug 6275]
Hello,
My problem is odbc_execute fails with the following error message:
Warning: SQL error: [Microsoft][ODBC Microsoft Access Driver]COUNT
field
incorrect , SQL state 07001 in SQLExecute in
d:\Inetpub\wwwroot\php\adodb\index.php on line 77
The odbc_exec INSERT works fine. I am using a plain vanilla NorthWind
MS
Access database and am using the ISAPI version of PHP, with ODBC built
in.
Reproduce code:
---
$conn = odbc_connect("nwind","","");
odbc_exec($conn,"drop table ADOXYZ");
odbc_exec($conn,"create table ADOXYZ (id int, firstname char(24),
lastname char(24))");
odbc_exec($conn,"insert into ADOXYZ (id,firstname,lastname) values
(0,'Zend','PHP')");
$stmt = odbc_prepare($conn,"insert into ADOXYZ (id,firstname,lastname)
values (?,?,?)");
if ($stmt) {
print "Trying execute";
$stmt = odbc_execute($stmt,array(1,"John","Lim"));
}
Actual result:
--
Warning: SQL error: [Microsoft][ODBC Microsoft Access Driver]COUNT
field
incorrect , SQL state 07001 in SQLExecute in
d:\Inetpub\wwwroot\php\adodb\index.php on line 77
--
Edit this bug report at http://bugs.php.net/?id=40695&edit=1
[california.jobs.com] (Job) Software Developer - New York, NY
This is my direct client opening for Software Developer - New York, NY. This is a long-term contract position. The Hourly rate is DOE. Candidates need to interview in person and should be in the NY area Requirements: -Eight (8) years experience: -Browser based development using Macromedia MX, VB, VB.NET, ASP, ASP.NET. -Strong SQL Server development -Must have four (4) years experience with SQL development skills including writing Stored Procedures. * Must possess strong time management skills. * Must have demonstrated experience in successfully delivering software solutions. * Must have proven and bz2.so. I have traced behavior, which doesn't let me include or read files, to the registered php streams. Which is easily obtainable from the phpinfo() output. Consider the lines below and their output. The registered php streams string gets mangled by including different modules. The resulting string seems to be semantically incorrect. I've tried a lot of different configure lines, changing extensions, with or without the suhosin patch. Didn't seem to change results except when I used --enable- simplexml instead of --enable- simplexml=shared. So compiling it in or loading it via php.ini is a workaround. Reproduce code: --- The configure string I used contains all the options I could find (sorry about that). --enable-libxml=shared --without-libxml-dir --with-openssl=shared --with-kerberos=shared --with-pcre-regex=/usr --with-zlib=shared --without-zlib-dir --disable-bcmath --with-bz2=shared --enable-calendar=shared --enable-ctype --with-curl=shared --without-curl-wrappers --disable-dba --without-qdbm --without-gdbm --without-ndbm --without-db4 --without-db3 --without-db2 --without-db1 --without-dbm --without-cdb --disable-inifile --disable-flatfile --disable-dbase --enable-dom --without-libxml-dir --enable-exif=shared --without-fbsql --without-fdftk --enable-filter --without-pcre-dir --enable-ftp=shared --without-openssl-dir --with-gd=shared --with-jpeg-dir=shared,/usr --with-png-dir=shared,/usr --without-zlib-dir --without-xmp-dir --with-ttf=shared --without-freetype-dir --without-t1lib --enable-gd-native-ttf --disable-gd-jis-conv --without-gettext --without-gmp --enable-hash=shared --with-iconv=shared --without-imap --with-kerberos --with-imap-ssl=shared --without-interbase --enable-json=shared --without-ldap --without-ldap-sasl --disable-mbstring --disable-mbregex --disable-mbregex-backtrack --without-libmbfl --with-mcrypt=shared --with-mhash=shared --with-mime-magic=shared --without-ming --without-msql --without-mssql --with-mysql=shared --with-mysql-sock=/tmp/mysql.sock --without-zlib-dir --with-mysqli=shared --disable-embedded-mysqli --without-ncurses --without-oci8 --without-adabas --without-sapdb --without-solid --without-ibm-db2 --without-ODBCRouter --without-empress --without-empress-bcs --without-birdstep --without-custom-odbc --without-iodbc --without-esoob --without-unixODBC --without-dbmaker --enable-pcntl --enable-pdo=shared --without-pdo-dblib --without-pdo-firebird --with-pdo-mysql=shared --without-zlib-dir --without-pdo-oci --without-pdo-odbc --without-pdo-pgsql --with-pdo-sqlite=shared --without-pgsql --enable-posix=shared --without-pspell --without-libedit --with-readline=shared --without-recode --enable-reflection --enable-session=shared --without-mm --enable-shmop=shared --enable-simplexml=shared --without-libxml-dir --without-snmp --without-openssl-dir --without-ucd-snmp-hack --enable-soap=shared --without-libxml-dir --enable-sockets=shared --enable-spl=shared --with-sqlite=shared --enable-sqlite-utf8=shared --with-regex=php --without-sybase --without-sybase-ct --enable-sysvmsg=shared --enable-sysvsem=shared --enable-sysvshm=shared --without-tidy --disable-tokenizer --disable-wddx --without-libxml-dir --without-libexpat-dir --enable-xml --without-libxml-dir --without-libexpat-dir --enable-xmlreader=shared --without-libxml-dir --without-xmlrpc --without-libxml-dir --without-libexpat-dir --without-iconv-dir --enable-xmlwriter=shared --without-libxml-dir --with-xsl=shared --enable-zip=shared --without-zlib-dir I have ran my test code on different configurations, but the issues seem to be directly related to the php registered streams string. Which is easier to capture, post and relate to behavior, which is done in the 'actual result' secti
