Bug #61895 [Opn]: PHP core crash when call $pdoStmt-execute($array_params) with PDO_Firebird
Edit report at https://bugs.php.net/bug.php?id=61895edit=1 ID: 61895 User updated by:andrey at tranvi dot info Reported by:andrey at tranvi dot info Summary:PHP core crash when call $pdoStmt-execute($array_params) with PDO_Firebird Status: Open Type: Bug Package:PDO related Operating System: Windows PHP Version:5.3.11 Block user comment: N Private report: N New Comment: Backtrace: php5ts_debug.dll!zend_error(int type=2, const char * format=0x10592b4c, ...) СÑÑока 979 C php5ts_debug.dll!_zval_dtor_func(_zval_struct * zvalue=0x026e4408, char * __zend_filename=0x10587080, unsigned int __zend_lineno=447) СÑÑока 35 + 0x2d Ð±Ð°Ð¹Ñ C php5ts_debug.dll!_zval_dtor(_zval_struct * zvalue=0x026e4408, char * __zend_filename=0x10587080, unsigned int __zend_lineno=447) СÑÑока 35 + 0x11 Ð±Ð°Ð¹Ñ C php5ts_debug.dll!_zval_ptr_dtor(_zval_struct * * zval_ptr=0x026e6660, char * __zend_filename=0x1064d5dc, unsigned int __zend_lineno=293) СÑÑока 447 + 0x17 Ð±Ð°Ð¹Ñ C php5ts_debug.dll!param_dtor(void * data=0x026e6650) СÑÑока 293 + 0x1a Ð±Ð°Ð¹Ñ C php5ts_debug.dll!zend_hash_destroy(_hashtable * ht=0x026e4bc8) СÑÑока 529 + 0x11 байÑC php5ts_debug.dll!zim_PDOStatement_execute(int ht=1, _zval_struct * return_value=0x026e2f60, _zval_struct * * return_value_ptr=0x, _zval_struct * this_ptr=0x026e2b20, int return_value_used=0, void * * * tsrm_ls=0x02993f98) СÑÑока 453 + 0xc Ð±Ð°Ð¹Ñ C php5ts_debug.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data * execute_data=0x026806e8, void * * * tsrm_ls=0x02993f98) СÑÑока 320 + 0x78 байÑC php5ts_debug.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER(_zend_execute_data * execute_data=0x026806e8, void * * * tsrm_ls=0x02993f98) СÑÑока 426 C php5ts_debug.dll!execute(_zend_op_array * op_array=0x02e038f0, void * * * tsrm_ls=0x02993f98) СÑÑока 107 + 0x11 Ð±Ð°Ð¹Ñ C php5ts_debug.dll!zend_execute_scripts(int type=8, void * * * tsrm_ls=0x02993f98, _zval_struct * * retval=0x, int file_count=3, ...) СÑÑока 1236 + 0x21 Ð±Ð°Ð¹Ñ C php5ts_debug.dll!php_execute_script(_zend_file_handle * primary_file=0x00c1fed8, void * * * tsrm_ls=0x02993f98) СÑÑока 2308 + 0x1b Ð±Ð°Ð¹Ñ C php.exe!main(int argc=4, char * * argv=0x02993e30) СÑÑока 1184 + 0x13 Ð±Ð°Ð¹Ñ C php.exe!__tmainCRTStartup() СÑÑока 586 + 0x19 Ð±Ð°Ð¹Ñ C php.exe!mainCRTStartup() СÑÑока 403 C kernel32.dll!763fed6c() [УказаннÑе ниже ÑÑÐµÐ¹Ð¼Ñ Ð¼Ð¾Ð³ÑÑ Ð±ÑÑÑ Ð½ÐµÐ²ÐµÑÐ½Ñ Ð¸ (или) оÑÑÑÑÑÑвоваÑÑ, ÑÐ¸Ð¼Ð²Ð¾Ð»Ñ Ð´Ð»Ñ kernel32.dll не загÑÑженÑ] ntdll.dll!778237f5() ntdll.dll!778237c8() Previous Comments: [2012-05-02 05:32:13] andrey at tranvi dot info Description: Here: http://pastebin.com/SPgP5xQX php code, minified for crashing. Here: http://pastebin.com/MYZj9cPB sql code for creating database for test. First, I try create prepared query: $q=$db-prepare($sql); when, in loop, I call $q-execute() with some params. So, when I call execute() without any params - all ok. With 1 or 2 simple parameters - all ok too. When parameters is array of 11 elements, PHP core crash. Under debug version, it's write this log: [Wed May 02 10:11:46 2012] [error] [client 127.0.0.1] PHP Warning: String is not zero-terminated (String is not zero-terminated (ZZZ E\xc2'\x1eZZ)\xf0\x15d\x10\xc4\x01) (source: c:\\php-sdk\\php53dev\\vc9\\x86\\zend\\zend_execute_api.c:447) in D:\\test\\yii\\testing\\test_niokr.php on line 107, referer: http://localhost/testing/ I tested it under php5.3.10, php5.3.11 (binary download from official site) and sself build 5.3.11 with VC9,thread safe, debug version Release version simple crash. Debug version write many warnings, and crash too. Test script: --- Here: http://pastebin.com/SPgP5xQX php code, minified for crashing. Here: http://pastebin.com/MYZj9cPB sql code -- Edit this bug report at https://bugs.php.net/bug.php?id=61895edit=1
Bug #61895 [Opn]: PHP core crash when call $pdoStmt-execute($array_params) with PDO_Firebird
Edit report at https://bugs.php.net/bug.php?id=61895edit=1
ID: 61895
User updated by:andrey at tranvi dot info
Reported by:andrey at tranvi dot info
Summary:PHP core crash when call
$pdoStmt-execute($array_params) with PDO_Firebird
Status: Open
Type: Bug
Package:PDO related
Operating System: Windows
PHP Version:5.3.11
Block user comment: N
Private report: N
New Comment:
If I create new PDOStatement, and free in loop, like this:
foreach ($data as $item)
{
$q=$db-prepare($sql);
$q-execute(array(:NIOKR_TYPE=$type,:INV_NO=$item[0],:NAME=$item[1],
:CREATOR=$item[2],:N_DOG=$item[3],:AUTHOR=$item[4],
:AYEAR=$item[5],:CITY=$item[6],:ANNOTATION=$item[7],
:ACOUNT=$item[8],:GRIF=$item[9],:ACOMMENT=$item[10]));
$q=null;
}
PHP crash in another place.
With this backtrace:
php5ts_debug.dll!zend_mm_check_ptr(_zend_mm_heap * heap=0x01941c38,
void * ptr=0x025e6b68, int silent=0, char * __zend_filename=0x10587080,
unsigned int __zend_lineno=447, char * __zend_orig_filename=0x10592b18,
unsigned int __zend_orig_lineno=36) СÑÑока 1357 + 0x12 Ð±Ð°Ð¹Ñ C
php5ts_debug.dll!zend_mm_check_ptr(_zend_mm_heap * heap=0x01941c38,
void * ptr=0x025e6b68, int silent=1, char * __zend_filename=0x10587080,
unsigned int __zend_lineno=447, char * __zend_orig_filename=0x10592b18,
unsigned int __zend_orig_lineno=36) СÑÑока 1352 + 0x1f Ð±Ð°Ð¹Ñ C
php5ts_debug.dll!_zend_mm_free_int(_zend_mm_heap * heap=0x01941c38,
void * p=0x025e6b68, char * __zend_filename=0x10587080, unsigned int
__zend_lineno=447, char * __zend_orig_filename=0x10592b18, unsigned int
__zend_orig_lineno=36) СÑÑока 1993 + 0x1f Ð±Ð°Ð¹Ñ C
php5ts_debug.dll!_efree(void * ptr=0x025e6b68, char *
__zend_filename=0x10587080, unsigned int __zend_lineno=447, char *
__zend_orig_filename=0x10592b18, unsigned int __zend_orig_lineno=36)
СÑÑока 2361 + 0x2b байÑC
php5ts_debug.dll!_zval_dtor_func(_zval_struct * zvalue=0x025e5848, char
* __zend_filename=0x10587080, unsigned int __zend_lineno=447) СÑÑока 36
+ 0x29 Ð±Ð°Ð¹Ñ C
php5ts_debug.dll!_zval_dtor(_zval_struct * zvalue=0x025e5848, char *
__zend_filename=0x10587080, unsigned int __zend_lineno=447) СÑÑока 35 +
0x11 Ð±Ð°Ð¹Ñ C
php5ts_debug.dll!_zval_ptr_dtor(_zval_struct * * zval_ptr=0x025e53e8,
char * __zend_filename=0x1064d5dc, unsigned int __zend_lineno=293)
СÑÑока 447 + 0x17 Ð±Ð°Ð¹Ñ C
php5ts_debug.dll!param_dtor(void * data=0x025e53d8) СÑÑока 293 +
0x1a Ð±Ð°Ð¹Ñ C
php5ts_debug.dll!zend_hash_destroy(_hashtable * ht=0x025e58d8)
СÑÑока 529 + 0x11 байÑC
php5ts_debug.dll!free_statement(_pdo_stmt_t * stmt=0x025e2e38, void * *
* tsrm_ls=0x02833f98) СÑÑока 2390 + 0xc Ð±Ð°Ð¹Ñ C
php5ts_debug.dll!php_pdo_stmt_delref(_pdo_stmt_t * stmt=0x025e2e38,
void * * * tsrm_ls=0x02833f98) СÑÑока 2448 + 0xd байÑC
php5ts_debug.dll!pdo_dbstmt_free_storage(_pdo_stmt_t * stmt=0x025e2e38,
void * * * tsrm_ls=0x02833f98) СÑÑока 2454 + 0xd байÑC
php5ts_debug.dll!zend_objects_store_del_ref_by_handle_ex(unsigned int
handle=2, const _zend_object_handlers * handlers=0x10797860, void * * *
tsrm_ls=0x02833f98) СÑÑока 220 + 0x14 Ð±Ð°Ð¹Ñ C
php5ts_debug.dll!zend_objects_store_del_ref(_zval_struct *
zobject=0x00c1f49c, void * * * tsrm_ls=0x02833f98) СÑÑока 172 + 0x14
Ð±Ð°Ð¹Ñ C
php5ts_debug.dll!_zval_dtor_func(_zval_struct * zvalue=0x00c1f49c, char
* __zend_filename=0x10586530, unsigned int __zend_lineno=703) СÑÑока 52
+ 0x15 Ð±Ð°Ð¹Ñ C
php5ts_debug.dll!_zval_dtor(_zval_struct * zvalue=0x00c1f49c, char *
__zend_filename=0x10586530, unsigned int __zend_lineno=703) СÑÑока 35 +
0x11 Ð±Ð°Ð¹Ñ C
php5ts_debug.dll!zend_assign_to_variable(_zval_struct * *
variable_ptr_ptr=0x025e4754, _zval_struct * value=0x02560570, int is_tmp_var=0,
void * * * tsrm_ls=0x02833f98) СÑÑока 703 + 0x17 Ð±Ð°Ð¹Ñ C
php5ts_debug.dll!ZEND_ASSIGN_SPEC_CV_CONST_HANDLER(_zend_execute_data *
execute_data=0x025806e8, void * * * tsrm_ls=0x02833f98) СÑÑока 24163 +
0x13 Ð±Ð°Ð¹Ñ C
php5ts_debug.dll!execute(_zend_op_array * op_array=0x02e938f0, void * *
* tsrm_ls=0x02833f98) СÑÑока 107 + 0x11 Ð±Ð°Ð¹Ñ C
php5ts_debug.dll!zend_execute_scripts(int type=8, void * * *
tsrm_ls=0x02833f98, _zval_struct * * retval=0x, int file_count=3, ...)
СÑÑока 1236 + 0x21 Ð±Ð°Ð¹Ñ C
php5ts_debug.dll!php_execute_script(_zend_file_handle *
primary_file=0x00c1fed8, void * * * tsrm_ls=0x02833f98) СÑÑока 2308 +
0x1b Ð±Ð°Ð¹Ñ C
Bug #61537 [Csd-ReO]: json_encode() incorrectly truncates/discards information
Edit report at https://bugs.php.net/bug.php?id=61537edit=1 ID: 61537 Updated by: s...@php.net Reported by:j...@php.net Summary:json_encode() incorrectly truncates/discards information -Status: Closed +Status: Re-Opened Type: Bug Package:JSON related Operating System: all PHP Version:5.4.0 Assigned To:aharvey Block user comment: N Private report: N New Comment: Sorry, the fix wasn't correct, had to revert it. Please correct the wrong things and reapply. Previous Comments: [2012-05-02 07:09:53] s...@php.net Automatic comment on behalf of stas Revision: http://git.php.net/?p=php-src.git;a=commit;h=7bbd5521d28ee77c5a8df80174f52dad0112e872 Log: Revert quot;Fix bug #61537 (json_encode() incorrectly truncates/discards information) andquot; [2012-04-12 10:03:35] johan...@php.net Automatic comment on behalf of a...@pwd.net.au Revision: http://git.php.net/?p=php-src.git;a=commit;h=3f3ad30c50c32327e723046bcc6649d05dd9236a Log: Fix bug #61537 (json_encode() incorrectly truncates/discards information) and remove a test case that's now mooted by this fix. [2012-04-11 00:44:38] ahar...@php.net 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. [2012-04-11 00:44:24] ahar...@php.net Automatic comment on behalf of a...@pwd.net.au Revision: http://git.php.net/?p=php-src.git;a=commit;h=cb2a1c71c96d7c9b2ee03d77beae0c8e0d385f1b Log: Fix bug #61537 (json_encode() incorrectly truncates/discards information) and remove a test case that's now mooted by this fix. [2012-04-11 00:44:23] ahar...@php.net Automatic comment on behalf of a...@pwd.net.au Revision: http://git.php.net/?p=php-src.git;a=commit;h=3f3ad30c50c32327e723046bcc6649d05dd9236a Log: Fix bug #61537 (json_encode() incorrectly truncates/discards information) and remove a test case that's now mooted by this fix. 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 https://bugs.php.net/bug.php?id=61537 -- Edit this bug report at https://bugs.php.net/bug.php?id=61537edit=1
Bug #61196 [Opn-Fbk]: Unable to load dynamic library, undefined symbol
Edit report at https://bugs.php.net/bug.php?id=61196edit=1 ID: 61196 Updated by: u...@php.net Reported by:floren at yqed dot com Summary:Unable to load dynamic library, undefined symbol -Status: Open +Status: Feedback Type: Bug Package:Dynamic loading Operating System: CentOS 5.7 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: There seem to be multiple build targets in your script. Please, paste the one into a bug system comment that leads to the error. Thanks. Previous Comments: [2012-02-27 20:00:57] floren at yqed dot com Please note the --enable-mysqlnd, present into build() function. I'm forced to use it, or else the mysqli related functions are not available into phpinfo(). I obtain the same results, if I force to yes the PHP_MYSQLND_ENABLED variable: PHP_MYSQLND_ENABLED=yes export PHP_MYSQLND_ENABLED [2012-02-27 19:53:30] floren at yqed dot com Description: I compiled successfully PHP with the following configuration: http://pastie.org/3474406 Everything works as expected, except when I run PHP from command line. I was wondering if I missed something, thank you for your help. Test script: --- # php -r 'echo 1;' PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/mysql.so' - /usr/lib64/php/modules/mysql.so: undefined symbol: _mysqlnd_fetch_lengths in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/mysqli.so' - /usr/lib64/php/modules/mysqli.so: undefined symbol: mysqlnd_get_client_version in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/pdo_mysql.so' - /usr/lib64/php/modules/pdo_mysql.so: undefined symbol: mysqlnd_allocator in Unknown on line 0 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=61196edit=1
Req #60716 [Opn]: Ability to set PDO connection timeout in milliseconds
Edit report at https://bugs.php.net/bug.php?id=60716edit=1 ID: 60716 Updated by: u...@php.net Reported by:markrose at markrose dot ca Summary:Ability to set PDO connection timeout in milliseconds Status: Open Type: Feature/Change Request Package:PDO related Operating System: n/a PHP Version:5.4.0RC5 Block user comment: N Private report: N New Comment: For the MySQL part this can be considered Bogus/Not a bug because PHP is the wrong place to ask for it. Please, file a bug at MySQL. The underlying MySQL C API does not offer sub second granularity for setting the connect timeout. If it was to be fixed, it should be done at the lowest level which is the MySQL C API. No matter whether we are talking mysqlnd or MySQL Client Library (libmysql). See also http://dev.mysql.com/doc/refman/5.6/en/mysql-options.html and http://blog.ulf-wendel.de/?p=273 For the PDO part, I am not too keen of driver specific settings. What's the purpose of PDO if not providing an abstraction for it... However, for years now PDO seems kind of neglected, nobody feeling too much responsible for it. Previous Comments: [2012-01-11 17:20:38] markrose at markrose dot ca Description: I'd like the ability to set PDO's connection timeout (to MySQL specifically) in milliseconds. The lowest the timeout can current be set to is 1 second, which is an extremely long time to wait for a database machine to reply. I run a synchronously replicated MySQL environment (Galera), and I'd like to be able to move on to the next machine if the database doesn't respond in say, 10 ms. Instead, PHP waits one second. This reduces the throughput of my PHP scripts from several hundred per second to only a handful per second, severely impacting performance and quickly exhausting the PHP thread pool, leading to timeouts. -- Edit this bug report at https://bugs.php.net/bug.php?id=60716edit=1
Bug #61411 [Opn]: PDO Segfaults with PERSISTENT == TRUE EMULATE_PREPARES == FALSE
Edit report at https://bugs.php.net/bug.php?id=61411edit=1
ID: 61411
Updated by: u...@php.net
Reported by:julien at palard dot fr
Summary:PDO Segfaults with PERSISTENT == TRUE
EMULATE_PREPARES == FALSE
Status: Open
Type: Bug
Package:PDO related
Operating System: Linux 2.6.32-5-amd64
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
Andrey,
do you think we should mnd_p*alloc(.., .., stmt-persistent) here?
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/mysqlnd/mysqlnd_ps.c?annotate=321634
1624if (!stmt-result_bind) {
1625andrey 289028 stmt-result_bind = mnd_ecalloc(stmt-field_count,
sizeof(MYSQLND_RESULT_BIND));
1626andrey 258383 } else {
1627andrey 289028 stmt-result_bind = mnd_erealloc(stmt-result_bind,
stmt-field_count * sizeof(MYSQLND_RESULT_BIND));
1628andrey 258383 }
Previous Comments:
[2012-03-16 09:16:27] julien at palard dot fr
Description:
PDO Segfaults or hangs when a statement is executed with both ATTR_PERSISTENT
=
TRUE and ATTR_EMULATE_PREPARES = FALSE
The exact bug is actually :
*** glibc detected *** /usr/local/php-5.4.0/bin/php: free(): invalid pointer:
0x7ff976ee84c8 ***
But from my tests yesterday I have seen a segfault and a double free, that I
can't reproduce today, only the invalid pointer.
Playing with PERSISTENT and EMULATE_PREPARE with the given test script give :
| ATTR_PERSISENT | ATTR_EMULATE_PREPARES | WORKS |
| FALSE | FALSE |YES |
| FALSE | TRUE |YES |
| TRUE | FALSE | free() invalid pointer |
| TRUE | TRUE |YES |
Configure command :
./configure' '--enable-fpm' '--prefix=/usr/local/php-5.4.0'
'--enable-mbstring'
'--enable-gd-native-ttf' '--enable-zip' '--with-mcrypt' '--with-openssl' '--
with-gd' '--with-jpeg-dir=/usr/lib' '--with-freetype-dir' '--with-curl' '--with-
pcre-regex' '--with-gettext' '--without-sqlite' '--without-sqlite3' '--with-pdo-
mysql=mysqlnd' '--disable-rpath' '--disable-debug' '--disable-fileinfo' '--
without-pdo-sqlite' '--disable-phar' '--disable-posix' '--disable-tokenizer' '--
disable-xmlreader' '--disable-xmlwriter' '--without-pear'
Same bug reproduced in php 5.3.8 and php 5.3.10
Test script:
---
?php
$options = array(PDO::ATTR_PERSISTENT = TRUE,
PDO::ATTR_EMULATE_PREPARES = FALSE);
$pdo = new PDO('mysql:host=sql;dbname=??;charset=utf8',
'??', '??', $options);
$statement = $pdo-prepare(SELECT count(*) from a_table);
$statement-execute();
foreach ($statement as $line)
var_dump($line);
Expected result:
I expect PHP not to segfault
Actual result:
--
*** glibc detected *** /usr/local/php-5.4.0/bin/php: free(): invalid pointer:
0x7ff976ee84c8 ***
--
Edit this bug report at https://bugs.php.net/bug.php?id=61411edit=1
Bug #61827 [Asn-Csd]: incorrect \e processing on Windows
Edit report at https://bugs.php.net/bug.php?id=61827edit=1 ID: 61827 Updated by: a...@php.net Reported by:a...@php.net Summary:incorrect \e processing on Windows -Status: Assigned +Status: Closed Type: Bug Package:Scripting Engine problem Operating System: windows PHP Version:5.4.0 Assigned To:felipe Block user comment: N Private report: N Previous Comments: [2012-04-30 05:24:26] paj...@php.net hi Felipe! Please use VK_ESCAPE instead. Thanks! [2012-04-29 22:38:38] fel...@php.net 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. [2012-04-29 22:37:42] fel...@php.net Automatic comment on behalf of felipe...@gmail.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=cc5b995c78038b92317b38356c9009ff80850d8b Log: - Fixed bug #61827 (incorrect \e processing on Windows) patch by: a...@php.net [2012-04-26 14:56:44] a...@php.net As a variation VK_ESCAPE or 0x1b could be used to represent \e on windows, which is equivalent to (char)27 [2012-04-23 16:35:08] a...@php.net Btw. compiling that snippet on windows there is an interesting line in the compiler out: cl esc.c Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. esc.c esc.c(5) : warning C4129: 'e' : unrecognized character escape sequence Microsoft (R) Incremental Linker Version 10.00.40219.01 Copyright (C) Microsoft Corporation. All rights reserved. /out:esc.exe esc.obj 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 https://bugs.php.net/bug.php?id=61827 -- Edit this bug report at https://bugs.php.net/bug.php?id=61827edit=1
Bug #61814 [Opn-Csd]: ext\standard\tests\strings\strspn_variation6.phpt fails
Edit report at https://bugs.php.net/bug.php?id=61814edit=1 ID: 61814 Updated by: a...@php.net Reported by:a...@php.net Summary:ext\standard\tests\strings\strspn_variation6.phpt fails -Status: Open +Status: Closed Type: Bug Package:*General Issues Operating System: windows PHP Version:5.4Git-2012-04-22 (snap) -Assigned To: +Assigned To:ab Block user comment: N Private report: N 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2012-04-23 15:39:19] a...@php.net see bug 61827 for further infos [2012-04-23 09:34:04] a...@php.net A simple reproduce case for this, Linux: php -r '$s = hello123world456; $m = fl\t\eh ; var_dump(strspn($s,$m));' int(1) Windows: php.exe -r $s = \hello123world456\; $m = \fl\t\eh \; var_dump(strspn($s,$m)); int(4) It looks somehow related to the bug 61813. [2012-04-22 12:06:20] a...@php.net Description: Test diff: 047+ int(4) 047- int(1) 059+ int(4) 059- int(1) 071+ int(4) 071- int(1) 083+ int(4) 083- int(1) Expected result: test pass Actual result: -- test diff -- Edit this bug report at https://bugs.php.net/bug.php?id=61814edit=1
Bug #61813 [Opn-Csd]: ext\standard\tests\strings\strrchr_variation5.phpt fails
Edit report at https://bugs.php.net/bug.php?id=61813edit=1 ID: 61813 Updated by: a...@php.net Reported by:a...@php.net Summary:ext\standard\tests\strings\strrchr_variation5.phpt fails -Status: Open +Status: Closed Type: Bug Package:*General Issues Operating System: windows PHP Version:Irrelevant -Assigned To: +Assigned To:ab Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2012-04-23 15:38:55] a...@php.net the patch is wrong, please see bug 61827 for further infos [2012-04-23 08:09:25] a...@php.net The windows terminal just turns '\e' into 'e'. The test was duplicated and adopted for windows. [2012-04-23 08:07:47] a...@php.net The following patch has been added/updated: Patch Name: 61813.diff Revision: 1335168467 URL: https://bugs.php.net/patch-display.php?bug=61813patch=61813.diffrevision=1335168467 [2012-04-22 11:45:48] a...@php.net Description: Test diff: 003+ escape \seque 003- ^[scape \seque 008+ escape \seque 008- ^[scape \seque 013+ escape \seque 013- ^[scape \seque Currently this fails only on the ofissial 5.4 windows snaps. However it fails on my 5.3 and 5.4 custom builds, which sounds more logic to me. The reason for the fail is most likely that \e is used as an escape character on windows. Going through proc_open and grabbing the test out hoses the \e's . Expected result: test pass Actual result: -- test fail -- Edit this bug report at https://bugs.php.net/bug.php?id=61813edit=1
Bug #60930 [Opn-Nab]: PDO exec
Edit report at https://bugs.php.net/bug.php?id=60930edit=1 ID: 60930 Updated by: u...@php.net Reported by:lenzai2004-dev at yahoo dot fr Summary:PDO exec -Status: Open +Status: Not a bug Type: Bug Package:PDO related Operating System: Ubuntu 11.10 64bits PHP Version:5.3.9 Block user comment: N Private report: N New Comment: There is no bug here. Do as the message says and everything works fine. It is not possible to run another statement on a MySQL line prior to fetching the results. By default - as the message says - there is no implicit fetch of results. Thus, you must explicitly fetch them. Previous Comments: [2012-01-30 01:26:19] lenzai2004-dev at yahoo dot fr Description: SQL statement that return or should return a statement could leave an open cursor that cannot be closed. This bug is related to the following previous reports https://bugs.php.net/bug.php?id=36347 https://bugs.php.net/bug.php?id=34499 https://bugs.php.net/bug.php?id=42499 It's been reported that sql statement that do return result could cause this issue in non trivial situations. This report also highlight that statement returning empty result set could also cause the issue. Test script: --- $dbh = new PDO(mysql:your connection string, '', ''); echo $dbh-exec(SELECT * FROM cube where false); echo $dbh-exec(SELECT * FROM cube where false); print_r($dbh-errorInfo()); Expected result: 00 Actual result: -- 0Array ( [0] = HY000 [1] = 2014 [2] = Cannot execute queries while other unbuffered queries are active. Consider using PDOStatement::fetchAll(). Alternatively, if your code is only ever going to run against mysql, you may enable query buffering by setting the PDO:: MYSQL_ATTR_USE_BUFFERED_QUERY attribute. ) -- Edit this bug report at https://bugs.php.net/bug.php?id=60930edit=1
Bug #60840 [Asn]: undefined symbol: mysqlnd_debug_std_no_trace_funcs
Edit report at https://bugs.php.net/bug.php?id=60840edit=1 ID: 60840 Updated by: u...@php.net Reported by:public at grik dot net Summary:undefined symbol: mysqlnd_debug_std_no_trace_funcs Status: Assigned Type: Bug Package:PDO related Operating System: linux PHP Version:5.4SVN-2012-01-22 (snap) -Assigned To:uw +Assigned To:mysql Block user comment: N Private report: N New Comment: Don't assign to individuals if you mean mysql. Previous Comments: [2012-04-03 05:46:53] luiz dot fk at gmail dot com Hi... same here: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/extensions/debug-non-zts-20100525/pdo_mysql.so' - /usr/lib64/extensions/debug-non-zts-20100525/pdo_mysql.so: undefined symbol: mysqlnd_debug_std_no_trace_funcs in Unknown on line 0 Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/extensions/debug-non-zts-20100525/pdo_mysql.so' - /usr/lib64/extensions/debug-non-zts-20100525/pdo_mysql.so: undefined symbol: mysqlnd_debug_std_no_trace_funcs in Unknown on line 0 [2012-01-22 20:02:35] public at grik dot net I tried to compile without mysqlnd driver: # cd ext/pdo_mysql # ./configure --with-pdo-mysql=/usr checking for mysql_config... /usr/bin/mysql_config # make; make install #php undefined symbol: mysqlnd_debug_std_no_trace_funcs same issue, even when mysqlnd is not used [2012-01-22 18:58:33] public at grik dot net Description: I built PHP 5.4 from sources in debug mode with pdo_mysql extension as shared, compiled successfully, but when I starting php I get the startup warning. My configure command: './configure' \ '--prefix=/usr/local' \ '--sysconfdir=/etc' \ '--with-config-file-path=/etc' \ '--with-mysql=shared,mysqlnd' \ '--with-mysqli=shared,mysqlnd' \ '--with-pdo-mysql=shared,mysqlnd' \ --enable-fpm \ --enable-debug Test script: --- just running from command line Actual result: -- # php Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/debug-non-zts-20100525/pdo_mysql.so' - /usr/local/lib/php/extensions/debug-non-zts-20100525/pdo_mysql.so: undefined symbol: mysqlnd_debug_std_no_trace_funcs in Unknown on line 0 -- Edit this bug report at https://bugs.php.net/bug.php?id=60840edit=1
Bug #55334 [Asn]: MySQLi make mod_php crash on stress test
Edit report at https://bugs.php.net/bug.php?id=55334edit=1 ID: 55334 Updated by: johan...@php.net Reported by:bruno at chalopin dot fr Summary:MySQLi make mod_php crash on stress test Status: Assigned Type: Bug Package:MySQLi related Operating System: Windows 2008r2 x64 PHP Version:5.3.7RC4 -Assigned To:johannes +Assigned To:mattficken Block user comment: N Private report: N New Comment: Matt, can you give it a new run. The change http://git.php.net/?p=php-src.git;a=commit;h=ea3e0d5a7370df63af9372780b91a749fda773b1 which is in 5.4.1 should fix the issue for 5.4. See also http://news.php.net/php.internals/59353 I wasn't able to see an issue neither in 5.3 nor 5.4 after having a 64-way Solaris machine running for a few hours. For Windows I did only a shorter test on a 4-way machine. Previous Comments: [2012-04-08 22:19:22] ricardo dot nuno dot rodrigues at hotmail dot com Hi there, In PHP 5.4 TS VC9 (Win) I have the same problem. Under stress goes down. With file mysql_test.php: ?php mysqli_init(); ? Under: ab -n 1 -c 50 http://127.0.0.1/mysql_test.php It restart server (apache 2.2.21). Sometimes creates a delay. Under xdebug there's a big time to connect. Thanks Ricardo [2012-03-12 17:21:41] paj...@php.net Johannes, See last comment, I can also still reproduce it locally (dual quad). [2012-03-09 23:08:26] mattfic...@php.net To repro this problem, your test environment needs to have 4+ cpus, which the environment I was previously using didn't have. [2012-03-09 19:07:38] mattfic...@php.net Closing bug [2012-03-09 19:03:14] mattfic...@php.net Using 5_3 r324027, with Apache 2.2 on Windows 2008r2sp0, I can no longer reproduce this bug. I think this bug is fixed. 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 https://bugs.php.net/bug.php?id=55334 -- Edit this bug report at https://bugs.php.net/bug.php?id=55334edit=1
Bug #61516 [Com]: PDOStatement::errorInfo returning NULL for driver code and message
Edit report at https://bugs.php.net/bug.php?id=61516edit=1
ID: 61516
Comment by: julien at palard dot fr
Reported by:julien at palard dot fr
Summary:PDOStatement::errorInfo returning NULL for driver
code and message
Status: Open
Type: Bug
Package:PDO related
Operating System: Linux 2.6.32-5-amd64
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
u...@php.net, I think that one can expect to have as much as possible
informations about an error, and that it's not fair to provide different level
of precision to one querying the error description from one way.
Just think about those who just didn't spotted the difference or those who
simply don't want to use ERRMODE_WARNING, they will have harder times to fix
their SQL bugs, that's not a good thing. I personally think this should be
fixed.
Previous Comments:
[2012-04-30 16:39:38] u...@php.net
The PDO warning is based on a static look-up table compiled into the PDO core.
That means, it is out of control of any PDO driver. A SQL code reported by a
driver is translated into whatever message the PDO core likes.
Any PDO driver is free to provide an internal callback to update the contents
of the return value of errorInfo(). Providing an internal callback is not
mandatory.
Due to the different source of the error message one must not expect error
messages to be equal. At the end of the day: this is PDO...
[2012-03-26 16:49:00] julien at palard dot fr
Description:
While using not emulated prepared statement against MySQL 5.5, warnings (using
ERRMODE_WARNING) are more verbose than errorInfo(). With prepared queries,
errorInfo return (string, NULL, NULL).
This fact is true with or without ERRMODE_WARNING.
And this fact is also true, but different while using standard queries :
What the warning give me :
{{{
[WARNING] PDO::query() [a href='pdo.query'pdo.query/a]: SQLSTATE[23000]:
Integrity constraint violation: 1062 Duplicate entry '83-27
7727' for key 'UNIQUE'
}}}
What I got from errorInfo()[2] (Missing the Integrity constraint violation:
string, built client side from error code ?) :
{{{
Duplicate entry '83-277727' for key 'UNIQUE'
}}}
Test script:
---
?php
class My_PDOStatement extends PDOStatement
{
public function execute($input_parameters = NULL)
{
$res = parent::execute($input_parameters);
if ($res === FALSE)
var_dump($this-errorInfo());
return $res;
}
}
$options = array(PDO::ATTR_PERSISTENT = FALSE,
PDO::ATTR_ERRMODE = PDO::ERRMODE_WARNING,
PDO::ATTR_EMULATE_PREPARES = FALSE,
PDO::ATTR_DEFAULT_FETCH_MODE = PDO::FETCH_ASSOC,
PDO::ATTR_STATEMENT_CLASS = array('My_PDOStatement'));
$pdo = new PDO(...);
$stmt = $pdo-prepare(SELECT :a + :a);
$stmt-execute(array('a' = 1)); // Willingly generate 'Invalid parameter
number'
var_dump($stmt-fetchAll());
Expected result:
I Expect errorInfo() to return error messages.
Actual result:
--
errorInfo() in this specific case return (string, NULL, NULL).
--
Edit this bug report at https://bugs.php.net/bug.php?id=61516edit=1
Bug #60930 [Nab]: PDO exec
Edit report at https://bugs.php.net/bug.php?id=60930edit=1 ID: 60930 User updated by:lenzai2004-dev at yahoo dot fr Reported by:lenzai2004-dev at yahoo dot fr Summary:PDO exec Status: Not a bug Type: Bug Package:PDO related Operating System: Ubuntu 11.10 64bits PHP Version:5.3.9 Block user comment: N Private report: N New Comment: You are right , this more of API design/enhancement request. the current behaivour is very hard to debug because the second statement raise an error caused by the first one. it does not tell what was the SQL statement or ID it does not tell which line in php source code created thsi statement. If the 2 statements are in unrelated location in source code it makes this situation almost impossible to debug. Even worse if the SQL statement was generated dynamically or comes external input. Previous Comments: [2012-05-02 09:27:23] u...@php.net There is no bug here. Do as the message says and everything works fine. It is not possible to run another statement on a MySQL line prior to fetching the results. By default - as the message says - there is no implicit fetch of results. Thus, you must explicitly fetch them. [2012-01-30 01:26:19] lenzai2004-dev at yahoo dot fr Description: SQL statement that return or should return a statement could leave an open cursor that cannot be closed. This bug is related to the following previous reports https://bugs.php.net/bug.php?id=36347 https://bugs.php.net/bug.php?id=34499 https://bugs.php.net/bug.php?id=42499 It's been reported that sql statement that do return result could cause this issue in non trivial situations. This report also highlight that statement returning empty result set could also cause the issue. Test script: --- $dbh = new PDO(mysql:your connection string, '', ''); echo $dbh-exec(SELECT * FROM cube where false); echo $dbh-exec(SELECT * FROM cube where false); print_r($dbh-errorInfo()); Expected result: 00 Actual result: -- 0Array ( [0] = HY000 [1] = 2014 [2] = Cannot execute queries while other unbuffered queries are active. Consider using PDOStatement::fetchAll(). Alternatively, if your code is only ever going to run against mysql, you may enable query buffering by setting the PDO:: MYSQL_ATTR_USE_BUFFERED_QUERY attribute. ) -- Edit this bug report at https://bugs.php.net/bug.php?id=60930edit=1
Req #61887 [Opn-Nab]: Behaviour of function given to usort
Edit report at https://bugs.php.net/bug.php?id=61887edit=1 ID: 61887 Updated by: johan...@php.net Reported by:vorcak dot jan at gmail dot com Summary:Behaviour of function given to usort -Status: Open +Status: Not a bug Type: Feature/Change Request Package:*General Issues PHP Version:Irrelevant Block user comment: N Private report: N New Comment: The documentation says: The comparison function must return an integer less than, equal to, or greater than zero if the first argument is considered to be respectively less than, equal to, or greater than the second. The implementation is using return retval 0 ? -1 : retval 0 ? 1 : 0; So your request is already fullfilled. Previous Comments: [2012-05-01 07:42:22] vorcak dot jan at gmail dot com Description: If you try to sort and array with the custom function using usort, you have to return -1, 0 or 1. It would be nice if user can return any integer and usort function would decide based on the sgn() value // after few years programming in Python/Java I had problems why my code doesn't work, because I just returned value $a-$b not sgn($a-$b) Expected result: I'd expect usort function to work with any integer, not just -1, 0, 1 Actual result: -- Usort function shuffle the array, it doesn't give me any warning -- Edit this bug report at https://bugs.php.net/bug.php?id=61887edit=1
Bug #60665 [Opn]: call to empty() on NULL result using PDO::FETCH_LAZY returns false
Edit report at https://bugs.php.net/bug.php?id=60665edit=1
ID: 60665
Updated by: u...@php.net
Reported by:denaje at gmail dot com
Summary:call to empty() on NULL result using PDO::FETCH_LAZY
returns false
Status: Open
Type: Bug
Package:PDO related
Operating System: Ubuntu Linux / Windows 7
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
This is not MySQL specific. Can be reproduced with SQLite.
$pdo = new PDO('sqlite::memory');
$statement = $pdo-prepare(SELECT NULL AS _something);
$statement-execute();
var_dump($row = $statement-fetch(PDO::FETCH_LAZY));
var_dump($row-_something);
var_dump(empty($row-_something));
$statement = $pdo-prepare(SELECT NULL);
$statement-execute();
var_dump($row = $statement-fetch(PDO::FETCH_ASSOC));
var_dump($row['_something']);
var_dump(empty($row['_something']));
Previous Comments:
[2012-01-05 14:56:35] denaje at gmail dot com
Description:
PHP 5.3.8 (on both Ubuntu Linux and Windows 7)
./configure --with-pdo-mysql
No changes to php.ini
When fetching rows from a MySQL database using PDO with the default fetch
method
FETCH_LAZY, the empty() function returns false on NULL values in the database.
This behavior does not exist when using other fetch methods (such as FETCH_OBJ
or
FETCH_ASSOC).
Test script:
---
$row = $stmt-fetch(PDO::FETCH_LAZY);
echo $row-Address2.\n; // RIGHT: outputs ''
var_dump($row-Address2); // RIGHT: outputs 'NULL'
var_dump(!$row-Address2);// RIGHT: outputs 'bool(true)'
var_dump(!!$row-Address2); // RIGHT: outputs 'bool(false)'
echo empty($row-Address2).\n; // WRONG: outputs ''
var_dump(empty($row-Address2)); // WRONG: outputs 'bool(false)'
var_dump(empty($row['Address2']));// WRONG: outputs 'bool(false)'
$var = $row['Address2'];
var_dump($var); // RIGHT: outputs 'NULL'
var_dump(empty($var));// RIGHT: outputs 'bool(true)'
Expected result:
NULL
bool(true)
bool(false)
1
bool(true)
bool(true)
NULL
bool(true)
Actual result:
--
NULL
bool(true)
bool(false)
bool(false)
bool(false)
NULL
bool(true)
--
Edit this bug report at https://bugs.php.net/bug.php?id=60665edit=1
Bug #60515 [Opn]: Invalid parameter number although it is correct
Edit report at https://bugs.php.net/bug.php?id=60515edit=1
ID: 60515
Updated by: u...@php.net
Reported by:phoenixseve at freenet dot de
Summary:Invalid parameter number although it is correct
Status: Open
Type: Bug
Package:PDO related
Operating System: archlinux x86_64
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
$stmt = $pdo-prepare(UPDATE `edtable` SET `id`=:p0, `coun't()`= :p1 WHERE
`id`='24');
Your SQL is invalid.
Whatever is behind, parsing is done by the PDO core. Thus, this is most
unlikely to be MySQL specific. Parsing needs to be done as a syntax is used
that is not supported by MySQL. Replace MySQL here with any other DB that does
not support named parameters or do the same with questionmarks and a DB that
does support named parameters only but no questionmarks.
Previous Comments:
[2012-03-06 02:35:34] jeffvanb at u dot washington dot edu
This misleading error message is also thrown when you include a single-line
comment that contains a single-quote.
Example:
SELECT something
-- This valid SQL syntax shouldn't be a problem
FROM somewhere
WHERE value = :v;
PDO will tell you the parameter count is mismatched and you will pull your hair
out wondering what is wrong.
[2011-12-13 20:57:47] phoenixseve at freenet dot de
Description:
When I execute the attached test script an exception is thrown with the message:
SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not
match number of tokens
The exception is raised in the execute() line.
If you change the WHERE clause to `id`=24 there is no error message.
The same is true for this query: UPDATE `edtable` SET `id`=:p0 WHERE `id`='24'
The generated error message is obviously not correct. I don't even see why an
error message is generated as the request seems valid (although strange) to me.
Test script:
---
$createTableSql = 'EOT'
DROP TABLE IF EXISTS `edtable`;
CREATE TABLE IF NOT EXISTS `edtable` (
`id` bigint(20) NOT NULL,
`coun't()` varchar(20) NOT NULL
);
EOT;
$pdo = new PDO('mysql:host=localhost;dbname=aynte','aynte','aynte');
$pdo-setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION);
$result = $pdo-query($createTableSql);
$result-closeCursor();
$stmt = $pdo-prepare(UPDATE `edtable` SET `id`=:p0, `coun't()`= :p1 WHERE
`id`='24');
$stmt-execute(array(':p0'='2', ':p1'='b2' ));
Expected result:
No error message.
Actual result:
--
PHP Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not
match number of tokens' in /srv/http/test.php:19\nStack trace:\n#0
/srv/http/test.php(19): PDOStatement-execute(Array)\n#1 {main}\n thrown in
/srv/http/test.php on line 19
--
Edit this bug report at https://bugs.php.net/bug.php?id=60515edit=1
Bug #61446 [Opn]: Can't prepare statement without getting a result
Edit report at https://bugs.php.net/bug.php?id=61446edit=1 ID: 61446 Updated by: u...@php.net Reported by:dasmag at gmail dot com Summary:Can't prepare statement without getting a result Status: Open Type: Bug Package:MySQLi related Operating System: ubuntu 11.04 PHP Version:5.3.10 -Assigned To: +Assigned To:mysql Block user comment: N Private report: N New Comment: Very good find! Thanks! Andrey, mysqlnd sets an appropriate error message but we do not copy it into mysqli. mysqli has code for libmysql but not for mysqlnd. Maybe the copy was not needed for mysqlnd in the past? mysqlnd_stmt::prepare | info : stmt=0 | info : query=SELECT 2 | mysqlnd_conn_data::simple_command | | info : command=STMT_PREPARE ok_packet=13 silent=0 | | mysqlnd_conn_data::get_state | | mysqlnd_conn_data::get_state | | _mysqlnd_pestrdup | | | info : file=mysqlnd.c line= 326 | | | info : ptr=0x893d594 | | _mysqlnd_pestrdup | | info : adding error [Commands out of sync; you can't run this command now] to the list | | mysqlnd_conn_data::get_state | | mysqlnd_conn_data::get_state | | error: Command out of sync. State=4 | mysqlnd_conn_data::simple_command | info : FAIL mysqlnd_stmt::prepare mysqlnd_stmt::dtor Previous Comments: [2012-03-19 23:25:42] dasmag at gmail dot com Description: --- From manual page: http://www.php.net/mysqli.prepare --- There are an error if I heven't got a result from statement. Just execute the script with and without commented string. And there are no description in the documentation. Test script: --- ?php $mysqli = new mysqli(localhost); $st = $mysqli-prepare(SELECT 1); $st-execute(); // print_r($st-get_result()-fetch_assoc()); $st = $mysqli-prepare(SELECT 2); $st-execute(); ? Actual result: -- Fatal error: Call to a member function execute() on a non-objec -- Edit this bug report at https://bugs.php.net/bug.php?id=61446edit=1
[PHP-BUG] Bug #61900 [NEW]: Cannot use PDO (dblib) and mssql_ (FreeTDS) in the same script
From:
Operating system: Ubuntu 12.04
PHP version: 5.3.11
Package: PDO related
Bug Type: Bug
Bug description:Cannot use PDO (dblib) and mssql_ (FreeTDS) in the same script
Description:
When using PDO (dblib) and mssql_ (FreeTDS) in the same script, PDO will
not
throw any Exceptions.
This is apparently due to the calls to 'dberrhandle' in the FreeTDS
library:
https://github.com/php/php-src/blob/master/ext/mssql/php_mssql.c#L598
https://github.com/php/php-src/blob/master/ext/pdo_dblib/pdo_dblib.c#L205
Regardless of the order in the PHP Script, php_mssql is executed last,
which
will replace any error handler function that pdo_dblib has set.
This also seems to be the case when 'forcing' the use of multiple
connections.
Whilst using both functions is a silly thing to do, we are migrating a 9
year
old project over to PDO in a number of phases.
Test script:
---
?php
/*
* Setup an MSSQL connection (FreeTDS library)
* It does not matter if this is executed before or after the PDO object
is
* instantiated.
*/
$mssql = mssql_connect('server', 'user', 'pass');
$pdo = new PDO('dblib:host=server;dbname=db', 'user', 'pass');
$pdo-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
try
{
$pdo-query('INSERT INTO incorrecttable (abc) VALUES (123)');
echo Exception not thrown\n;
}
catch(\PDOException $exception)
{
echo Exception caught\n;
}
Expected result:
Exception caught
Actual result:
--
Warning: PDO::query(): message: Invalid object name 'incorrecttable'.
(severity
16) in /tmp/php-test/pdotest.php on line 15
Call Stack:
0.0001 631912 1. {main}() /tmp/php-test/pdotest.php:0
0.0557 633632 2. PDO-query() /tmp/php-test/pdotest.php:15
Warning: PDO::query(): General SQL Server error: Check messages from the
SQL
Server (severity 16) in /tmp/php-test/pdotest.php on line 15
Call Stack:
0.0001 631912 1. {main}() /tmp/php-test/pdotest.php:0
0.0557 633632 2. PDO-query() /tmp/php-test/pdotest.php:15
Exception not thrown
--
Edit bug report at https://bugs.php.net/bug.php?id=61900edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61900r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61900r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61900r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61900r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61900r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61900r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61900r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61900r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61900r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61900r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61900r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61900r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61900r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61900r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61900r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61900r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61900r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61900r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61900r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61900r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61900r=mysqlcfg
Bug-Req #60849 [Opn]: Too many open links not reported correctly
Edit report at https://bugs.php.net/bug.php?id=60849edit=1 ID: 60849 Updated by: u...@php.net Reported by:haavard dot pedersen at gmail dot com Summary:Too many open links not reported correctly Status: Open -Type: Bug +Type: Feature/Change Request Package:MySQLi related Operating System: Linux PHP Version:5.3.9 Block user comment: N Private report: N New Comment: This is a bit on the API design/feature request side. mysqli.max_connections is a PHP setting. It is something enforced by the API. Because it does not come from the server side, the server logic does not set an error. There is no error on the line. Thus, the wrapped C API call, mysql_connect_errno() does not return one. Error: 1040 SQLSTATE: 08004 (ER_CON_COUNT_ERROR), Message: Too many connections must not be used to hint that mysqli.max_links has been exceeded. 1040 is a server error code. One needs a client error code, if at all. For example, Error: 2000 (CR_UNKNOWN_ERROR) Message: Unknown MySQL error could be used together with message pointing to the mysqli configuration. I say if at all because one also has to ask about the semantics of mysqli_connect_errno(). Previous Comments: [2012-01-23 12:25:15] haavard dot pedersen at gmail dot com Description: The Too many links error condition does not provide any error code. The only way you can get a description of the error is via the warning output. Run test script with mysqli.max_connections = 1 to see the problem. This even breaks the documentations example for mysqli_real_connect(). Test script: --- $link1 = mysqli_init(); $m_rc1 = mysqli_real_connect($link1, 'localhost', 'dbuser', 'dbpassword', 'testdb', 8889); echo --- Opening second link ---\n; $link2 = mysqli_init(); echo mysqli_init() result : .var_export($link2, TRUE).\n; echo --- Opening second connection ---\n; $m_rc2 = mysqli_real_connect($link2, 'localhost', 'dbuser', 'dbpassword', 'testdb', 8889); echo mysqli_real_connect() result : .var_export($m_rc2, TRUE).\n; echo Error number: .var_export(mysqli_connect_errno($link2), TRUE).\n; Expected result: An error number returned on the last line. Actual result: -- Error number is 0, possibly indicating success. -- Edit this bug report at https://bugs.php.net/bug.php?id=60849edit=1
Bug #61838 [Opn-Nab]: mysqli_get_cache_stats() does nothing
Edit report at https://bugs.php.net/bug.php?id=61838edit=1 ID: 61838 Updated by: u...@php.net Reported by:jpa...@php.net Summary:mysqli_get_cache_stats() does nothing -Status: Open +Status: Not a bug Type: Bug Package:MySQL related Operating System: Linux PHP Version:5.3.10 Block user comment: N Private report: N New Comment: Good find, but... - it is marked as undocumented. Means, it can return pretty much anything, including nothing. - it is marked as deprecated. Whether this is sufficient or not, well, Docs team can decide on adding a note.I would say its OK as it is. Thus, setting to not a bug. Previous Comments: [2012-04-24 14:19:38] jpa...@php.net Description: mysqli_get_cache_stats() just return an empty array, always. It has not been implemented, but it's documented :) Test script: --- See source code of mysqli_get_cache_stats(), it always returns an empty array, whatever happens Expected result: mysqli_get_cache_stats() returns useful data Actual result: -- mysqli_get_cache_stats() is useless actually -- Edit this bug report at https://bugs.php.net/bug.php?id=61838edit=1
Bug #61838 [Nab]: mysqli_get_cache_stats() does nothing
Edit report at https://bugs.php.net/bug.php?id=61838edit=1 ID: 61838 Updated by: jpa...@php.net Reported by:jpa...@php.net Summary:mysqli_get_cache_stats() does nothing Status: Not a bug Type: Bug Package:MySQL related Operating System: Linux PHP Version:5.3.10 Block user comment: N Private report: N New Comment: So, there is no plan to implement this function at all ? Previous Comments: [2012-05-02 14:16:07] u...@php.net Good find, but... - it is marked as undocumented. Means, it can return pretty much anything, including nothing. - it is marked as deprecated. Whether this is sufficient or not, well, Docs team can decide on adding a note.I would say its OK as it is. Thus, setting to not a bug. [2012-04-24 14:19:38] jpa...@php.net Description: mysqli_get_cache_stats() just return an empty array, always. It has not been implemented, but it's documented :) Test script: --- See source code of mysqli_get_cache_stats(), it always returns an empty array, whatever happens Expected result: mysqli_get_cache_stats() returns useful data Actual result: -- mysqli_get_cache_stats() is useless actually -- Edit this bug report at https://bugs.php.net/bug.php?id=61838edit=1
[PHP-BUG] Bug #61901 [NEW]: ext\phar\tests\phar_buildfromdirectory2.phpt fails
From: ab Operating system: windows PHP version: Irrelevant Package: PHAR related Bug Type: Bug Bug description:ext\phar\tests\phar_buildfromdirectory2.phpt fails Description: Test diff: 002+ RecursiveDirectoryIterator::__construct(1,1): The system cannot find the file specified. (code: 2) 002- RecursiveDirectoryIterator::__construct(1): failed to open dir: No such file or directory Expected result: test pass Actual result: -- test fail -- Edit bug report at https://bugs.php.net/bug.php?id=61901edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61901r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61901r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61901r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61901r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61901r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61901r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61901r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61901r=needscript Try newer version: https://bugs.php.net/fix.php?id=61901r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61901r=support Expected behavior: https://bugs.php.net/fix.php?id=61901r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61901r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61901r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61901r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61901r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61901r=dst IIS Stability: https://bugs.php.net/fix.php?id=61901r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61901r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61901r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61901r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61901r=mysqlcfg
[PHP-BUG] Bug #61902 [NEW]: ext\phar\tests\phar_setsignaturealgo2.phpt falis
From: ab
Operating system: windows
PHP version: Irrelevant
Package: PHAR related
Bug Type: Bug
Bug description:ext\phar\tests\phar_setsignaturealgo2.phpt falis
Description:
Test diff:
031+ phar error: unable to write signature: unable to process private
key===DONE===
031- array(2) {
032- [hash]=
033- string(%d) %s
034- [hash_type]=
035- string(7) OpenSSL
036- }
037- ===DONE===
Expected result:
test pass
Actual result:
--
test fail
--
Edit bug report at https://bugs.php.net/bug.php?id=61902edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61902r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61902r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61902r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61902r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61902r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61902r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61902r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61902r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61902r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61902r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61902r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61902r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61902r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61902r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61902r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61902r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61902r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61902r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61902r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61902r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61902r=mysqlcfg
Bug #61536 [Opn]: when building with hardening-wrapper, mysqlnd fails with format exceptions
Edit report at https://bugs.php.net/bug.php?id=61536edit=1 ID: 61536 Updated by: u...@php.net Reported by:i dot galic at brainsware dot org Summary:when building with hardening-wrapper, mysqlnd fails with format exceptions Status: Open Type: Bug Package:MySQL related Operating System: Ubuntu PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Funny compiler... const char * const msg = Authentication data too long. Won't fit into the buffer and will be truncated. Authentication will thus fail; SET_CLIENT_ERROR(*conn-error_info, CR_UNKNOWN_ERROR, UNKNOWN_SQLSTATE, msg); php_error_docref(NULL TSRMLS_CC, E_WARNING, %s, msg); DBG_RETURN(0); Previous Comments: [2012-03-28 00:19:22] i dot galic at brainsware dot org Description: when building with hardening-wrapper, mysqlnd fails with format exceptions Test script: --- add CFLAGS=$CFLAGS -Werror=format-security Expected result: Everything builds happily. Actual result: -- php-5.4.0/ext/mysqlnd/mysqlnd_wireprotocol.c: In function âphp_mysqlnd_auth_writeâ: php-5.4.0/ext/mysqlnd/mysqlnd_wireprotocol.c:503:4: error: format not a string literal and no format arguments [-Werror=format-security] cc1: some warnings being treated as errors -- Edit this bug report at https://bugs.php.net/bug.php?id=61536edit=1
[PHP-BUG] Bug #61903 [NEW]: ext\phar\tests\tar\phar_commitwrite.phpt fails
From: ab
Operating system: windows
PHP version: Irrelevant
Package: PHAR related
Bug Type: Bug
Bug description:ext\phar\tests\tar\phar_commitwrite.phpt fails
Description:
test diff:
001+ Fatal error: Uncaught exception 'BadMethodCallException' with message
'Entry file1.txt does not exist and cannot be created: phar error: unable
to create temporary file' in
C:\snaps\php-test-pack-5.3-nts-windows-vc9-x86-rf3d86b3\ext\phar\tests\tar\phar_commitwrite.php:3
002+ Stack trace:
003+ #0
C:\snaps\php-test-pack-5.3-nts-windows-vc9-x86-rf3d86b3\ext\phar\tests\tar\phar_commitwrite.php(3):
Phar-offsetSet('file1.txt', 'hi')
004+ #1 {main}
005+ thrown in
C:\snaps\php-test-pack-5.3-nts-windows-vc9-x86-rf3d86b3\ext\phar\tests\tar\phar_commitwrite.php
on line 3
001- string(60) ?php // tar-based phar archive stub file
002- __HALT_COMPILER();
003- string(200) ?php
004- function __autoload($class)
005- {
006- include 'phar://' . str_replace('_', '/', $class);
007- }
008- Phar::mapPhar('brandnewphar.phar');
009- include 'phar://brandnewphar.phar/startup.php';
010- __HALT_COMPILER(); ?
011-
012- bool(true)
013- ===DONE===
Expected result:
test pass
Actual result:
--
test fail
--
Edit bug report at https://bugs.php.net/bug.php?id=61903edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61903r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61903r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61903r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61903r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61903r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61903r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61903r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61903r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61903r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61903r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61903r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61903r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61903r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61903r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61903r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61903r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61903r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61903r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61903r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61903r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61903r=mysqlcfg
[PHP-BUG] Bug #61904 [NEW]: ext\phar\tests\tar\phar_setsignaturealgo2.phpt fail
From: ab
Operating system: windows
PHP version: Irrelevant
Package: PHAR related
Bug Type: Bug
Bug description:ext\phar\tests\tar\phar_setsignaturealgo2.phpt fail
Description:
Test diff:
031+ phar error: unable to write signature to tar-based phar: unable to
process private key===DONE===
031- array(2) {
032- [hash]=
033- string(%d) %s
034- [hash_type]=
035- string(7) OpenSSL
036- }
037- ===DONE===
Expected result:
test pass
Actual result:
--
test fail
--
Edit bug report at https://bugs.php.net/bug.php?id=61904edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61904r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61904r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61904r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61904r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61904r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61904r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61904r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61904r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61904r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61904r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61904r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61904r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61904r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61904r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61904r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61904r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61904r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61904r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61904r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61904r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61904r=mysqlcfg
[PHP-BUG] Bug #61905 [NEW]: ext\phar\tests\zip\phar_commitwrite.phpt fails
From: ab
Operating system: windows
PHP version: Irrelevant
Package: PHAR related
Bug Type: Bug
Bug description:ext\phar\tests\zip\phar_commitwrite.phpt fails
Description:
Test diff:
001+ Fatal error: Uncaught exception 'BadMethodCallException' with message
'Entry file1.txt does not exist and cannot be created: phar error: unable
to create temporary file' in
C:\snaps\php-test-pack-5.3-nts-windows-vc9-x86-rf3d86b3\ext\phar\tests\zip\phar_commitwrite.php:3
002+ Stack trace:
003+ #0
C:\snaps\php-test-pack-5.3-nts-windows-vc9-x86-rf3d86b3\ext\phar\tests\zip\phar_commitwrite.php(3):
Phar-offsetSet('file1.txt', 'hi')
004+ #1 {main}
005+ thrown in
C:\snaps\php-test-pack-5.3-nts-windows-vc9-x86-rf3d86b3\ext\phar\tests\zip\phar_commitwrite.php
on line 3
001- string(60) ?php // zip-based phar archive stub file
002- __HALT_COMPILER();
003- string(200) ?php
004- function __autoload($class)
005- {
006- include 'phar://' . str_replace('_', '/', $class);
007- }
008- Phar::mapPhar('brandnewphar.phar');
009- include 'phar://brandnewphar.phar/startup.php';
010- __HALT_COMPILER(); ?
011-
012- bool(true)
013- ===DONE===
Expected result:
test pass
Actual result:
--
test fail
--
Edit bug report at https://bugs.php.net/bug.php?id=61905edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61905r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61905r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61905r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61905r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61905r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61905r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61905r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61905r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61905r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61905r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61905r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61905r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61905r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61905r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61905r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61905r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61905r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61905r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61905r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61905r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61905r=mysqlcfg
[PHP-BUG] Bug #61906 [NEW]: ext\phar\tests\zip\phar_setsignaturealgo2.phpt fails
From: ab Operating system: windows PHP version: Irrelevant Package: PHAR related Bug Type: Bug Bug description:ext\phar\tests\zip\phar_setsignaturealgo2.phpt fails Description: Test diff: 031+ 032+ Warning: openssl_pkey_export(): cannot get key from parameter 1 in C:\php-sdk\php53\vc9\x86\php-src\ext\phar\tests\zip\phar_setsignaturealgo2.php on line 41 033+ 034+ Warning: openssl_pkey_get_details() expects parameter 1 to be resource, boolean given in C:\php-sdk\php53\vc9\x86\php-src\ext\phar\tests\zip\phar_setsignaturealgo2.php on line 42 035- string(7) OpenSSL 039+ string(7) SHA-512 Expected result: test pass Actual result: -- test fail -- Edit bug report at https://bugs.php.net/bug.php?id=61906edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61906r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61906r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61906r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61906r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61906r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61906r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61906r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61906r=needscript Try newer version: https://bugs.php.net/fix.php?id=61906r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61906r=support Expected behavior: https://bugs.php.net/fix.php?id=61906r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61906r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61906r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61906r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61906r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61906r=dst IIS Stability: https://bugs.php.net/fix.php?id=61906r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61906r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61906r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61906r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61906r=mysqlcfg
[PHP-BUG] Bug #61909 [NEW]: PHP realpath on Windows Case Issue
From:
Operating system: Windows Vista/7
PHP version: Irrelevant
Package: Filesystem function related
Bug Type: Bug
Bug description:PHP realpath on Windows Case Issue
Description:
I have a symlink on my Windows server which was made like this:
F:\mkdir link-target
F:\mklink /D link f:\link-target
(Note the lower case f: in the symlink target)
In PHP I run this:
$dir = realpath('f:\link');
var_dump($dir);
$dir = realpath($dir);
var_dump($dir);
Which outputs:
string 'f:\link-target' (length=14)
string 'F:\link-target' (length=14)
Notice the change in case on the second realpath.
The expected output is:
string 'F:\link-target' (length=14)
string 'F:\link-target' (length=14)
Test script:
---
?php
// F:\mkdir link-target
// F:\mklink /D link f:\link-target
$dir = realpath('f:\link');
var_dump($dir);
$dir = realpath($dir);
var_dump($dir);
Expected result:
string 'F:\link-target' (length=14)
string 'F:\link-target' (length=14)
Actual result:
--
string 'f:\link-target' (length=14)
string 'F:\link-target' (length=14)
--
Edit bug report at https://bugs.php.net/bug.php?id=61909edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61909r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61909r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61909r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61909r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61909r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61909r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61909r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61909r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61909r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61909r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61909r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61909r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61909r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61909r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61909r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61909r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61909r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61909r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61909r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61909r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61909r=mysqlcfg
Bug #61909 [Com]: PHP realpath on Windows Case Issue
Edit report at https://bugs.php.net/bug.php?id=61909edit=1
ID: 61909
Comment by: david at panmedia dot co dot nz
Reported by:david at panmedia dot co dot nz
Summary:PHP realpath on Windows Case Issue
Status: Open
Type: Bug
Package:Filesystem function related
Operating System: Windows Vista/7
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
On further investigation I have noticed that on Windows symlinks are only
followed 1 level deep:
// F:\mkdir link-target
// F:\mklink /D link f:\link-target
// F:\mklink /D link2 f:\link
$dir = realpath('f:\link2');
var_dump($dir);
$dir = realpath($dir);
var_dump($dir);
$dir = realpath($dir);
var_dump($dir);
// string 'f:\link' (length=7)
// string 'f:\link-target' (length=14)
// string 'F:\link-target' (length=14)
Previous Comments:
[2012-05-02 17:37:52] david at panmedia dot co dot nz
Description:
I have a symlink on my Windows server which was made like this:
F:\mkdir link-target
F:\mklink /D link f:\link-target
(Note the lower case f: in the symlink target)
In PHP I run this:
$dir = realpath('f:\link');
var_dump($dir);
$dir = realpath($dir);
var_dump($dir);
Which outputs:
string 'f:\link-target' (length=14)
string 'F:\link-target' (length=14)
Notice the change in case on the second realpath.
The expected output is:
string 'F:\link-target' (length=14)
string 'F:\link-target' (length=14)
Test script:
---
?php
// F:\mkdir link-target
// F:\mklink /D link f:\link-target
$dir = realpath('f:\link');
var_dump($dir);
$dir = realpath($dir);
var_dump($dir);
Expected result:
string 'F:\link-target' (length=14)
string 'F:\link-target' (length=14)
Actual result:
--
string 'f:\link-target' (length=14)
string 'F:\link-target' (length=14)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61909edit=1
Bug #61902 [Opn-Csd]: ext\phar\tests\phar_setsignaturealgo2.phpt falis
Edit report at https://bugs.php.net/bug.php?id=61902edit=1
ID: 61902
Updated by: a...@php.net
Reported by:a...@php.net
Summary:ext\phar\tests\phar_setsignaturealgo2.phpt falis
-Status: Open
+Status: Closed
Type: Bug
Package:PHAR related
Operating System: windows
PHP Version:Irrelevant
-Assigned To:
+Assigned To:ab
Block user comment: N
Private report: N
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2012-05-02 14:52:06] a...@php.net
Description:
Test diff:
031+ phar error: unable to write signature: unable to process private
key===DONE===
031- array(2) {
032- [hash]=
033- string(%d) %s
034- [hash_type]=
035- string(7) OpenSSL
036- }
037- ===DONE===
Expected result:
test pass
Actual result:
--
test fail
--
Edit this bug report at https://bugs.php.net/bug.php?id=61902edit=1
Bug #60758 [Com]: require() crashes Apache
Edit report at https://bugs.php.net/bug.php?id=60758edit=1 ID: 60758 Comment by: mmoreno at pobox dot com Reported by:bugzilla33 at gmail dot com Summary:require() crashes Apache Status: Assigned Type: Bug Package:Reproducible crash Operating System: Windows PHP Version:5.4.0RC5 Assigned To:dmitry Block user comment: N Private report: N New Comment: Looks like this issue has been fixed in 5.3.11. Previous Comments: [2012-04-11 05:32:54] paj...@php.net Reminder for Dmitry now that we have the mails back on bugs :) [2012-04-11 03:11:00] mmoreno at pobox dot com Any progress on this issue? [2012-03-08 23:59:43] paj...@php.net hi Dmitry, Seems that we have it back :P [2012-03-08 18:53:57] mmoreno at pobox dot com I've confirmed this problem has NOT been fixed using this snapshot (2012-03-08): http://windows.php.net/downloads/snaps/php-5.3/r324022/php-5.3-ts-windows-vc9-x86- r324022.zip [2012-03-07 20:55:41] paj...@php.net It is already fixed in svn, use a snapshot if you like to confirm it. 5.3.11 will have the fix (5.4.0 has it). The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60758 -- Edit this bug report at https://bugs.php.net/bug.php?id=60758edit=1
Bug #61873 [Opn]: proc_get_status always returns exitcode -1
Edit report at https://bugs.php.net/bug.php?id=61873edit=1 ID: 61873 User updated by:dcb at insomniacsoft dot com Reported by:dcb at insomniacsoft dot com Summary:proc_get_status always returns exitcode -1 Status: Open Type: Bug Package:Program Execution Operating System: Linux PHP Version:5.4.1 Block user comment: N Private report: N New Comment: Ok, I think I've solved it. After some other tests I figured out it was a build config issue and in the end I narrowed it down to --enable-sigchild. I don't know why and without really understanding what it does I added that config option when I moved to php 5.4. It also breaks php 5.3. I've tested with php 5.3.6, 5.3.11 and 5.4.1 and after a clean build without --enable-sigchild proc_get_status will return the correct exitcode. I did a bit of research and found this article: https://blogs.oracle.com/opal/entry/php_oci8_signal_handling_and_e_1 Unfortunately I couldn't find the other bugs reporting this issue, but if they exist then this should be closed. Previous Comments: [2012-05-01 16:18:24] phpmpan at mpan dot pl Have you tried testing this on non-Ubuntu box? Maybe it's something that depends on Ubuntu configuration? I still don't like the fact that a second process is spawned after the one PHP is starting. The following code should also show calls to `wait` and values that are returned from processes. -- strace -f php -r '$descriptorspec = array( 0 = array(pipe, r), 1 = array(pipe, w), 2 = array(file, /tmp/error-output.txt, a) ); $p = proc_open(/tmp/te, $descriptorspec, $pipes, /tmp); sleep(1); fclose($pipes[0]);fclose($pipes[1]); $s = proc_get_status($p); print_r($s);' 21 | grep '/tmp/te\|wait' -- [2012-05-01 01:12:19] dcb at insomniacsoft dot com Well, that is returning the proper exit code. It's strange that nobody else can reproduce this while I have it happening on 2 different Ubuntu machines. One is a 10.04 and the other one is 11.10. I was thinking that it might be something else, but keep in mind that on the same machine php 5.3 does work properly and returns the correct exit code in all the tests. [2012-05-01 00:28:56] phpmpan at mpan dot pl and you the code is executing it. In other should be: and the code is executing it. In the other Sorry [2012-05-01 00:27:25] phpmpan at mpan dot pl Since no one was able to reproduce this to this point, all that can be done is debugging it somehow on your side and eliminate possible reasons. What strace output tells us here is that /tmp/te actually exists and you the code is executing it. In other case the second call to `execve` would not return 0. If it is returning 0, it means that the interpretation of /tmp/te has actually started. He's my output for comparison (snaps for 5.4 and trunk): --- [pid 7359] execve(/bin/sh, [sh, -c, /tmp/te], [/* 47 vars */] unfinished ... [pid 7359] execve(/tmp/te, [/tmp/te], [/* 46 vars */]) = 0 [pid 7359] open(/tmp/te, O_RDONLY) = 3 write(1, /tmp/te, 7/tmp/te) = 7 --- What is puzzling me is why your `sh` (pid:26199) is not replacing itself with the script. As we can see, another process (pid:26200) is spawned and it is the one that executes your script. My blind guess is that PHP receives status code from 26199, which - for some reason - is not waiting for 26200 or not passing the status code from it properly. Can you check what is this producing? --- sh -c /tmp/te echo $? --- Maybe the bug is not in PHP... [2012-04-30 23:24:42] dcb at insomniacsoft dot com Still getting -1 for /bin/ls as well I did the strace, here is output, unfortunately I have no idea how to interpret it: [pid 26199] execve(/bin/sh, [sh, -c, /tmp/te], [/* 19 vars */] unfinished ... [pid 26200] execve(/tmp/te, [/tmp/te], [/* 19 vars */]) = 0 [pid 26200] open(/tmp/te, O_RDONLY) = 3 write(1, /tmp/te, 7/tmp/te) = 7 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 https://bugs.php.net/bug.php?id=61873 -- Edit this bug report at https://bugs.php.net/bug.php?id=61873edit=1
[PHP-BUG] Bug #61915 [NEW]: incorrect associativity of ternary operator
From: Operating system: Linux,Windows PHP version: Irrelevant Package: Scripting Engine problem Bug Type: Bug Bug description:incorrect associativity of ternary operator Description: zend_language_parser.y on line 81 gives the '?:' operator left associativity when it should be right as in virtually every other language that has a ternary operator. Test script: --- $arg = 3; $food = ( ($arg == '1') ? 'Banana' : ($arg == '2') ? 'Apple' : ($arg == '3') ? 'Toast' : ($arg == '4') ? 'Cantalope' : ($arg == '5') ? 'Swiss Cheese' : 'Fig Newton Cookie' ); echo $food; Expected result: I expected to see 'Toast'. Actual result: -- The actual result is 'Swiss Cheese'. -- Edit bug report at https://bugs.php.net/bug.php?id=61915edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61915r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61915r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61915r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61915r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61915r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61915r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61915r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61915r=needscript Try newer version: https://bugs.php.net/fix.php?id=61915r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61915r=support Expected behavior: https://bugs.php.net/fix.php?id=61915r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61915r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61915r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61915r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61915r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61915r=dst IIS Stability: https://bugs.php.net/fix.php?id=61915r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61915r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61915r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61915r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61915r=mysqlcfg
Bug #61915 [Opn-Nab]: incorrect associativity of ternary operator
Edit report at https://bugs.php.net/bug.php?id=61915edit=1 ID: 61915 Updated by: johan...@php.net Reported by:iam4webwork at hotmail dot com Summary:incorrect associativity of ternary operator -Status: Open +Status: Not a bug Type: Bug Package:Scripting Engine problem Operating System: Linux,Windows PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Yes, this was an oversight when the language was defined and is documentedlike that on http://php.net/ternary (see the last note). Unfortunately we can't fix this without breaking code, which depends on the current order, in a non-obvious way. Previous Comments: [2012-05-02 22:16:24] iam4webwork at hotmail dot com Description: zend_language_parser.y on line 81 gives the '?:' operator left associativity when it should be right as in virtually every other language that has a ternary operator. Test script: --- $arg = 3; $food = ( ($arg == '1') ? 'Banana' : ($arg == '2') ? 'Apple' : ($arg == '3') ? 'Toast' : ($arg == '4') ? 'Cantalope' : ($arg == '5') ? 'Swiss Cheese' : 'Fig Newton Cookie' ); echo $food; Expected result: I expected to see 'Toast'. Actual result: -- The actual result is 'Swiss Cheese'. -- Edit this bug report at https://bugs.php.net/bug.php?id=61915edit=1
Bug #61892 [Opn-Ana]: Zend/tests/gc_029.phpt fails with ZTS mode in PHP 5.4.1
Edit report at https://bugs.php.net/bug.php?id=61892edit=1 ID: 61892 Updated by: larue...@php.net Reported by:s...@php.net Summary:Zend/tests/gc_029.phpt fails with ZTS mode in PHP 5.4.1 -Status: Open +Status: Analyzed Type: Bug Package:Testing related Operating System: Linux PHP Version:5.4.1 Block user comment: N Private report: N New Comment: @sixed I think it's okey to separate this test for ZTS and no-ZTS mode. as we talked via mail. thanks :) Previous Comments: [2012-05-01 22:22:00] s...@php.net Description: With ZTS enabled, the gc_collect_cycles() call in Zend/tests/gc_029.phpt is returning 3 instead of the expected 2. From http://qa.php.net/reports, this seems to have started in PHP 5.4.1. -- Edit this bug report at https://bugs.php.net/bug.php?id=61892edit=1
Bug #61909 [Opn]: PHP realpath on Windows Case Issue
Edit report at https://bugs.php.net/bug.php?id=61909edit=1
ID: 61909
Updated by: larue...@php.net
Reported by:david at panmedia dot co dot nz
Summary:PHP realpath on Windows Case Issue
Status: Open
Type: Bug
Package:Filesystem function related
Operating System: Windows Vista/7
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
path in windows is case insensitive..
Previous Comments:
[2012-05-02 17:46:25] david at panmedia dot co dot nz
On further investigation I have noticed that on Windows symlinks are only
followed 1 level deep:
// F:\mkdir link-target
// F:\mklink /D link f:\link-target
// F:\mklink /D link2 f:\link
$dir = realpath('f:\link2');
var_dump($dir);
$dir = realpath($dir);
var_dump($dir);
$dir = realpath($dir);
var_dump($dir);
// string 'f:\link' (length=7)
// string 'f:\link-target' (length=14)
// string 'F:\link-target' (length=14)
[2012-05-02 17:37:52] david at panmedia dot co dot nz
Description:
I have a symlink on my Windows server which was made like this:
F:\mkdir link-target
F:\mklink /D link f:\link-target
(Note the lower case f: in the symlink target)
In PHP I run this:
$dir = realpath('f:\link');
var_dump($dir);
$dir = realpath($dir);
var_dump($dir);
Which outputs:
string 'f:\link-target' (length=14)
string 'F:\link-target' (length=14)
Notice the change in case on the second realpath.
The expected output is:
string 'F:\link-target' (length=14)
string 'F:\link-target' (length=14)
Test script:
---
?php
// F:\mkdir link-target
// F:\mklink /D link f:\link-target
$dir = realpath('f:\link');
var_dump($dir);
$dir = realpath($dir);
var_dump($dir);
Expected result:
string 'F:\link-target' (length=14)
string 'F:\link-target' (length=14)
Actual result:
--
string 'f:\link-target' (length=14)
string 'F:\link-target' (length=14)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61909edit=1
Bug #61909 [Com]: PHP realpath on Windows Case Issue
Edit report at https://bugs.php.net/bug.php?id=61909edit=1
ID: 61909
Comment by: david at panmedia dot co dot nz
Reported by:david at panmedia dot co dot nz
Summary:PHP realpath on Windows Case Issue
Status: Open
Type: Bug
Package:Filesystem function related
Operating System: Windows Vista/7
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
@larue...@php.net
Well, not always. In Windows Server 2008 it can be configured.
http://technet.microsoft.com/en-us/library/cc725747.aspx
Also, the point of realpath is to return the canonicalized absolute pathname,
but it does not. Especially in the case of nested symlinks, as I pointed out in
my other comment.
You should be able to test if a path is the same by going
if (realpath('c:\path-to-link') === realpath('C:\RealPathToTarget')) ...
Previous Comments:
[2012-05-03 03:10:56] larue...@php.net
path in windows is case insensitive..
[2012-05-02 17:46:25] david at panmedia dot co dot nz
On further investigation I have noticed that on Windows symlinks are only
followed 1 level deep:
// F:\mkdir link-target
// F:\mklink /D link f:\link-target
// F:\mklink /D link2 f:\link
$dir = realpath('f:\link2');
var_dump($dir);
$dir = realpath($dir);
var_dump($dir);
$dir = realpath($dir);
var_dump($dir);
// string 'f:\link' (length=7)
// string 'f:\link-target' (length=14)
// string 'F:\link-target' (length=14)
[2012-05-02 17:37:52] david at panmedia dot co dot nz
Description:
I have a symlink on my Windows server which was made like this:
F:\mkdir link-target
F:\mklink /D link f:\link-target
(Note the lower case f: in the symlink target)
In PHP I run this:
$dir = realpath('f:\link');
var_dump($dir);
$dir = realpath($dir);
var_dump($dir);
Which outputs:
string 'f:\link-target' (length=14)
string 'F:\link-target' (length=14)
Notice the change in case on the second realpath.
The expected output is:
string 'F:\link-target' (length=14)
string 'F:\link-target' (length=14)
Test script:
---
?php
// F:\mkdir link-target
// F:\mklink /D link f:\link-target
$dir = realpath('f:\link');
var_dump($dir);
$dir = realpath($dir);
var_dump($dir);
Expected result:
string 'F:\link-target' (length=14)
string 'F:\link-target' (length=14)
Actual result:
--
string 'f:\link-target' (length=14)
string 'F:\link-target' (length=14)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61909edit=1
[PHP-BUG] Bug #61919 [NEW]: PDO DBLIB Driver is not working
From: Operating system: Linux Ubuntu PHP version: 5.3.11 Package: MSSQL related Bug Type: Bug Bug description:PDO DBLIB Driver is not working Description: Hi, As I tired to connect with MSSQL with my Linux system using PDO DBLIB Driver I am getting following error SQLSTATE[] (null) (severity 0) -- Edit bug report at https://bugs.php.net/bug.php?id=61919edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61919r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61919r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61919r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61919r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61919r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61919r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61919r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61919r=needscript Try newer version: https://bugs.php.net/fix.php?id=61919r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61919r=support Expected behavior: https://bugs.php.net/fix.php?id=61919r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61919r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61919r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61919r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61919r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61919r=dst IIS Stability: https://bugs.php.net/fix.php?id=61919r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61919r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61919r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61919r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61919r=mysqlcfg
Bug #61909 [Opn-Nab]: PHP realpath on Windows Case Issue
Edit report at https://bugs.php.net/bug.php?id=61909edit=1
ID: 61909
Updated by: paj...@php.net
Reported by:david at panmedia dot co dot nz
Summary:PHP realpath on Windows Case Issue
-Status: Open
+Status: Not a bug
Type: Bug
Package:Filesystem function related
Operating System: Windows Vista/7
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
We do not support case sensitive paths on windows, so do 99.999% of the windows
apps as well.
strcasecmp is what you actually need.
Previous Comments:
[2012-05-03 03:16:50] david at panmedia dot co dot nz
@larue...@php.net
Well, not always. In Windows Server 2008 it can be configured.
http://technet.microsoft.com/en-us/library/cc725747.aspx
Also, the point of realpath is to return the canonicalized absolute pathname,
but it does not. Especially in the case of nested symlinks, as I pointed out in
my other comment.
You should be able to test if a path is the same by going
if (realpath('c:\path-to-link') === realpath('C:\RealPathToTarget')) ...
[2012-05-03 03:10:56] larue...@php.net
path in windows is case insensitive..
[2012-05-02 17:46:25] david at panmedia dot co dot nz
On further investigation I have noticed that on Windows symlinks are only
followed 1 level deep:
// F:\mkdir link-target
// F:\mklink /D link f:\link-target
// F:\mklink /D link2 f:\link
$dir = realpath('f:\link2');
var_dump($dir);
$dir = realpath($dir);
var_dump($dir);
$dir = realpath($dir);
var_dump($dir);
// string 'f:\link' (length=7)
// string 'f:\link-target' (length=14)
// string 'F:\link-target' (length=14)
[2012-05-02 17:37:52] david at panmedia dot co dot nz
Description:
I have a symlink on my Windows server which was made like this:
F:\mkdir link-target
F:\mklink /D link f:\link-target
(Note the lower case f: in the symlink target)
In PHP I run this:
$dir = realpath('f:\link');
var_dump($dir);
$dir = realpath($dir);
var_dump($dir);
Which outputs:
string 'f:\link-target' (length=14)
string 'F:\link-target' (length=14)
Notice the change in case on the second realpath.
The expected output is:
string 'F:\link-target' (length=14)
string 'F:\link-target' (length=14)
Test script:
---
?php
// F:\mkdir link-target
// F:\mklink /D link f:\link-target
$dir = realpath('f:\link');
var_dump($dir);
$dir = realpath($dir);
var_dump($dir);
Expected result:
string 'F:\link-target' (length=14)
string 'F:\link-target' (length=14)
Actual result:
--
string 'f:\link-target' (length=14)
string 'F:\link-target' (length=14)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61909edit=1
