#49421 [NEW]: Make failure with MySQL 6 and PHP 6.0-dev
From: gabrycucciolo84pv at fastwebnet dot it Operating system: Centos 4.8 PHP version: 6SVN-2009-08-31 (snap) PHP Bug Type: Compile Failure Bug description: Make failure with MySQL 6 and PHP 6.0-dev Description: Trying to compile and make snapshot php6.0-200908310030 with MySQL 6.0.11-alpha returns this chain of errors. With 5.3.1-dev the compilation and make are succesful. The installed files of MySQL 6.0.11-alpha have been reinstalled to ensure they were not corrupted. Compilation line: ./configure --with-openssl --enable-ctype --with-curl --enable-exif --with-iconv --enable-json --enable-libxml --enable-mbstring --with-bz2 --enable-soap --enable-bcmath --enable-calendar --enable-ftp --with-gd=/usr/local/bin/gdlib-config --with-mcrypt --with-mhash --enable-zip --enable-xmlreader --enable-xmlwriter --with-mysql --with-mysqli --with-apxs2=/usr/local/apache2/bin/apxs --with-pear --with-zlib --enable-gd-native-ttf --with-pgsql=/usr/bin --enable-maintainer-zts --with-imap --with-kerberos --with-imap-ssl --with-xsl --enable-zend-multibyte --enable-wddx --enable-shmop --with-ldap --with-oci8=/usr/lib/oracle/xe/app/oracle/product/10.2.0/server --with-db4 Reproduce code: --- In file included from /usr/include/mysql/mysql.h:74, from /root/php6.0-200908310030/ext/mysql/php_mysql_structs.h:43, from main/internal_functions.c:58: /usr/include/mysql/my_list.h:26: error: syntax error before numeric constant /usr/include/mysql/my_list.h:30: error: syntax error before numeric constant /usr/include/mysql/my_list.h:34: error: syntax error before numeric constant /usr/include/mysql/my_list.h:35: error: syntax error before numeric constant /usr/include/mysql/my_list.h:36: error: syntax error before numeric constant In file included from /root/php6.0-200908310030/ext/mysql/php_mysql_structs.h:43, from main/internal_functions.c:58: /usr/include/mysql/mysql.h:266: error: syntax error before numeric constant /usr/include/mysql/mysql.h:266: warning: no semicolon at end of struct or union /usr/include/mysql/mysql.h:277: error: syntax error before '}' token /usr/include/mysql/mysql.h:277: warning: data definition has no type or storage class /usr/include/mysql/mysql.h:286: error: syntax error before "MYSQL" /usr/include/mysql/mysql.h:286: warning: no semicolon at end of struct or union /usr/include/mysql/mysql.h:296: error: syntax error before '}' token /usr/include/mysql/mysql.h:296: warning: data definition has no type or storage class /usr/include/mysql/mysql.h:352: error: syntax error before '*' token /usr/include/mysql/mysql.h:353: error: syntax error before '*' token /usr/include/mysql/mysql.h:354: error: syntax error before '*' token /usr/include/mysql/mysql.h:355: error: syntax error before '*' token /usr/include/mysql/mysql.h:357: error: syntax error before '*' token /usr/include/mysql/mysql.h:358: error: syntax error before '*' token /usr/include/mysql/mysql.h:359: error: syntax error before '*' token /usr/include/mysql/mysql.h:361: error: syntax error before '*' token /usr/include/mysql/mysql.h:362: error: syntax error before '*' token /usr/include/mysql/mysql.h:363: error: syntax error before '*' token /usr/include/mysql/mysql.h:364: error: syntax error before '*' token /usr/include/mysql/mysql.h:365: error: syntax error before '*' token /usr/include/mysql/mysql.h:366: error: syntax error before '*' token /usr/include/mysql/mysql.h:367: error: syntax error before '*' token /usr/include/mysql/mysql.h:368: error: syntax error before '*' token /usr/include/mysql/mysql.h:369: error: syntax error before '*' token /usr/include/mysql/mysql.h:370: error: syntax error before '*' token /usr/include/mysql/mysql.h:371: error: syntax error before '*' token /usr/include/mysql/mysql.h:373: error: syntax error before '*' token /usr/include/mysql/mysql.h:373: error: syntax error before '*' token /usr/include/mysql/mysql.h:373: warning: data definition has no type or storage class /usr/include/mysql/mysql.h:374: error: syntax error before '*' token /usr/include/mysql/mysql.h:377: error: syntax error before '*' token /usr/include/mysql/mysql.h:378: error: syntax error before '*' token /usr/include/mysql/mysql.h:380: error: syntax error before '*' token /usr/include/mysql/mysql.h:380: error: syntax error before '*' token /usr/include/mysql/mysql.h:386: warning: data definition has no type or storage class /usr/include/mysql/mysql.h:387: error: syntax error before '*' token /usr/include/mysql/mysql.h:388: error: syntax error before '*' token /usr/include/mysql/mysql.h:389: error: syntax error before '*' token /usr/include/mysql/mysql.h:391: error: syntax error before '*' token /usr/include/mysql/mysql.h:393: error: syntax error before '*' token /usr/include/mysql/mysql.h:393: error: syntax error before '*' token /usr/include/mysql/mysql.h:393: warning: data definition has no type or storage class /usr/include/mysql/mysql.h:394: error: synt
#48930 [Ana]: __COMPILER_HALT_OFFSET__ incorrect in PHP>=5.3
ID: 48930 User updated by: adam-phpbugs at adam dot gs Reported By: adam-phpbugs at adam dot gs Status: Analyzed Bug Type: Scripting Engine problem Operating System: * PHP Version: 5.3.0 Assigned To: scottmac New Comment: Understandably this might be a bit hackish to have use a global variable here, but perhaps thats preferable to what i'd consider a major regression? I attempted to patch this so I could just submit a patch here, but unfortunately my c-fu and my understanding of PHP internals is lacking. Previous Comments: [2009-08-03 03:06:47] scott...@php.net The sapi/cli/php_cli.c code will read forward when it see's a shebang to the next line. The file is already seeked by the time the scanner gets a change to look at it. The zend_get_scanned_file_offset() doesn't know about this because by the time the scanner is started the bytes are already long gone. Short of a global variable I'm not seeing a clean way to fix this. [2009-07-16 00:23:45] ka...@php.net Scott, you worked on the re2c switch, any chance you can clarrify this one? [2009-07-15 17:40:49] adam-phpbugs at adam dot gs Description: Starting in PHP 5.3.0, php no longer includes the shebang when calculating the __COMPILER_HALT_OFFSET__. Reproduce code: --- #!/usr/bin/php http://bugs.php.net/?id=48930&edit=1
#49420 [Com]: Uncatchable fatal error
ID: 49420
Comment by: tomseven at gmx dot de
Reported By: tomseven at gmx dot de
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Windows Vista
PHP Version: 5.3.0
New Comment:
Updated to the latest PHP release and source (5.3.1), but it still
crashes.
Problemsignatur:
Problemereignisname: APPCRASH
Anwendungsname: httpd.exe
Anwendungsversion:2.2.13.0
Anwendungszeitstempel:4a7b422b
Fehlermodulname: php5ts.dll
Fehlermodulversion: 5.3.1.0
Fehlermodulzeitstempel: 4a9ae59c
Ausnahmecode: c005
Ausnahmeoffset: 0008c767
Betriebsystemversion: 6.0.6001.2.1.0.768.3
Gebietsschema-ID: 1031
Zusatzinformation 1: f1e8
Zusatzinformation 2: d4eb7cf28a4f910486e91a11f70d294f
Zusatzinformation 3: 8d19
Zusatzinformation 4: c73248402f4105cfb47e294ad6946345
Previous Comments:
[2009-08-30 20:39:49] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-08-30 20:32:44] tomseven at gmx dot de
Description:
Uncatchable fatal error for function call on non-object
Reproduce code:
---
...
LPSTR eval_code = "?> $NOVAR->ABC();";
...
zend_first_try {
if ( zend_eval_string(eval_code, NULL, eval_name TSRMLS_CC) ==
SUCCESS ) {
...
}
}
zend_catch
{
} zend_end_try();
Expected result:
zend_eval_string should throw a fatal error and jump to zend_catch.
Fatal error "Call to a member function ABC() on a non-object" is
expected to be catchable.
It is working in 5.2.1/Apache2 but no longer in 5.3/Apache2.2
Actual result:
--
zend_catch never reached
--
Edit this bug report at http://bugs.php.net/?id=49420&edit=1
#49420 [Opn->Fbk]: Uncatchable fatal error
ID: 49420
Updated by: j...@php.net
Reported By: tomseven at gmx dot de
-Status: Open
+Status: Feedback
-Bug Type: Class/Object related
+Bug Type: Scripting Engine problem
Operating System: Windows Vista
PHP Version: 5.3.0
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2009-08-30 20:32:44] tomseven at gmx dot de
Description:
Uncatchable fatal error for function call on non-object
Reproduce code:
---
...
LPSTR eval_code = "?> $NOVAR->ABC();";
...
zend_first_try {
if ( zend_eval_string(eval_code, NULL, eval_name TSRMLS_CC) ==
SUCCESS ) {
...
}
}
zend_catch
{
} zend_end_try();
Expected result:
zend_eval_string should throw a fatal error and jump to zend_catch.
Fatal error "Call to a member function ABC() on a non-object" is
expected to be catchable.
It is working in 5.2.1/Apache2 but no longer in 5.3/Apache2.2
Actual result:
--
zend_catch never reached
--
Edit this bug report at http://bugs.php.net/?id=49420&edit=1
#49420 [NEW]: Uncatchable fatal error
From: tomseven at gmx dot de
Operating system: Windows Vista
PHP version: 5.3.0
PHP Bug Type: Class/Object related
Bug description: Uncatchable fatal error
Description:
Uncatchable fatal error for function call on non-object
Reproduce code:
---
...
LPSTR eval_code = "?> $NOVAR->ABC();";
...
zend_first_try {
if ( zend_eval_string(eval_code, NULL, eval_name TSRMLS_CC) == SUCCESS )
{
...
}
}
zend_catch
{
} zend_end_try();
Expected result:
zend_eval_string should throw a fatal error and jump to zend_catch. Fatal
error "Call to a member function ABC() on a non-object" is expected to be
catchable.
It is working in 5.2.1/Apache2 but no longer in 5.3/Apache2.2
Actual result:
--
zend_catch never reached
--
Edit bug report at http://bugs.php.net/?id=49420&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49420&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49420&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49420&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49420&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49420&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49420&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49420&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49420&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49420&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49420&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49420&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49420&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49420&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49420&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49420&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49420&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49420&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49420&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49420&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49420&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49420&r=mysqlcfg
#48745 [Opn->Asn]: mysqlnd: mysql_num_fields returns wrong column count for mysql_list_fields
ID: 48745
Updated by: j...@php.net
Reported By: theta...@php.net
-Status: Open
+Status: Assigned
Bug Type: MySQL related
Operating System: *
-PHP Version: 5.3.0
+PHP Version: 5.3SVN-2009-08-29
Assigned To: mysql
Previous Comments:
[2009-08-29 13:11:41] theta...@php.net
It is still the same stack trace:
Program terminated with signal 11, Segmentation fault.
#0 0xfc3931aa in php_mysql_field_info (ht=0, return_value=0xd7db5a8,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1,
tsrm_ls=0xc96f228, entry_type=2) at
/pangaea/install/php5.3-200908291030/ext/mysql/php_mysql.c:2410
2410Z_STRLEN_P(return_value) =
strlen(mysql_field->table);
(gdb) where
#0 0xfc3931aa in php_mysql_field_info (ht=0, return_value=0xd7db5a8,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1,
tsrm_ls=0xc96f228, entry_type=2) at
/pangaea/install/php5.3-200908291030/ext/mysql/php_mysql.c:2410
#1 0xfc56d291 in zend_do_fcall_common_helper_SPEC
(execute_data=0xc6ddf20, tsrm_ls=0xc404e20)
at /pangaea/install/php5.3-200908291030/Zend/zend_vm_execute.h:313
#2 0xfc56c116 in execute (op_array=0xc7dcaec, tsrm_ls=0xc404e20) at
/pangaea/install/php5.3-200908291030/Zend/zend_vm_execute.h:104
#3 0xfc54a437 in zend_execute_scripts (type=8, tsrm_ls=0xc404e20,
retval=0x0, file_count=3)
at /pangaea/install/php5.3-200908291030/Zend/zend.c:1188
#4 0xfc4f58d6 in php_execute_script (primary_file=0xe7de7cb8,
tsrm_ls=0xc404e20)
at /pangaea/install/php5.3-200908291030/main/main.c:2212
#5 0xfc5d60ea in php5_execute (pb=0x81ae228, sn=0xc2661dc,
rq=0xc266254)
at /pangaea/install/php5.3-200908291030/sapi/nsapi/nsapi.c:1047
#6 0xfecfb147 in func_exec_str () from
/pangaea/webserver70/lib/libns-httpd40.so
#7 0xfecfbd2a in INTfunc_exec_directive () from
/pangaea/webserver70/lib/libns-httpd40.so
#8 0xfed009d6 in INTservact_service () from
/pangaea/webserver70/lib/libns-httpd40.so
#9 0xfed01a39 in INTservact_handle_processed () from
/pangaea/webserver70/lib/libns-httpd40.so
#10 0xfed5e358 in __1cLHttpRequestUUnacceleratedRespond6M_v_ () from
/pangaea/webserver70/lib/libns-httpd40.so
#11 0xfed5d5ba in __1cLHttpRequestNHandleRequest6MpnGnetbuf_I_i_ ()
from /pangaea/webserver70/lib/libns-httpd40.so
#12 0xfed5be90 in __1cNDaemonSessionDrun6M_v_ () from
/pangaea/webserver70/lib/libns-httpd40.so
#13 0xfeb861fc in ThreadMain () from
/pangaea/webserver70/lib/libnsprwrap.so
#14 0xfe0bb6c9 in _pt_root () from
/pangaea/webserver70/lib/libnspr4.so
#15 0xfd37fd36 in _thr_setup () from /lib/libc.so.1
#16 0xfd380020 in L3_doit () from /lib/libc.so.1
#17 0xeb9d3c00 in ?? ()
#18 0x in ?? ()
(gdb) print *mysql_field
$2 = {name = 0x0, org_name = 0x0, table = 0x0, org_table = 0x0, db =
0x0, catalog = 0x0, def = 0x0, length = 0, max_length = 0,
name_length = 0, org_name_length = 0, table_length = 0,
org_table_length = 0, db_length = 0, catalog_length = 0, def_length = 0,
flags = 0, decimals = 0, charsetnr = 0, type = MYSQL_TYPE_DECIMAL,
root = 0x0, root_len = 0}
(gdb) print mysql_result
$3 = (MYSQLND_RES *) 0x0
(gdb)
The new version is installed (I checked the snaps.php.net version for
your changes).
The attached PHP scipt to reproduce generates similar stack trace:
Core was generated by `php test.php'.
Program terminated with signal 11, Segmentation fault.
#0 0x081a24f2 in php_mysql_field_info (ht=0, return_value=0x887e28c,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1,
tsrm_ls=0x8b057d8, entry_type=2) at
/pangaea/install/php5.3-200908291030/ext/mysql/php_mysql.c:2410
2410Z_STRLEN_P(return_value) =
strlen(mysql_field->table);
(gdb) where
#0 0x081a24f2 in php_mysql_field_info (ht=0, return_value=0x887e28c,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1,
tsrm_ls=0x8b057d8, entry_type=2) at
/pangaea/install/php5.3-200908291030/ext/mysql/php_mysql.c:2410
#1 0x0837c5d9 in zend_do_fcall_common_helper_SPEC
(execute_data=0x8abb468, tsrm_ls=0x885ecc0)
at /pangaea/install/php5.3-200908291030/Zend/zend_vm_execute.h:313
#2 0x0837b45e in execute (op_array=0x886e340, tsrm_ls=0x885ecc0) at
/pangaea/install/php5.3-200908291030/Zend/zend_vm_execute.h:104
#3 0x0835977f in zend_execute_scripts (type=8, tsrm_ls=0x885ecc0,
retval=0x0, file_count=3)
at /pangaea/install/php5.3-200908291030/Zend/zend.c:1188
#4 0x08304c1e in php_execute_script (primary_file=0x8047c90,
tsrm_ls=0x885ecc0)
at /pangaea/install/php5.3-200908291030/main/main.c:2212
#5 0x083e5406 in main (argc=2, argv=0x8047d24) at
/pangaea/install/php5.3-200908291030/sapi/cli/php_cli.c:1188
$ php --version
PHP 5.3.1-dev (cli) (built: Aug 29 2009 14:35:51)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
>From this snap: php5.3-200908291030.tar.bz2
Uwe
#49404 [Opn->Bgs]: LDAP search crashes if key not matched
ID: 49404 Updated by: j...@php.net Reported By: doctor_nett at yahoo dot com -Status: Open +Status: Bogus Bug Type: LDAP related Operating System: linux PHP Version: 5.3.0 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2009-08-30 18:19:54] doctor_nett at yahoo dot com thanks :) let me rephrase it by code CASE 1: [Matching field displayName] #$chrName = "Mazhar Hassan"; #works fine,coz exsist in AD $chrName = "M Hassan"; #crashes the system, not exsist in the AD $sr=ldap_search($ds, $LDAP_DN, "(displayName=$chrName)"); Note: on my production environment i cant find displayName Field CASE 2:[Matching field sxdisplayName] #$chrName = "Mazhar Hassan"; #works fine,coz exsist in AD $chrName = "M Hassan"; #Also works fine, but not exsist in the AD $sr=ldap_search($ds, $LDAP_DN, "(sxdisplayName=$chrName)"); Expected: i think that case1 must stuck for both user exsist in AD or not, but for one it give result and for other it get stuck, moreover i this displayName field doesnot exsist in AD. can any one please help me in this. Thanks in Advance [2009-08-30 18:12:25] doctor_nett at yahoo dot com Hi, I have got the solution, infact the LADP uid search was not getting stuck, but it was the displayName, which i used to search for user name, so the code part that was getting stuck was #$chrName = "Mazhar Hassan"; #works fine, coz exsist in active directory $chrUid = "M Mazhar"; #crashes the system, not exsist in the active director $sr=ldap_search($ds, $LDAP_DN, "(displayName=$chrName)"); i have tried few other tools to search it on my linux environment, and similar kind of stuck thing was happing with those tools as well, then i realized that there no displayName field in active directory of my production environment, instead there is sxdisplayName, but on my XP system environment its displayName, sorry for mis understanding. as soon as i changed that to sxdisplayName it now works fine, if record not matches it gracefully return the control. now here is a question, why displayName was working for the the user name that exsist in active directory and getting stuck for those who do not exsist in active dirctory. i hope so i made my point clear. in short its not php fault, coz other tools also get stuck. [2009-08-29 18:58:55] doctor_nett at yahoo dot com thanks for quick reply i will try to get backtrace of it, thanks [2009-08-28 22:18:07] fel...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2009-08-28 22:09:04] doctor_nett at yahoo dot com Description: i am using php, with ldap to search records form active director on linux(webserver) it work fines if i type uid that exsist in active directory, but if i type some uid that does not exsist in the active directory php script crashes. note: sorry if i am posting this in wrong place, but the same code works fine on my windows xp(webserver) system with ADAM ADSI Reproduce code: --- $chrUid = "mazhar.hassan"; #works fine $chrUid = "maz.hass"; #crashes the system $sr=ldap_search($ds, $LDAP_DN, "(uid=$chrUid)"); Expected result: it should return nothing, as its doing on my XP system environment, so that i can display a message record not found Actual result: -- system crashes and have to restart. -- Edit this bug report at http://bugs.php.net/?id=49404&edit=1
#49419 [NEW]: PHP ssl:// wrapper - cannot verify VeriSign certificate chain
From: Jacek at jacekk dot info
Operating system: Ubuntu
PHP version: 5.3.0
PHP Bug Type: OpenSSL related
Bug description: PHP ssl:// wrapper - cannot verify VeriSign certificate chain
Description:
PHP cannot validate some (VeriSign's?) certificate chains correctly.
openssl s_client works fine with the same input.
Verification of thawte chain works well.
chain.pem is available at http://pastebin.com/f4ab25a9a
OpenSSL:
$ openssl s_client -connect www.verisign.com:443 -CAfile chain.pem
(...)
Verify return code: 0 (ok)
(...)
Reproduce code:
---
TRUE,
'verify_depth' => 5,
'allow_self_signed' => FALSE,
'cafile' => 'chain.pem',
'capture_peer_cert' => TRUE,
'capture_peer_chain' => TRUE,
);
$context = stream_context_create(array(
'ssl' => $ssl,
));
file_get_contents('https://api-3t.paypal.com/', NULL, $context);
file_get_contents('https://www.verisign.com/', NULL, $context);
?>
Expected result:
Nothing
Actual result:
--
Warning: file_get_contents(): SSL operation failed with code 1. OpenSSL
Error messages:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
failed in /home/me/test/test.php on line 14
Warning: file_get_contents(): Failed to enable crypto in
/home/me/test/test.php on line 14
Warning: file_get_contents(https://api-3t.paypal.com/): failed to open
stream: operation failed in /home/me/test/test.php on line 14
Warning: file_get_contents(): SSL operation failed with code 1. OpenSSL
Error messages:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
failed in /home/me/test/test.php on line 15
Warning: file_get_contents(): Failed to enable crypto in
/home/me/test/test.php on line 15
Warning: file_get_contents(https://www.verisign.com/): failed to open
stream: operation failed in /home/me/test/test.php on line 15
--
Edit bug report at http://bugs.php.net/?id=49419&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49419&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49419&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49419&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49419&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49419&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49419&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49419&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49419&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49419&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49419&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49419&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49419&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49419&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49419&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49419&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49419&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49419&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49419&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49419&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49419&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49419&r=mysqlcfg
#49404 [Opn]: LDAP searh crashes PHP if key not matched
ID: 49404 User updated by: doctor_nett at yahoo dot com Reported By: doctor_nett at yahoo dot com Status: Open Bug Type: LDAP related Operating System: linux PHP Version: 5.3.0 New Comment: thanks :) let me rephrase it by code CASE 1: [Matching field displayName] #$chrName = "Mazhar Hassan"; #works fine,coz exsist in AD $chrName = "M Hassan"; #crashes the system, not exsist in the AD $sr=ldap_search($ds, $LDAP_DN, "(displayName=$chrName)"); Note: on my production environment i cant find displayName Field CASE 2:[Matching field sxdisplayName] #$chrName = "Mazhar Hassan"; #works fine,coz exsist in AD $chrName = "M Hassan"; #Also works fine, but not exsist in the AD $sr=ldap_search($ds, $LDAP_DN, "(sxdisplayName=$chrName)"); Expected: i think that case1 must stuck for both user exsist in AD or not, but for one it give result and for other it get stuck, moreover i this displayName field doesnot exsist in AD. can any one please help me in this. Thanks in Advance Previous Comments: [2009-08-30 18:12:25] doctor_nett at yahoo dot com Hi, I have got the solution, infact the LADP uid search was not getting stuck, but it was the displayName, which i used to search for user name, so the code part that was getting stuck was #$chrName = "Mazhar Hassan"; #works fine, coz exsist in active directory $chrUid = "M Mazhar"; #crashes the system, not exsist in the active director $sr=ldap_search($ds, $LDAP_DN, "(displayName=$chrName)"); i have tried few other tools to search it on my linux environment, and similar kind of stuck thing was happing with those tools as well, then i realized that there no displayName field in active directory of my production environment, instead there is sxdisplayName, but on my XP system environment its displayName, sorry for mis understanding. as soon as i changed that to sxdisplayName it now works fine, if record not matches it gracefully return the control. now here is a question, why displayName was working for the the user name that exsist in active directory and getting stuck for those who do not exsist in active dirctory. i hope so i made my point clear. in short its not php fault, coz other tools also get stuck. [2009-08-29 18:58:55] doctor_nett at yahoo dot com thanks for quick reply i will try to get backtrace of it, thanks [2009-08-28 22:18:07] fel...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2009-08-28 22:09:04] doctor_nett at yahoo dot com Description: i am using php, with ldap to search records form active director on linux(webserver) it work fines if i type uid that exsist in active directory, but if i type some uid that does not exsist in the active directory php script crashes. note: sorry if i am posting this in wrong place, but the same code works fine on my windows xp(webserver) system with ADAM ADSI Reproduce code: --- $chrUid = "mazhar.hassan"; #works fine $chrUid = "maz.hass"; #crashes the system $sr=ldap_search($ds, $LDAP_DN, "(uid=$chrUid)"); Expected result: it should return nothing, as its doing on my XP system environment, so that i can display a message record not found Actual result: -- system crashes and have to restart. -- Edit this bug report at http://bugs.php.net/?id=49404&edit=1
#49404 [Fbk->Opn]: LDAP searh crashes PHP if key not matched
ID: 49404 User updated by: doctor_nett at yahoo dot com Reported By: doctor_nett at yahoo dot com -Status: Feedback +Status: Open Bug Type: LDAP related Operating System: linux PHP Version: 5.3.0 New Comment: Hi, I have got the solution, infact the LADP uid search was not getting stuck, but it was the displayName, which i used to search for user name, so the code part that was getting stuck was #$chrName = "Mazhar Hassan"; #works fine, coz exsist in active directory $chrUid = "M Mazhar"; #crashes the system, not exsist in the active director $sr=ldap_search($ds, $LDAP_DN, "(displayName=$chrName)"); i have tried few other tools to search it on my linux environment, and similar kind of stuck thing was happing with those tools as well, then i realized that there no displayName field in active directory of my production environment, instead there is sxdisplayName, but on my XP system environment its displayName, sorry for mis understanding. as soon as i changed that to sxdisplayName it now works fine, if record not matches it gracefully return the control. now here is a question, why displayName was working for the the user name that exsist in active directory and getting stuck for those who do not exsist in active dirctory. i hope so i made my point clear. in short its not php fault, coz other tools also get stuck. Previous Comments: [2009-08-29 18:58:55] doctor_nett at yahoo dot com thanks for quick reply i will try to get backtrace of it, thanks [2009-08-28 22:18:07] fel...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2009-08-28 22:09:04] doctor_nett at yahoo dot com Description: i am using php, with ldap to search records form active director on linux(webserver) it work fines if i type uid that exsist in active directory, but if i type some uid that does not exsist in the active directory php script crashes. note: sorry if i am posting this in wrong place, but the same code works fine on my windows xp(webserver) system with ADAM ADSI Reproduce code: --- $chrUid = "mazhar.hassan"; #works fine $chrUid = "maz.hass"; #crashes the system $sr=ldap_search($ds, $LDAP_DN, "(uid=$chrUid)"); Expected result: it should return nothing, as its doing on my XP system environment, so that i can display a message record not found Actual result: -- system crashes and have to restart. -- Edit this bug report at http://bugs.php.net/?id=49404&edit=1
#49418 [Opn->Bgs]: The greatest bug in the history of PHP
ID: 49418
Updated by: col...@php.net
Reported By: ilies dot radu at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Variables related
Operating System: MacOSX, NetBSD, Linux
PHP Version: 5.2.10
New Comment:
Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.
If you would like to know more about "floats" and what IEEE
754 is, read this:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
Thank you for your interest in PHP.
Previous Comments:
[2009-08-30 17:29:54] ilies dot radu at gmail dot com
Description:
Example #1 / FAIL (This should NOT FAIL, but it does) !!!
$a=1.;
$b=1.;
$c=2.;
$d=($a+$b);
if($d != $c) {
echo 'php have a serious bug ...';
} else {
echo 'OK ...';
} //end if else
// notice that currently I use number_format($d, 4, '.', '') to fix
this, but is abnormal !
Example #2 / OK
$a=4.;
$b=4.;
$c=8.;
$d=($a+$b);
if($d != $c) {
echo 'php have a serious bug ...';
} else {
echo 'OK ...';
} //end if
// this seems that not raise that bug, ... hmmm ... very strange
I tested it on:
PHP 4.4.9
PHP 5.2.9
PHP 5.2.10
PHP 4.4.4 (bundled with Zend Studio)
It appears that all fail at Example #1 and should not ... !!!
If you release a patch, please also patch the 4.4.9 version.
Reproduce code:
---
$a=1.;
$b=1.;
$c=2.;
$d=($a+$b);
if($d != $c) {
echo 'php have a serious bug ...';
} else {
echo 'OK ...';
} //end if else
Expected result:
the output should be 'OK ...'
but is not !
Actual result:
--
'php have a serious bug ...'
--
Edit this bug report at http://bugs.php.net/?id=49418&edit=1
#49418 [NEW]: The greatest bug in the history of PHP
From: ilies dot radu at gmail dot com
Operating system: MacOSX, NetBSD, Linux
PHP version: 5.2.10
PHP Bug Type: Variables related
Bug description: The greatest bug in the history of PHP
Description:
Example #1 / FAIL (This should NOT FAIL, but it does) !!!
$a=1.;
$b=1.;
$c=2.;
$d=($a+$b);
if($d != $c) {
echo 'php have a serious bug ...';
} else {
echo 'OK ...';
} //end if else
// notice that currently I use number_format($d, 4, '.', '') to fix this,
but is abnormal !
Example #2 / OK
$a=4.;
$b=4.;
$c=8.;
$d=($a+$b);
if($d != $c) {
echo 'php have a serious bug ...';
} else {
echo 'OK ...';
} //end if
// this seems that not raise that bug, ... hmmm ... very strange
I tested it on:
PHP 4.4.9
PHP 5.2.9
PHP 5.2.10
PHP 4.4.4 (bundled with Zend Studio)
It appears that all fail at Example #1 and should not ... !!!
If you release a patch, please also patch the 4.4.9 version.
Reproduce code:
---
$a=1.;
$b=1.;
$c=2.;
$d=($a+$b);
if($d != $c) {
echo 'php have a serious bug ...';
} else {
echo 'OK ...';
} //end if else
Expected result:
the output should be 'OK ...'
but is not !
Actual result:
--
'php have a serious bug ...'
--
Edit bug report at http://bugs.php.net/?id=49418&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49418&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49418&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49418&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49418&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49418&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49418&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49418&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49418&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49418&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49418&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49418&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49418&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49418&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49418&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49418&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49418&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49418&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49418&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49418&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49418&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49418&r=mysqlcfg
#49417 [Bgs]: resolving symlinks works unstable
ID: 49417
Updated by: paj...@php.net
Reported By: info at libertydesign dot de
Status: Bogus
Bug Type: Apache2 related
Operating System: Windows Vista
PHP Version: 5.3.0
New Comment:
Relative path won't change, the way it works now (try a snapshot :)
matches what we do on all other platforms.
Previous Comments:
[2009-08-30 15:56:46] info at libertydesign dot de
mh, i used
c:\>mklink /d "C:\localhost\htdocs\page\lib\base"
"C:\localhost\htdocs\_base"
and it works with 5.2.9.
Anyway :-) Thanks for your comment that it will be fixed in coming
versions :-)
[2009-08-30 15:45:37] paj...@php.net
Symbolic links did not work at all with 5.2, junctions did (luckily).
But the issues related to this change are in #48746.
Mark as bogus (duplicate and almost all issues are fixed in svn
already). You can try a snapshot as well.
[2009-08-30 15:20:43] info at libertydesign dot de
Description:
Symbolic links under Windows Vista doesnt work as expected anymore when
using PHP 5.3 in combination with Apache 2.2.12.
See Code below.
Resolving to Base.php works. But using BASE_DIR in Base.php itself
causes
Warning:
require_once(C:\localhost\htdocs\page/lib/base/Database.class.php)
[function.require-once]: failed to open stream: No such file or
directory in C:\localhost\htdocs\page/lib/base/Base.php on line 7
Fatal error: require_once() [function.require]: Failed opening required
'C:\localhost\htdocs\page/lib/base/Database.class.php'
(include_path='.;C:\localhost\php\pear\') in
C:\localhost\htdocs\page\lib\base\Base.php on line 7
but sometimes it works, than i reload and it doesn't work again.
I don't know why. With PHP 5.2.9 it works as expected.
Reproduce code:
---
/* in C:\localhost\page/index.php */
// something like C:\localhost\page/
define('BASE_DIR', dirname(__FILE__).'/');
// the base dir is a symbolic link to C:\localhost\_base/
require_once(BASE_DIR.'lib/base/Base.php');
/* in C:\localhost\_base/Base.php */
require_once(BASE_DIR.'lib/base/Database.php');
--
Edit this bug report at http://bugs.php.net/?id=49417&edit=1
#49417 [Bgs]: resolving symlinks works unstable
ID: 49417
User updated by: info at libertydesign dot de
Reported By: info at libertydesign dot de
Status: Bogus
Bug Type: Apache2 related
Operating System: Windows Vista
PHP Version: 5.3.0
New Comment:
mh, i used
c:\>mklink /d "C:\localhost\htdocs\page\lib\base"
"C:\localhost\htdocs\_base"
and it works with 5.2.9.
Anyway :-) Thanks for your comment that it will be fixed in coming
versions :-)
Previous Comments:
[2009-08-30 15:45:37] paj...@php.net
Symbolic links did not work at all with 5.2, junctions did (luckily).
But the issues related to this change are in #48746.
Mark as bogus (duplicate and almost all issues are fixed in svn
already). You can try a snapshot as well.
[2009-08-30 15:20:43] info at libertydesign dot de
Description:
Symbolic links under Windows Vista doesnt work as expected anymore when
using PHP 5.3 in combination with Apache 2.2.12.
See Code below.
Resolving to Base.php works. But using BASE_DIR in Base.php itself
causes
Warning:
require_once(C:\localhost\htdocs\page/lib/base/Database.class.php)
[function.require-once]: failed to open stream: No such file or
directory in C:\localhost\htdocs\page/lib/base/Base.php on line 7
Fatal error: require_once() [function.require]: Failed opening required
'C:\localhost\htdocs\page/lib/base/Database.class.php'
(include_path='.;C:\localhost\php\pear\') in
C:\localhost\htdocs\page\lib\base\Base.php on line 7
but sometimes it works, than i reload and it doesn't work again.
I don't know why. With PHP 5.2.9 it works as expected.
Reproduce code:
---
/* in C:\localhost\page/index.php */
// something like C:\localhost\page/
define('BASE_DIR', dirname(__FILE__).'/');
// the base dir is a symbolic link to C:\localhost\_base/
require_once(BASE_DIR.'lib/base/Base.php');
/* in C:\localhost\_base/Base.php */
require_once(BASE_DIR.'lib/base/Database.php');
--
Edit this bug report at http://bugs.php.net/?id=49417&edit=1
#49417 [Opn->Bgs]: resolving symlinks works unstable
ID: 49417
Updated by: paj...@php.net
Reported By: info at libertydesign dot de
-Status: Open
+Status: Bogus
Bug Type: Apache2 related
Operating System: Windows Vista
PHP Version: 5.3.0
New Comment:
Symbolic links did not work at all with 5.2, junctions did (luckily).
But the issues related to this change are in #48746.
Mark as bogus (duplicate and almost all issues are fixed in svn
already). You can try a snapshot as well.
Previous Comments:
[2009-08-30 15:20:43] info at libertydesign dot de
Description:
Symbolic links under Windows Vista doesnt work as expected anymore when
using PHP 5.3 in combination with Apache 2.2.12.
See Code below.
Resolving to Base.php works. But using BASE_DIR in Base.php itself
causes
Warning:
require_once(C:\localhost\htdocs\page/lib/base/Database.class.php)
[function.require-once]: failed to open stream: No such file or
directory in C:\localhost\htdocs\page/lib/base/Base.php on line 7
Fatal error: require_once() [function.require]: Failed opening required
'C:\localhost\htdocs\page/lib/base/Database.class.php'
(include_path='.;C:\localhost\php\pear\') in
C:\localhost\htdocs\page\lib\base\Base.php on line 7
but sometimes it works, than i reload and it doesn't work again.
I don't know why. With PHP 5.2.9 it works as expected.
Reproduce code:
---
/* in C:\localhost\page/index.php */
// something like C:\localhost\page/
define('BASE_DIR', dirname(__FILE__).'/');
// the base dir is a symbolic link to C:\localhost\_base/
require_once(BASE_DIR.'lib/base/Base.php');
/* in C:\localhost\_base/Base.php */
require_once(BASE_DIR.'lib/base/Database.php');
--
Edit this bug report at http://bugs.php.net/?id=49417&edit=1
#49391 [Opn->Csd]: ldap.c utilizing deprecated ldap_modify_s
ID: 49391 Updated by: il...@php.net Reported By: thinice at gmail dot com -Status: Open +Status: Closed Bug Type: LDAP related Operating System: * PHP Version: 5.3.0 New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2009-08-30 15:34:00] s...@php.net Automatic comment from SVN on behalf of iliaa Revision: http://svn.php.net/viewvc/?view=revision&revision=287897 Log: Bug #49391 ldap.c utilizing deprecated ldap_modify_s [2009-08-27 17:28:46] thinice at gmail dot com ldap_modify_est_s = ldap_modify_ext_s [2009-08-27 17:27:46] thinice at gmail dot com Description: As per the OpenLDAP documentation here: http://www.openldap.org/software/man.cgi?query=ldap_modify_s&apropos=0&sektion=0&manpath=OpenLDAP+2.4-Release&format=html The basis of most of the ldap functions utilize ldap_modify_s - which is deprecating in favor of ldap_modify_est_s -- Edit this bug report at http://bugs.php.net/?id=49391&edit=1
#49417 [NEW]: resolving symlinks works unstable
From: info at libertydesign dot de
Operating system: Windows Vista
PHP version: 5.3.0
PHP Bug Type: Apache2 related
Bug description: resolving symlinks works unstable
Description:
Symbolic links under Windows Vista doesnt work as expected anymore when
using PHP 5.3 in combination with Apache 2.2.12.
See Code below.
Resolving to Base.php works. But using BASE_DIR in Base.php itself causes
Warning:
require_once(C:\localhost\htdocs\page/lib/base/Database.class.php)
[function.require-once]: failed to open stream: No such file or directory
in C:\localhost\htdocs\page/lib/base/Base.php on line 7
Fatal error: require_once() [function.require]: Failed opening required
'C:\localhost\htdocs\page/lib/base/Database.class.php'
(include_path='.;C:\localhost\php\pear\') in
C:\localhost\htdocs\page\lib\base\Base.php on line 7
but sometimes it works, than i reload and it doesn't work again.
I don't know why. With PHP 5.2.9 it works as expected.
Reproduce code:
---
/* in C:\localhost\page/index.php */
// something like C:\localhost\page/
define('BASE_DIR', dirname(__FILE__).'/');
// the base dir is a symbolic link to C:\localhost\_base/
require_once(BASE_DIR.'lib/base/Base.php');
/* in C:\localhost\_base/Base.php */
require_once(BASE_DIR.'lib/base/Database.php');
--
Edit bug report at http://bugs.php.net/?id=49417&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49417&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49417&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49417&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49417&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49417&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49417&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49417&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49417&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49417&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49417&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49417&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49417&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49417&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49417&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49417&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49417&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49417&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49417&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49417&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49417&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49417&r=mysqlcfg
#49403 [Opn->Bgs]: FILTER_VALIDATE_URL
ID: 49403 Updated by: il...@php.net Reported By: botisdale at gmail dot com -Status: Open +Status: Bogus Bug Type: Filter related Operating System: win xp PHP Version: 5.2.10 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php . Previous Comments: [2009-08-28 21:38:42] botisdale at gmail dot com Description: It seems that the scheme is always required for FILTER_VALIDATE_URL, whether or not FILTER_FLAG_SCHEME_REQUIRED is used - making the second flag redundant. Is this the expected behavior of FILTER_VALIDATE_URL? Does it never evaluate 'example.com' to true? --- >From manual page: function.filter-var --- Reproduce code: --- --- >From manual page: function.filter-var --- #1: #2: Expected result: I'd expect to see: #1: string(11) "example.com" #2: bool(false) Actual result: -- #1: bool(false) #2: bool(false) -- Edit this bug report at http://bugs.php.net/?id=49403&edit=1
#49416 [NEW]: stream_socket_listen() and stream_socket_set_option() functions.
From: kak dot serpom dot po dot yaitsam at gmail dot com Operating system: any PHP version: 5.3.0 PHP Bug Type: Feature/Change Request Bug description: stream_socket_listen() and stream_socket_set_option() functions. Description: Please, add function stream_socket_listen(resource,backlog): it should call listen() for the socket created by stream_socket_server beforehand. I need to use stream_socket_server but I can not use socket_*, because of libevent. Also, it would be nice to have a stream_socket_set_option function, which allows to apply SO_REUSE and other parameters. Thanks. -- Edit bug report at http://bugs.php.net/?id=49416&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49416&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49416&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49416&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49416&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49416&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49416&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49416&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49416&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49416&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49416&r=support Expected behavior: http://bugs.php.net/fix.php?id=49416&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49416&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49416&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49416&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49416&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49416&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49416&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49416&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49416&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49416&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49416&r=mysqlcfg
#48746 [Fbk]: Unable to browse directories within Junction Points
ID: 48746
Updated by: paj...@php.net
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
@shoresofnowhere at gmail dot com
Not with symlink/link/etc. You can try it under unix as well:
/var/www/dir1
/var/www/test.txt
/var/www/dir2
/var/www/dir2/linktodir1
/var/www/dir2/test2.txt
/var/www/dir2/linktodir1/t.php
In t.php, ../test2.txt will fail because it will use dir1 as base
direct. That's how it always worked, windows had only partial support
for links (symbolic or hard) or junctions. It worked before but it was
not correct (and not portable).
Previous Comments:
[2009-08-30 13:00:44] shoresofnowhere at gmail dot com
@ pajoye:
Sorry, but i don't understand why the correct behaviour should be that
of 5.3:
dir1 directory
subdir1 subdirectory of dir1
cfg.php file in dir1
dir2 directory
cfg.php file in dir2
junction1 junction to subdir1 created in dir2
and i have in dir1/subdir1/file.php:
require_once("../cfg.php");
I expect that if i run dir1/subdir1/file.php i get
require_once("dir1/cfg.php");
BUT if i run dir2/subdir1/file.php i will get
require_once("dir2/cfg.php");
Could you please tell me why this would be wrong? File inclusions have
always been relative to the path of the main php file that's
executing...
Thanks!
[2009-08-30 11:17:07] paj...@php.net
Found the problems, the windows port of dirent (scandir) as well as
php_mkdir (used by mkdir()) lack a call to realpath, making them use the
current path with the standard API. It ends to use c:.
Testing the patch but it should do it for RC1 next Tuesday. You can
test the patch yourself by calling realpath manually:
scandir(realpath('mounted_volume')); or
mkdir(realpath('mounted_volume\\test34'));
Other files operations work as expected.
[2009-08-30 10:39:21] paj...@php.net
Using different drives work fine here (ie. G, Z or whatever else).
Did you test it using CLI? And running each test separately or using
one single script with all tests (stat cache will be used in this
case)?
Which windows version?
[2009-08-30 04:41:30] phpstuff at cresstone dot com
Hmmm. may have spoke too soon. Getting some weird results when working
with mounted volumes.
'C:\mnt\test\mounted_volume' is a junction mounted volume that is *not*
the system drive ie: not c:\
Take the following sequence of commands, working directory is
'C:\mnt\test\':
is_dir('mounted_volume');
Returns true, yay!
scandir('mounted_volume');
Here's the strange behavior; this command enumerates the root system
drive, c:\, rather than the correct pointed-to volume.
mkdir('mounted_volume\test34');
Returns true, but test32 is created on the incorrect volume: c:\test32
now exists
is_dir('mounted_volume\test34');
Returns FALSE, this is the correct behavior because the directory does
not exist in the correct location, but it is obviously inconsistent with
the above mkdir
unlink('mounted_volume\test34');
Throws a 'No such file or directory' warning. Appears to be looking in
the correct place.
My previous tests all used c:\ as the 'mounted volume' which is why I
didn't see this at first.
[2009-08-30 03:30:14] phpstuff at cresstone dot com
Latest snapshot give correct behavior for me. Thanks much.
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746&edit=1
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746
Comment by: shoresofnowhere at gmail dot com
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
@ pajoye:
Sorry, but i don't understand why the correct behaviour should be that
of 5.3:
dir1 directory
subdir1 subdirectory of dir1
cfg.php file in dir1
dir2 directory
cfg.php file in dir2
junction1 junction to subdir1 created in dir2
and i have in dir1/subdir1/file.php:
require_once("../cfg.php");
I expect that if i run dir1/subdir1/file.php i get
require_once("dir1/cfg.php");
BUT if i run dir2/subdir1/file.php i will get
require_once("dir2/cfg.php");
Could you please tell me why this would be wrong? File inclusions have
always been relative to the path of the main php file that's
executing...
Thanks!
Previous Comments:
[2009-08-30 11:17:07] paj...@php.net
Found the problems, the windows port of dirent (scandir) as well as
php_mkdir (used by mkdir()) lack a call to realpath, making them use the
current path with the standard API. It ends to use c:.
Testing the patch but it should do it for RC1 next Tuesday. You can
test the patch yourself by calling realpath manually:
scandir(realpath('mounted_volume')); or
mkdir(realpath('mounted_volume\\test34'));
Other files operations work as expected.
[2009-08-30 10:39:21] paj...@php.net
Using different drives work fine here (ie. G, Z or whatever else).
Did you test it using CLI? And running each test separately or using
one single script with all tests (stat cache will be used in this
case)?
Which windows version?
[2009-08-30 04:41:30] phpstuff at cresstone dot com
Hmmm. may have spoke too soon. Getting some weird results when working
with mounted volumes.
'C:\mnt\test\mounted_volume' is a junction mounted volume that is *not*
the system drive ie: not c:\
Take the following sequence of commands, working directory is
'C:\mnt\test\':
is_dir('mounted_volume');
Returns true, yay!
scandir('mounted_volume');
Here's the strange behavior; this command enumerates the root system
drive, c:\, rather than the correct pointed-to volume.
mkdir('mounted_volume\test34');
Returns true, but test32 is created on the incorrect volume: c:\test32
now exists
is_dir('mounted_volume\test34');
Returns FALSE, this is the correct behavior because the directory does
not exist in the correct location, but it is obviously inconsistent with
the above mkdir
unlink('mounted_volume\test34');
Throws a 'No such file or directory' warning. Appears to be looking in
the correct place.
My previous tests all used c:\ as the 'mounted volume' which is why I
didn't see this at first.
[2009-08-30 03:30:14] phpstuff at cresstone dot com
Latest snapshot give correct behavior for me. Thanks much.
[2009-08-30 02:09:06] paj...@php.net
@shoresofnowhere at gmail dot com
It is not correct, the correct behavior is relative to the target of
the link/junction, as it is on any other supported platforms with link
support. It was not the case in 5.2 but php did not support links
correctly (no link at all, and only partially for junction or mounted
drive).
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746&edit=1
#49408 [Fbk->Csd]: Wrong PHP Startup error messages
ID: 49408 User updated by: jo at feuersee dot de Reported By: jo at feuersee dot de -Status: Feedback +Status: Closed Bug Type: *General Issues Operating System: Linux PHP Version: 5.3.0 New Comment: Is fixed in current PHP 5.3.1-dev, verified with 200908301030 snapshot Previous Comments: [2009-08-30 01:25:01] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-08-29 21:44:11] jo at feuersee dot de Description: After upgrading to PHP 5.3.0 I wanted to clean up the pecl repos (I had the intl extension running with PHP 4.4) by issuing $ pecl uninstall intl Unfortunately, this didn't rm the intl.so in the directory where I installed it but the intl.so of PHP 5.3.0 (totally different directory). It took some time to figure this out because both CLI and Apache mod only stated some issue with the timezone settings (which are perfectly ok). Reproduce code: --- rm eg. the intl extension (intl.so), restart apache or just issue $ php -m Expected result: Requested extension 'intl.so' missing in '/usr/lib/php5/extensions' Actual result: -- PHP Fatal error: PHP Startup: Timezone database is corrupt - this should *never* happen! in Unknown on line 0 [Sat Aug 29 22:21:19 2009] [notice] seg fault or similar nasty error detected in the parent process PHP Warning: PHP Startup: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/?id=49408&edit=1
#49415 [Opn]: Allow multiple SMTP servers to be set for the php.ini setting SMTP
ID: 49415 Updated by: paj...@php.net Reported By: RQuadling at GMail dot com Status: Open Bug Type: Feature/Change Request Operating System: n/a PHP Version: 5.3.0 New Comment: I think it is the role of the delivery system on your system. PHP will simply use the served defined by php.ini, which should be safe. As I can imagine the usefulness of this feature when one uses only remote smtp servers, I do not think this is a common case. Production servers use local relay not remote servers (or should :). There are many servers who can be used as local relay, like sendmail.exe (never tested), hmailserver or mailenable. Previous Comments: [2009-08-30 10:55:35] RQuadling at GMail dot com Description: Hi. One of the "features" of Windows is no native SMTP server. One of the solutions is the use getmxrr() to find the recipients mail server and send to one of the servers listed. If the server fails you then have to run through the list and keep trying until it all goes off ok. It'd be nice if the php.ini setting SMTP allowed for multiple servers and have the mail() function automatically handle them. Ideally, being able to get the response of getmxrr() into the mail() function would be a nice solution. -- Edit this bug report at http://bugs.php.net/?id=49415&edit=1
#48746 [Fbk]: Unable to browse directories within Junction Points
ID: 48746
Updated by: paj...@php.net
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
Found the problems, the windows port of dirent (scandir) as well as
php_mkdir (used by mkdir()) lack a call to realpath, making them use the
current path with the standard API. It ends to use c:.
Testing the patch but it should do it for RC1 next Tuesday. You can
test the patch yourself by calling realpath manually:
scandir(realpath('mounted_volume')); or
mkdir(realpath('mounted_volume\\test34'));
Other files operations work as expected.
Previous Comments:
[2009-08-30 10:39:21] paj...@php.net
Using different drives work fine here (ie. G, Z or whatever else).
Did you test it using CLI? And running each test separately or using
one single script with all tests (stat cache will be used in this
case)?
Which windows version?
[2009-08-30 04:41:30] phpstuff at cresstone dot com
Hmmm. may have spoke too soon. Getting some weird results when working
with mounted volumes.
'C:\mnt\test\mounted_volume' is a junction mounted volume that is *not*
the system drive ie: not c:\
Take the following sequence of commands, working directory is
'C:\mnt\test\':
is_dir('mounted_volume');
Returns true, yay!
scandir('mounted_volume');
Here's the strange behavior; this command enumerates the root system
drive, c:\, rather than the correct pointed-to volume.
mkdir('mounted_volume\test34');
Returns true, but test32 is created on the incorrect volume: c:\test32
now exists
is_dir('mounted_volume\test34');
Returns FALSE, this is the correct behavior because the directory does
not exist in the correct location, but it is obviously inconsistent with
the above mkdir
unlink('mounted_volume\test34');
Throws a 'No such file or directory' warning. Appears to be looking in
the correct place.
My previous tests all used c:\ as the 'mounted volume' which is why I
didn't see this at first.
[2009-08-30 03:30:14] phpstuff at cresstone dot com
Latest snapshot give correct behavior for me. Thanks much.
[2009-08-30 02:09:06] paj...@php.net
@shoresofnowhere at gmail dot com
It is not correct, the correct behavior is relative to the target of
the link/junction, as it is on any other supported platforms with link
support. It was not the case in 5.2 but php did not support links
correctly (no link at all, and only partially for junction or mounted
drive).
[2009-08-29 20:34:10] shoresofnowhere at gmail dot com
Still not working correctly in latest snapshot: now if you have
dir1 directory
subdir1 subdirectory of dir1
dir2 directory
junction1 junction to subdir1 created in dir2
and from a file accessed as dir2/junction1/file.php you reference to
the ../ dir, you get to the dir1 directory, while the correct behaviour
is to get to dir2!
You can see the difference if you try this setup with 5.2.10, which
works ok.
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746&edit=1
#49415 [NEW]: Allow multiple SMTP servers to be set for the php.ini setting SMTP
From: RQuadling at GMail dot com Operating system: n/a PHP version: 5.3.0 PHP Bug Type: Feature/Change Request Bug description: Allow multiple SMTP servers to be set for the php.ini setting SMTP Description: Hi. One of the "features" of Windows is no native SMTP server. One of the solutions is the use getmxrr() to find the recipients mail server and send to one of the servers listed. If the server fails you then have to run through the list and keep trying until it all goes off ok. It'd be nice if the php.ini setting SMTP allowed for multiple servers and have the mail() function automatically handle them. Ideally, being able to get the response of getmxrr() into the mail() function would be a nice solution. -- Edit bug report at http://bugs.php.net/?id=49415&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49415&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49415&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49415&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49415&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49415&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49415&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49415&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49415&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49415&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49415&r=support Expected behavior: http://bugs.php.net/fix.php?id=49415&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49415&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49415&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49415&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49415&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49415&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49415&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49415&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49415&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49415&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49415&r=mysqlcfg
#48746 [Fbk]: Unable to browse directories within Junction Points
ID: 48746
Updated by: paj...@php.net
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
Using different drives work fine here (ie. G, Z or whatever else).
Did you test it using CLI? And running each test separately or using
one single script with all tests (stat cache will be used in this
case)?
Which windows version?
Previous Comments:
[2009-08-30 04:41:30] phpstuff at cresstone dot com
Hmmm. may have spoke too soon. Getting some weird results when working
with mounted volumes.
'C:\mnt\test\mounted_volume' is a junction mounted volume that is *not*
the system drive ie: not c:\
Take the following sequence of commands, working directory is
'C:\mnt\test\':
is_dir('mounted_volume');
Returns true, yay!
scandir('mounted_volume');
Here's the strange behavior; this command enumerates the root system
drive, c:\, rather than the correct pointed-to volume.
mkdir('mounted_volume\test34');
Returns true, but test32 is created on the incorrect volume: c:\test32
now exists
is_dir('mounted_volume\test34');
Returns FALSE, this is the correct behavior because the directory does
not exist in the correct location, but it is obviously inconsistent with
the above mkdir
unlink('mounted_volume\test34');
Throws a 'No such file or directory' warning. Appears to be looking in
the correct place.
My previous tests all used c:\ as the 'mounted volume' which is why I
didn't see this at first.
[2009-08-30 03:30:14] phpstuff at cresstone dot com
Latest snapshot give correct behavior for me. Thanks much.
[2009-08-30 02:09:06] paj...@php.net
@shoresofnowhere at gmail dot com
It is not correct, the correct behavior is relative to the target of
the link/junction, as it is on any other supported platforms with link
support. It was not the case in 5.2 but php did not support links
correctly (no link at all, and only partially for junction or mounted
drive).
[2009-08-29 20:34:10] shoresofnowhere at gmail dot com
Still not working correctly in latest snapshot: now if you have
dir1 directory
subdir1 subdirectory of dir1
dir2 directory
junction1 junction to subdir1 created in dir2
and from a file accessed as dir2/junction1/file.php you reference to
the ../ dir, you get to the dir1 directory, while the correct behaviour
is to get to dir2!
You can see the difference if you try this setup with 5.2.10, which
works ok.
[2009-08-29 12:23:01] paj...@php.net
Thanks for the testing! :)
Added support for mounted volumes (and path resolutions for them). The
next snapshots (5.3+) should have it.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/48746
--
Edit this bug report at http://bugs.php.net/?id=48746&edit=1
