#46063 [NEW]: SoapFault exception: [HTTP] Error Fetching http headers
From: filip_stjernberg at hotmaol dot com
Operating system: Windows vista
PHP version: 5.2.6
PHP Bug Type: SOAP related
Bug description: SoapFault exception: [HTTP] Error Fetching http headers
Description:
I'm trying to use an existing webservice:
http://testhorizon.gothiagroup.com/AFSServices/AFSService.svc?wsdl
There is a simple test function called "HelloWorld" that returns the input
"myVaule". This function dos not need authentification but its more advaced
one do.
Really need this to work, have tried nuSOAP to but that gives me other
problems.
Reproduce code:
---
This is the code I use:
try{
$wsdl =
'http://testhorizon.gothiagroup.com/AFSServices/AFSService.svc?wsdl';
$client = new SoapClient($wsdl,
array(
'soap_version' => SOAP_1_2,
'trace' => 1,
'exceptions' => 1
));
print($client->HelloWorld(array('myValue' => 'Test')));
} catch (Exception $e) {
printf("Message = %s\n",$e->__toString());
}
print "n";
print "Request :n".htmlspecialchars($client->__getLastRequest()) ."n";
print "Response:n".htmlspecialchars($client->__getLastResponse())."n";
print "";
Expected result:
Hello from AFSService: Test
Actual result:
--
Message = SoapFault exception: [HTTP] Error Fetching http headers in
/customers/veus.se/veus.se/httpd.www/Test/samples/AFSWS1.php:20 Stack
trace: #0 [internal function]: SoapClient->__doRequest('http://testhori...', 'http://tempuri', 2, 0) #1
[internal function]: SoapClient->__call('HelloWorld', Array) #2
/customers/veus.se/veus.se/httpd.www/Test/samples/AFSWS1.php(20):
SoapClient->HelloWorld(Array) #3 {main}
nRequest :n
http://www.w3.org/2003/05/soap-envelope";
xmlns:ns1="http://tempuri.org/";>Exor
nResponse:nn
--
Edit bug report at http://bugs.php.net/?id=46063&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46063&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46063&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46063&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=46063&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=46063&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=46063&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=46063&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=46063&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=46063&r=support
Expected behavior:http://bugs.php.net/fix.php?id=46063&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46063&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46063&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=46063&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46063&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=46063&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=46063&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=46063&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=46063&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=46063&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=46063&r=mysqlcfg
#46061 [Opn->Bgs]: trim could not work as expected
ID: 46061 Updated by: [EMAIL PROTECTED] Reported By: ddrplayer at foxmail dot com -Status: Open +Status: Bogus Bug Type: *Directory/Filesystem functions Operating System: Linux PHP Version: 5.2CVS-2008-09-12 (snap) 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 The second argument expects a char list. Previous Comments: [2008-09-12 04:03:55] ddrplayer at foxmail dot com Description: hi , first of all sorry for my bad english but trim could not work as expected i run the program in 5.14,5.25 ,it could not work as expected. Reproduce code: --- '; $s='hello world '; echo trim($s,''); ?> Expected result: hello world Actual result: -- hello world http://bugs.php.net/?id=46061&edit=1
#46064 [NEW]: Exception on ReflectionProperty created on dynamicly created property
From: zemi dot inet at gmail dot com
Operating system: Linux amoeba 2.6.22-14-server
PHP version: 5.2.6
PHP Bug Type: Reflection related
Bug description: Exception on ReflectionProperty created on dynamicly created
property
Description:
Always getting exception when creating ReflectionProperty object on
dynamicly created property.
Discovered when I tried to use ReflectionProperty::isDefault().
I presume it returns true when property is created on compile-time and
false when dynamicly created on run-time?
Reproduce code:
---
class x {
public $x = 1;
public $y = 1;
}
$o = new x;
$o->z = 1;
$reflector = new ReflectionProperty($o, 'z');
$d = $reflector->isDefault();
Expected result:
$d == false
Actual result:
--
Fatal error: Uncaught exception 'ReflectionException' with message
'Property x::$z does not exist' on line: $reflector = new
ReflectionProperty($o, 'z');
--
Edit bug report at http://bugs.php.net/?id=46064&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46064&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46064&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46064&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=46064&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=46064&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=46064&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=46064&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=46064&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=46064&r=support
Expected behavior:http://bugs.php.net/fix.php?id=46064&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46064&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46064&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=46064&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46064&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=46064&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=46064&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=46064&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=46064&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=46064&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=46064&r=mysqlcfg
#46059 [Opn->Fbk]: Compile failure under IRIX 6.5.30 building posix.c
ID: 46059 Updated by: [EMAIL PROTECTED] Reported By: neko at nekochan dot net -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: IRIX 6.5.30 PHP Version: 5.3.0alpha2 New Comment: Please try the following patch: http://arnaud.lb.s3.amazonaws.com/utsname_domainname.patch (run ./buildconf, then re-configure) Previous Comments: [2008-09-11 20:24:15] neko at nekochan dot net Description: Able to compile up to and including php-5.2.6 without error (and run in a production environment). My attempt to build php-5.3.0alpha2 dies in posix.c (The struct "utsname" has no field "domainname".). Reproduce code: --- IRIX64 Kazehana 6.5 6.5.30f 07202013 IP35 MIPSpro Compilers: Version 7.4.4m './configure' '--prefix=/usr/nekoware/php5' '--enable-dba' '--enable-dbx' '--enable-calendar' '--enable-wddx' '--with-config-file-path=/usr/nekoware/etc/php5' '--with-apxs2=/usr/nekoware/apache2/bin/apxs' '--enable-cli' '--with-libxml-dir=/usr/nekoware' '--with-expat-dir=/usr/nekoware' '--with-png-dir=/usr/nekoware' '--with-jpeg-dir=/usr/nekoware' '--with-freetype-dir=/usr/nekoware' '--with-zlib-dir=/usr/nekoware' '--with-zlib' '--with-curlwrappers' '--with-curl=shared,/usr/nekoware' '--with-openssl=shared,/usr/nekoware' '--with-mysql=shared,mysqlnd' '--with-mysqli=shared,mysqlnd' '--with-mhash=shared,/usr/nekoware' '--with-mcrypt=shared,/usr/nekoware' '--with-bz2=shared,/usr/nekoware' '--enable-ftp=shared' '--enable-sockets=shared' '--with-gd=shared '--enable-exif=shared' '--enable-dbase=shared' '--with-xmlrpc' '--with-gettext=shared,/usr/nekoware' '--with-iconv-dir=/usr/nekoware' '--enable-mbstring=shared' '--enable-sysvsem=shared' '--enable-sysvshm=shared' '--enable-sysvmsg=shared' '--with-xpm-dir=/usr/lib32' '--enable-zip=shared' '--with-pgsql=shared,/usr/nekoware/pgsql' '--disable-fileinfo' '--disable-phar' '--with-tsrm-st' Expected result: Completed build. Actual result: -- /bin/sh /opt/build/php-5.3.0alpha2/libtool --silent --preserve-dup-deps --mode=compile c99 -Iext/posix/ -I/opt/build/php-5.3.0alpha2/ext/posix/ -DPHP_ATOM_INC -I/opt/build/php-5.3.0alpha2/include -I/opt/build/php-5.3.0alpha2/main -I/opt/build/php-5.3.0alpha2 -I/opt/build/php-5.3.0alpha2/ext/ereg/regex -I/usr/nekoware/include/libxml2 -I/usr/nekoware/include -I/opt/build/php-5.3.0alpha2/ext/date/lib -I/usr/nekoware/include/freetype2 -I/opt/build/php-5.3.0alpha2/ext/mbstring/oniguruma -I/opt/build/php-5.3.0alpha2/ext/mbstring/libmbfl -I/opt/build/php-5.3.0alpha2/ext/mbstring/libmbfl/mbfl -I/opt/build/php-5.3.0alpha2/ext/sqlite3/libsqlite -I/usr/nekoware/pgsql/include -I/opt/build/php-5.3.0alpha2/TSRM -I/opt/build/php-5.3.0alpha2/Zend -D_XPG_IV -L/usr/nekoware/lib -L/usr/lib32 -I/usr/include -mips4 -O2 -I/usr/nekoware/include -I/usr/include -Wl,-rpath -Wl,/usr/nekoware/lib:/usr/nekoware/mysql5/lib/mysql -OPT:Olimit=0:roundoff=3 -TARG:platform=IP35:proc=r16000 -c /opt/build/php-5.3.0alpha2/ext/posix/posix.c -o ext/posix/posix.lo cc-3604 c99: WARNING File = /opt/build/php-5.3.0alpha2/Zend/zend_alloc.h, Line = 87 missing return statement at end of non-void function "__zend_malloc" } ^ cc-3604 c99: WARNING File = /opt/build/php-5.3.0alpha2/Zend/zend_alloc.h, Line = 104 missing return statement at end of non-void function "__zend_realloc" } ^ cc-3970 c99: WARNING File = /opt/build/php-5.3.0alpha2/Zend/zend_execute.h, Line = 70 conversion from pointer to same-sized integral type (potential portability problem) FREE_ZVAL_REL(p); ^ cc-3970 c99: WARNING File = /opt/build/php-5.3.0alpha2/Zend/zend_execute.h, Line = 272 conversion from pointer to same-sized integral type (potential portability problem) int delete_count = (int)(zend_uintptr_t) *p; ^ cc-3970 c99: WARNING File = /opt/build/php-5.3.0alpha2/Zend/zend_execute.h, Line = 285 conversion from pointer to same-sized integral type (potential portability problem) int arg_count = (int)(zend_uintptr_t) *p; ^ cc-1565 c99: ERROR File = /opt/build/php-5.3.0alpha2/ext/posix/posix.c, Line = 671 The struct "utsname" has no field "domainname". add_assoc_string(return_value, "domainname", u.domainname, 1); ^ cc-3968 c99: WARNING File = /opt/build/php-5.3.0alpha2/ext/posix/posix.c, Line = 1267 implicit conversion of a 64-bit integral type to a smaller integral type (potential portability problem) add_assoc_long(return_value, soft, rl.rlim_cur); ^ cc-3968 c99: WARNING File = /opt/build/php-5.3.0alpha2/ext/posix/posix.c, Line = 1273 implicit conversion of a 64-bit integral type to a smaller integral type (potential portability problem) add_assoc
#45994 [Opn->Fbk]: "\" directive in php.ini, DISABLES ALL non-built-in php extensions
ID: 45994 Updated by: [EMAIL PROTECTED] Reported By: ipseno at yahoo dot com -Status: Open +Status: Feedback Bug Type: PHP options/info functions Operating System: Windows XP SP3 PHP Version: 5.3.0alpha2 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.3-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.3-win32-installer-latest.msi Previous Comments: [2008-09-04 20:46:41] [EMAIL PROTECTED] As mentioned on the internals list, this should cause a syntax error. Much like in PHP code this would not work: [2008-09-04 16:22:54] [EMAIL PROTECTED] We're talking about ini files here, we always had different rules in ini files than regular code! Not sure if this is caused by Jani's improvements in the parsing or by some re2c work, but it should certainly work as before else many Windows users will have this issue! [2008-09-04 14:46:00] ipseno at yahoo dot com Wait, wait... Now I know, why did I posted this question... Now I reverted PHP to version 5.2.6 And there is NO problems with: upload_tmp_dir = "E:\" BUT, when i copy that php.ini file to PHP 5.3 alpha2 THEN upload_tmp_dir = "E:\" causes behavior as explained above. That is a reason why did I cretaed this "bug" report In 5.2.6 "\" doesn't escape, but in 5.3 alpha2 it does! How come?! [2008-09-04 14:20:26] ipseno at yahoo dot com Actually... "\" at the END of ANY directive in php.ini breaks configuration under WinXP Ie: error_log = "E:\php-5.3.0alpha2\error.log\" variables_order = "GPCS\" [2008-09-04 13:54:00] ipseno at yahoo dot com Description: upload_tmp_dir directive in php.ini, DISABLES ALL non-built-in php extensions To recreate this: In php.ini set: upload_tmp_dir = "E:\" create .php file Under windows xp sp3 Apache/2.2.9b, parse it by php-cgi.exe Now skip to upload_tmp_dir section, of generated page and look at a HUGE part of php.ini copied in that filed! That is..., everything from line upload_tmp_dir = "E:\", till the end of php.ini Commenting it out in php.ini. ;upload_tmp_dir = "E:\" OR shifting slash!!! upload_tmp_dir = "E:/" ...fixes it and enables all extensions again! Actual result: -- This is VERY POSSIBLE SOLUTION to: Bug #13290 extension_dir directive is not working -- Edit this bug report at http://bugs.php.net/?id=45994&edit=1
#45994 [Fbk->Opn]: "\" directive in php.ini, DISABLES ALL non-built-in php extensions
ID: 45994 User updated by: ipseno at yahoo dot com Reported By: ipseno at yahoo dot com -Status: Feedback +Status: Open Bug Type: PHP options/info functions Operating System: Windows XP SP3 PHP Version: 5.3.0alpha2 New Comment: Thanks. I'll "play" with it... Previous Comments: [2008-09-12 13:00:50] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.3-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.3-win32-installer-latest.msi [2008-09-04 20:46:41] [EMAIL PROTECTED] As mentioned on the internals list, this should cause a syntax error. Much like in PHP code this would not work: [2008-09-04 16:22:54] [EMAIL PROTECTED] We're talking about ini files here, we always had different rules in ini files than regular code! Not sure if this is caused by Jani's improvements in the parsing or by some re2c work, but it should certainly work as before else many Windows users will have this issue! [2008-09-04 14:46:00] ipseno at yahoo dot com Wait, wait... Now I know, why did I posted this question... Now I reverted PHP to version 5.2.6 And there is NO problems with: upload_tmp_dir = "E:\" BUT, when i copy that php.ini file to PHP 5.3 alpha2 THEN upload_tmp_dir = "E:\" causes behavior as explained above. That is a reason why did I cretaed this "bug" report In 5.2.6 "\" doesn't escape, but in 5.3 alpha2 it does! How come?! [2008-09-04 14:20:26] ipseno at yahoo dot com Actually... "\" at the END of ANY directive in php.ini breaks configuration under WinXP Ie: error_log = "E:\php-5.3.0alpha2\error.log\" variables_order = "GPCS\" 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/45994 -- Edit this bug report at http://bugs.php.net/?id=45994&edit=1
#46065 [NEW]: Unexpected behavior snmp_set_quick_print()
From: php at painfullscratch dot nl Operating system: Linux PHP version: 5.2.6 PHP Bug Type: SNMP related Bug description: Unexpected behavior snmp_set_quick_print() Description: When PHP runs under Apache and snmp_set_quick_print(TRUE) is issued, the behavior of all SNMP-related functions will be "quick print" for the lifetime of the PID. NET-SNMP Support => enabled NET-SNMP Version => 5.4.1 PHP version: 5.2.4 There are two possibilities: 1) This behavior is "by design": If this is the case I think the manual page for snmp_set_quick_print() needs a warning for this behavior. 2) This is a bug: For each PID the behavior should be (re)set to the default behavior after execution of the script. Reproduce code: --- [EMAIL PROTECTED]:/tmp$ sudo /etc/init.d/apache2 restart > /dev/null 2>&1 [EMAIL PROTECTED]:/tmp$ for (( i=0; i<5; i++ )) ; do links -dump http://localhost/snmp_get_quick_print.php; done snmp_get_quick_print: '' | pid: '9402' snmp_get_quick_print: '' | pid: '9403' snmp_get_quick_print: '' | pid: '9404' snmp_get_quick_print: '' | pid: '9405' snmp_get_quick_print: '' | pid: '9406' [EMAIL PROTECTED]:/tmp$ links -dump http://localhost/snmp_set_quick_print.php snmp_set_quick_print: '' | pid: '9406' [EMAIL PROTECTED]:/tmp$ for (( i=0; i<5; i++ )) ; do links -dump http://localhost/snmp_get_quick_print.php; done snmp_get_quick_print: '' | pid: '9403' snmp_get_quick_print: '' | pid: '9404' snmp_get_quick_print: '' | pid: '9446' snmp_get_quick_print: '' | pid: '9405' snmp_get_quick_print: '1' | pid: '9406' -- Edit bug report at http://bugs.php.net/?id=46065&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46065&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46065&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46065&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46065&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=46065&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46065&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=46065&r=needscript Try newer version:http://bugs.php.net/fix.php?id=46065&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46065&r=support Expected behavior:http://bugs.php.net/fix.php?id=46065&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46065&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46065&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46065&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46065&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=46065&r=dst IIS Stability:http://bugs.php.net/fix.php?id=46065&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46065&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46065&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46065&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=46065&r=mysqlcfg
#46064 [Opn]: Exception when creating ReflectionProperty object on dynamicly created property
ID: 46064
User updated by: zemi dot inet at gmail dot com
-Summary: Exception on ReflectionProperty created on dynamicly
created property
Reported By: zemi dot inet at gmail dot com
Status: Open
Bug Type: Reflection related
Operating System: Linux amoeba 2.6.22-14-server
PHP Version: 5.2.6
New Comment:
more meaningful summary
Previous Comments:
[2008-09-12 11:16:08] zemi dot inet at gmail dot com
Description:
Always getting exception when creating ReflectionProperty object on
dynamicly created property.
Discovered when I tried to use ReflectionProperty::isDefault().
I presume it returns true when property is created on compile-time and
false when dynamicly created on run-time?
Reproduce code:
---
class x {
public $x = 1;
public $y = 1;
}
$o = new x;
$o->z = 1;
$reflector = new ReflectionProperty($o, 'z');
$d = $reflector->isDefault();
Expected result:
$d == false
Actual result:
--
Fatal error: Uncaught exception 'ReflectionException' with message
'Property x::$z does not exist' on line: $reflector = new
ReflectionProperty($o, 'z');
--
Edit this bug report at http://bugs.php.net/?id=46064&edit=1
#46066 [NEW]: Regular Expression differences between 4.4 and 5.2
From: ewen dot cumming at gmail dot com
Operating system: Debian Linux
PHP version: 5.2CVS-2008-09-12 (snap)
PHP Bug Type: PCRE related
Bug description: Regular Expression differences between 4.4 and 5.2
Description:
In upgrading our code base from PHP4.4 to 5.2 I found the same regular
exression would give different results.
Apologies for the large include string and results, however if I reduce
the input string any more the problem doesn't occur.
I have tested with:
PHP 4.4.4-8+etch6 (cli) (built: May 16 2008 15:59:34)
Zend Engine v1.3.0
PHP 5.2.0-8+etch11 (cli) (built: May 10 2008 10:46:24)
Zend Engine v2.2.0
And before submitting the bug:
PHP 5.2.7-dev (cli) (built: Sep 12 2008 15:05:09)
Zend Engine v2.2.0
Reproduce code:
---
http://www.workingweb.nl/example/input.inc' );
$pattern = "/ ]+)([^>]*)>(.*?)|
]+)([^>]*)>/si";
preg_match_all( $pattern, $string, $matches );
var_dump($matches);
?>
Expected result:
This is what I get in PHP4.4 (and what I would expect after an PHP5.2
upgrade).
array(6) {
[0]=>
array(22) {
[0]=>
string(31) ""
[1]=>
string(15) ""
[2]=>
string(11) ""
[3]=>
string(16) ""
[4]=>
string(12) ""
[5]=>
string(17) ""
[6]=>
string(13) ""
[7]=>
string(17) ""
[8]=>
string(13) ""
[9]=>
string(21) ""
[10]=>
string(18) ""
[11]=>
string(25) ""
[12]=>
string(20) ""
[13]=>
string(15) ""
[14]=>
string(20) ""
[15]=>
string(20) ""
[16]=>
string(13) ""
[17]=>
string(18) ""
[18]=>
string(25) ""
[19]=>
string(21) ""
[20]=>
string(16) ""
[21]=>
string(15) ""
}
[1]=>
array(22) {
[0]=>
string(0) ""
[1]=>
string(0) ""
[2]=>
string(0) ""
[3]=>
string(0) ""
[4]=>
string(0) ""
[5]=>
string(0) ""
[6]=>
string(0) ""
[7]=>
string(0) ""
[8]=>
string(0) ""
[9]=>
string(0) ""
[10]=>
string(0) ""
[11]=>
string(0) ""
[12]=>
string(0) ""
[13]=>
string(0) ""
[14]=>
string(0) ""
[15]=>
string(0) ""
[16]=>
string(0) ""
[17]=>
string(0) ""
[18]=>
string(0) ""
[19]=>
string(0) ""
[20]=>
string(0) ""
[21]=>
string(0) ""
}
[2]=>
array(22) {
[0]=>
string(0) ""
[1]=>
string(0) ""
[2]=>
string(0) ""
[3]=>
string(0) ""
[4]=>
string(0) ""
[5]=>
string(0) ""
[6]=>
string(0) ""
[7]=>
string(0) ""
[8]=>
string(0) ""
[9]=>
string(0) ""
[10]=>
string(0) ""
[11]=>
string(0) ""
[12]=>
string(0) ""
[13]=>
string(0) ""
[14]=>
string(0) ""
[15]=>
string(0) ""
[16]=>
string(0) ""
[17]=>
string(0) ""
[18]=>
string(0) ""
[19]=>
string(0) ""
[20]=>
string(0) ""
[21]=>
string(0) ""
}
[3]=>
array(22) {
[0]=>
string(0) ""
[1]=>
string(0) ""
[2]=>
string(0) ""
[3]=>
string(0) ""
[4]=>
string(0) ""
[5]=>
string(0) ""
[6]=>
string(0) ""
[7]=>
string(0) ""
[8]=>
string(0) ""
[9]=>
string(0) ""
[10]=>
string(0) ""
[11]=>
string(0) ""
[12]=>
string(0) ""
[13]=>
string(0) ""
[14]=>
string(0) ""
[15]=>
string(0) ""
[16]=>
string(0) ""
[17]=>
string(0) ""
[18]=>
string(0) ""
[19]=>
string(0) ""
[20]=>
string(0) ""
[21]=>
string(0) ""
}
[4]=>
array(22) {
[0]=>
string(26) "lang_searchforpublications"
[1]=>
string(10) "lang_title"
[2]=>
string(6) "fTitle"
[3]=>
string(11) "lang_author"
[4]=>
string(7) "fAuthor"
[5]=>
string(12) "lang_session"
[6]=>
string(8) "fSession"
[7]=>
string(12) "lang_summary"
[8]=>
string(8) "butCheck"
[9]=>
string(16) "lang_showsummary"
[10]=>
string(13) "lang_language"
[11]=>
string(20) "languageselectwidget"
[12]=>
string(15) "lang_daterange1"
[13]=>
string(10) "lang_start"
[14]=>
string(15) "startdateWidget"
[15]=>
string(15) "lang_daterange2"
[16]=>
string(8) "lang_end"
[17]=>
string(13) "enddateWidget"
[18]=>
string(20) "lang_publicationtype"
[19]=>
string(16) "pubtypeselectbox"
[20]=>
string(11) "lang_search"
[21]=>
string(10) "lang_clear"
}
[5]=>
array(22) {
[0]=>
string(0) ""
[1]=>
string(0) ""
[2]=>
string(0) ""
[3]=>
string(0) ""
[4]=>
string(0) ""
[5]=>
string(0) ""
[6]=>
string(0) ""
[7]=>
string(0) ""
[8]=>
string(0) ""
[9]=>
string(0) ""
[10]=>
string(0) ""
[11]=>
string(0) ""
[12]=>
string(0) ""
[13]=>
string(0) ""
[14]=>
string(
#46066 [Opn]: Regular Expression differences between 4.4 and 5.2
ID: 46066
User updated by: ewen dot cumming at gmail dot com
Reported By: ewen dot cumming at gmail dot com
Status: Open
Bug Type: PCRE related
Operating System: Debian Linux
PHP Version: 5.2CVS-2008-09-12 (snap)
New Comment:
Note there should be a space in my reproduce code regex (where the line
break happened to occur):
The below should set it right:
$pattern = "/ ]+)([^>]*)>(.*?)".
"| ]+)([^>]*)>/si";
Previous Comments:
[2008-09-12 14:05:28] ewen dot cumming at gmail dot com
Description:
In upgrading our code base from PHP4.4 to 5.2 I found the same regular
exression would give different results.
Apologies for the large include string and results, however if I reduce
the input string any more the problem doesn't occur.
I have tested with:
PHP 4.4.4-8+etch6 (cli) (built: May 16 2008 15:59:34)
Zend Engine v1.3.0
PHP 5.2.0-8+etch11 (cli) (built: May 10 2008 10:46:24)
Zend Engine v2.2.0
And before submitting the bug:
PHP 5.2.7-dev (cli) (built: Sep 12 2008 15:05:09)
Zend Engine v2.2.0
Reproduce code:
---
http://www.workingweb.nl/example/input.inc' );
$pattern = "/ ]+)([^>]*)>(.*?)|
]+)([^>]*)>/si";
preg_match_all( $pattern, $string, $matches );
var_dump($matches);
?>
Expected result:
This is what I get in PHP4.4 (and what I would expect after an PHP5.2
upgrade).
array(6) {
[0]=>
array(22) {
[0]=>
string(31) ""
[1]=>
string(15) ""
[2]=>
string(11) ""
[3]=>
string(16) ""
[4]=>
string(12) ""
[5]=>
string(17) ""
[6]=>
string(13) ""
[7]=>
string(17) ""
[8]=>
string(13) ""
[9]=>
string(21) ""
[10]=>
string(18) ""
[11]=>
string(25) ""
[12]=>
string(20) ""
[13]=>
string(15) ""
[14]=>
string(20) ""
[15]=>
string(20) ""
[16]=>
string(13) ""
[17]=>
string(18) ""
[18]=>
string(25) ""
[19]=>
string(21) ""
[20]=>
string(16) ""
[21]=>
string(15) ""
}
[1]=>
array(22) {
[0]=>
string(0) ""
[1]=>
string(0) ""
[2]=>
string(0) ""
[3]=>
string(0) ""
[4]=>
string(0) ""
[5]=>
string(0) ""
[6]=>
string(0) ""
[7]=>
string(0) ""
[8]=>
string(0) ""
[9]=>
string(0) ""
[10]=>
string(0) ""
[11]=>
string(0) ""
[12]=>
string(0) ""
[13]=>
string(0) ""
[14]=>
string(0) ""
[15]=>
string(0) ""
[16]=>
string(0) ""
[17]=>
string(0) ""
[18]=>
string(0) ""
[19]=>
string(0) ""
[20]=>
string(0) ""
[21]=>
string(0) ""
}
[2]=>
array(22) {
[0]=>
string(0) ""
[1]=>
string(0) ""
[2]=>
string(0) ""
[3]=>
string(0) ""
[4]=>
string(0) ""
[5]=>
string(0) ""
[6]=>
string(0) ""
[7]=>
string(0) ""
[8]=>
string(0) ""
[9]=>
string(0) ""
[10]=>
string(0) ""
[11]=>
string(0) ""
[12]=>
string(0) ""
[13]=>
string(0) ""
[14]=>
string(0) ""
[15]=>
string(0) ""
[16]=>
string(0) ""
[17]=>
string(0) ""
[18]=>
string(0) ""
[19]=>
string(0) ""
[20]=>
string(0) ""
[21]=>
string(0) ""
}
[3]=>
array(22) {
[0]=>
string(0) ""
[1]=>
string(0) ""
[2]=>
string(0) ""
[3]=>
string(0) ""
[4]=>
string(0) ""
[5]=>
string(0) ""
[6]=>
string(0) ""
[7]=>
string(0) ""
[8]=>
string(0) ""
[9]=>
string(0) ""
[10]=>
string(0) ""
[11]=>
string(0) ""
[12]=>
string(0) ""
[13]=>
string(0) ""
[14]=>
string(0) ""
[15]=>
string(0) ""
[16]=>
string(0) ""
[17]=>
string(0) ""
[18]=>
string(0) ""
[19]=>
string(0) ""
[20]=>
string(0) ""
[21]=>
string(0) ""
}
[4]=>
array(22) {
[0]=>
string(26) "lang_searchforpublications"
[1]=>
string(10) "lang_title"
[2]=>
string(6) "fTitle"
[3]=>
string(11) "lang_author"
[4]=>
string(7) "fAuthor"
[5]=>
string(12) "lang_session"
[6]=>
string(8) "fSession"
[7]=>
string(12) "lang_summary"
[8]=>
string(8) "butCheck"
[9]=>
string(16) "lang_showsummary"
[10]=>
string(13) "lang_language"
[11]=>
string(20) "languageselectwidget"
[12]=>
string(15) "lang_daterange1"
[13]=>
string(10) "lang_start"
[14]=>
string(15) "startdateWidget"
[15]=>
string(15) "lang_daterange2"
[16]=>
string(8) "lang_end"
[17]=>
string(13) "enddateWidget"
[18]=>
string(20) "lang_publicationtype"
[19]=>
string(16) "pubtypeselectbox"
[20]=>
string(11) "lang_search"
[21]=>
string(10) "lang_clear"
}
[5]=>
array(22) {
[0]=>
str
#45837 [Ver->Csd]: open_basedir failed for building outside of source tree
ID: 45837 Updated by: [EMAIL PROTECTED] Reported By: xuefer at gmail dot com -Status: Verified +Status: Closed Bug Type: Safe Mode/open_basedir Operating System: linux PHP Version: 5.3CVS ZTS New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2008-08-17 13:15:58] xuefer at gmail dot com forgot to note that, when it is build outside of source tree, there're more test cases failed than i listed [2008-08-17 09:28:24] [EMAIL PROTECTED] Reproducible on ZTS builds [2008-08-17 03:28:44] xuefer at gmail dot com Description: my php is built outside of the php source tree, i'm not sure if this is the reason as i haven't try to built php witin source tree yet. looks like most of the open_basedir* test failed and btw tests/basic/bug20539.phpt also failed due to the same problem imho. Reproduce code: --- ~/src/php5 $ cd ../php5-debug-zts ~/src/php5-debug-zts $ ../php5/configure ... ~/src/php5-debug-zts $ make && make test Actual result: -- Bug #20539 (PHP CLI Segmentation Fault) [tests/basic/bug20539.phpt] Test open_basedir configuration [tests/security/open_basedir_chdir.phpt] Test open_basedir configuration [tests/security/open_basedir_chmod.phpt] Test open_basedir configuration [tests/security/open_basedir_copy.phpt] Test open_basedir configuration [tests/security/open_basedir_copy_variation1.phpt] Test open_basedir configuration [tests/security/open_basedir_dir.phpt] Test open_basedir configuration [tests/security/open_basedir_disk_free_space.phpt] Test open_basedir configuration [tests/security/open_basedir_error_log.phpt] Test open_basedir configuration [tests/security/open_basedir_error_log_variation.phpt] Test open_basedir configuration [tests/security/open_basedir_file.phpt] Test open_basedir configuration [tests/security/open_basedir_file_exists.phpt] Test open_basedir configuration [tests/security/open_basedir_file_get_contents.phpt] Test open_basedir configuration [tests/security/open_basedir_file_put_contents.phpt] Test open_basedir configuration [tests/security/open_basedir_fileatime.phpt] Test open_basedir configuration [tests/security/open_basedir_filectime.phpt] Test open_basedir configuration [tests/security/open_basedir_filegroup.phpt] Test open_basedir configuration [tests/security/open_basedir_fileinode.phpt] Test open_basedir configuration [tests/security/open_basedir_filemtime.phpt] Test open_basedir configuration [tests/security/open_basedir_fileowner.phpt] Test open_basedir configuration [tests/security/open_basedir_fileperms.phpt] Test open_basedir configuration [tests/security/open_basedir_filesize.phpt] Test open_basedir configuration [tests/security/open_basedir_filetype.phpt] Test open_basedir configuration [tests/security/open_basedir_fopen.phpt] Test open_basedir configuration [tests/security/open_basedir_glob.phpt] Test open_basedir configuration [tests/security/open_basedir_is_dir.phpt] Test open_basedir configuration [tests/security/open_basedir_is_executable.phpt] Test open_basedir configuration [tests/security/open_basedir_is_file.phpt] Test open_basedir configuration [tests/security/open_basedir_is_link.phpt] Test open_basedir configuration [tests/security/open_basedir_is_readable.phpt] Test open_basedir configuration [tests/security/open_basedir_is_writable.phpt] Test open_basedir configuration [tests/security/open_basedir_link.phpt] Test open_basedir configuration [tests/security/open_basedir_linkinfo.phpt] Test open_basedir configuration [tests/security/open_basedir_lstat.phpt] Test open_basedir configuration [tests/security/open_basedir_opendir.phpt] Test open_basedir configuration [tests/security/open_basedir_readlink.phpt] Test open_basedir configuration [tests/security/open_basedir_rename.phpt] Test open_basedir configuration [tests/security/open_basedir_rmdir.phpt] Test open_basedir configuration [tests/security/open_basedir_scandir.phpt] Test open_basedir configuration [tests/security/open_basedir_stat.phpt] Test open_basedir configuration [tests/security/open_basedir_symlink.phpt] Test open_basedir configuration [tests/security/open_basedir_tempnam.phpt] Test open_basedir configuration [tests/security/open_basedir_touch.phpt] Test open_basedir configuration [tests/security/open_basedir_unlink.phpt] /home/xuefer/src/php5/tests/basic/bug20539.phpt Warning
#45994 [Opn->Fbk]: "\" directive in php.ini, DISABLES ALL non-built-in php extensions
ID: 45994 Updated by: [EMAIL PROTECTED] Reported By: ipseno at yahoo dot com -Status: Open +Status: Feedback Bug Type: PHP options/info functions Operating System: Windows XP SP3 PHP Version: 5.3.0alpha2 Previous Comments: [2008-09-12 13:19:30] ipseno at yahoo dot com Thanks. I'll "play" with it... [2008-09-12 13:00:50] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.3-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.3-win32-installer-latest.msi [2008-09-04 20:46:41] [EMAIL PROTECTED] As mentioned on the internals list, this should cause a syntax error. Much like in PHP code this would not work: [2008-09-04 16:22:54] [EMAIL PROTECTED] We're talking about ini files here, we always had different rules in ini files than regular code! Not sure if this is caused by Jani's improvements in the parsing or by some re2c work, but it should certainly work as before else many Windows users will have this issue! [2008-09-04 14:46:00] ipseno at yahoo dot com Wait, wait... Now I know, why did I posted this question... Now I reverted PHP to version 5.2.6 And there is NO problems with: upload_tmp_dir = "E:\" BUT, when i copy that php.ini file to PHP 5.3 alpha2 THEN upload_tmp_dir = "E:\" causes behavior as explained above. That is a reason why did I cretaed this "bug" report In 5.2.6 "\" doesn't escape, but in 5.3 alpha2 it does! How come?! 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/45994 -- Edit this bug report at http://bugs.php.net/?id=45994&edit=1
#45866 [Opn->Ver]: decimal values fed to DateTime->modify() causes long execution times
ID: 45866
Updated by: [EMAIL PROTECTED]
Reported By: jsnell at e-normous dot com
-Status: Open
+Status: Verified
Bug Type: Date/time related
Operating System: Debian Linux with 2.6.22-2-amd64
PHP Version: 5.3CVS-2008-08-20 (snap)
Previous Comments:
[2008-08-20 03:58:45] jsnell at e-normous dot com
Description:
Feeding a decimal value to DateTime's modify() function can cause very
long execution times because the decimal point is ignored.
Reproduced on the php5.3-200808200230 snapshot.
Reproduce code:
---
$date = new DateTime();
$date->modify("+1.61538461538 day");
Expected result:
A warning or exception, or perhaps 1 day + 0.61538461538*24 hours
added.
Actual result:
--
after 32 seconds of execution, 161538461538 days are added to the date
--
Edit this bug report at http://bugs.php.net/?id=45866&edit=1
#46066 [Opn->Fbk]: Regular Expression differences between 4.4 and 5.2
ID: 46066
Updated by: [EMAIL PROTECTED]
Reported By: ewen dot cumming at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: PCRE related
Operating System: Debian Linux
PHP Version: 5.2CVS-2008-09-12 (snap)
New Comment:
Use var_dump(preg_last_error()) after preg_match_all() to check if any
the problems mentioned in the documentation
(http://docs.php.net/preg-last-error) has occured.
Previous Comments:
[2008-09-12 14:11:33] ewen dot cumming at gmail dot com
Note there should be a space in my reproduce code regex (where the line
break happened to occur):
The below should set it right:
$pattern = "/ ]+)([^>]*)>(.*?)".
"| ]+)([^>]*)>/si";
[2008-09-12 14:05:28] ewen dot cumming at gmail dot com
Description:
In upgrading our code base from PHP4.4 to 5.2 I found the same regular
exression would give different results.
Apologies for the large include string and results, however if I reduce
the input string any more the problem doesn't occur.
I have tested with:
PHP 4.4.4-8+etch6 (cli) (built: May 16 2008 15:59:34)
Zend Engine v1.3.0
PHP 5.2.0-8+etch11 (cli) (built: May 10 2008 10:46:24)
Zend Engine v2.2.0
And before submitting the bug:
PHP 5.2.7-dev (cli) (built: Sep 12 2008 15:05:09)
Zend Engine v2.2.0
Reproduce code:
---
http://www.workingweb.nl/example/input.inc' );
$pattern = "/ ]+)([^>]*)>(.*?)|
]+)([^>]*)>/si";
preg_match_all( $pattern, $string, $matches );
var_dump($matches);
?>
Expected result:
This is what I get in PHP4.4 (and what I would expect after an PHP5.2
upgrade).
array(6) {
[0]=>
array(22) {
[0]=>
string(31) ""
[1]=>
string(15) ""
[2]=>
string(11) ""
[3]=>
string(16) ""
[4]=>
string(12) ""
[5]=>
string(17) ""
[6]=>
string(13) ""
[7]=>
string(17) ""
[8]=>
string(13) ""
[9]=>
string(21) ""
[10]=>
string(18) ""
[11]=>
string(25) ""
[12]=>
string(20) ""
[13]=>
string(15) ""
[14]=>
string(20) ""
[15]=>
string(20) ""
[16]=>
string(13) ""
[17]=>
string(18) ""
[18]=>
string(25) ""
[19]=>
string(21) ""
[20]=>
string(16) ""
[21]=>
string(15) ""
}
[1]=>
array(22) {
[0]=>
string(0) ""
[1]=>
string(0) ""
[2]=>
string(0) ""
[3]=>
string(0) ""
[4]=>
string(0) ""
[5]=>
string(0) ""
[6]=>
string(0) ""
[7]=>
string(0) ""
[8]=>
string(0) ""
[9]=>
string(0) ""
[10]=>
string(0) ""
[11]=>
string(0) ""
[12]=>
string(0) ""
[13]=>
string(0) ""
[14]=>
string(0) ""
[15]=>
string(0) ""
[16]=>
string(0) ""
[17]=>
string(0) ""
[18]=>
string(0) ""
[19]=>
string(0) ""
[20]=>
string(0) ""
[21]=>
string(0) ""
}
[2]=>
array(22) {
[0]=>
string(0) ""
[1]=>
string(0) ""
[2]=>
string(0) ""
[3]=>
string(0) ""
[4]=>
string(0) ""
[5]=>
string(0) ""
[6]=>
string(0) ""
[7]=>
string(0) ""
[8]=>
string(0) ""
[9]=>
string(0) ""
[10]=>
string(0) ""
[11]=>
string(0) ""
[12]=>
string(0) ""
[13]=>
string(0) ""
[14]=>
string(0) ""
[15]=>
string(0) ""
[16]=>
string(0) ""
[17]=>
string(0) ""
[18]=>
string(0) ""
[19]=>
string(0) ""
[20]=>
string(0) ""
[21]=>
string(0) ""
}
[3]=>
array(22) {
[0]=>
string(0) ""
[1]=>
string(0) ""
[2]=>
string(0) ""
[3]=>
string(0) ""
[4]=>
string(0) ""
[5]=>
string(0) ""
[6]=>
string(0) ""
[7]=>
string(0) ""
[8]=>
string(0) ""
[9]=>
string(0) ""
[10]=>
string(0) ""
[11]=>
string(0) ""
[12]=>
string(0) ""
[13]=>
string(0) ""
[14]=>
string(0) ""
[15]=>
string(0) ""
[16]=>
string(0) ""
[17]=>
string(0) ""
[18]=>
string(0) ""
[19]=>
string(0) ""
[20]=>
string(0) ""
[21]=>
string(0) ""
}
[4]=>
array(22) {
[0]=>
string(26) "lang_searchforpublications"
[1]=>
string(10) "lang_title"
[2]=>
string(6) "fTitle"
[3]=>
string(11) "lang_author"
[4]=>
string(7) "fAuthor"
[5]=>
string(12) "lang_session"
[6]=>
string(8) "fSession"
[7]=>
string(12) "lang_summary"
[8]=>
string(8) "butCheck"
[9]=>
string(16) "lang_showsummary"
[10]=>
string(13) "lang_language"
[11]=>
string(20) "languageselectwidget"
[12]=>
string(15) "lang_daterange1"
[13]=>
string(10) "lang_start"
[14]=>
string(15) "startdateWidget"
[15]=>
string(15) "
#45866 [Ver->Asn]: decimal values fed to DateTime->modify() causes long execution times
ID: 45866
Updated by: [EMAIL PROTECTED]
Reported By: jsnell at e-normous dot com
-Status: Verified
+Status: Assigned
Bug Type: Date/time related
Operating System: Debian Linux with 2.6.22-2-amd64
PHP Version: 5.3CVS-2008-08-20 (snap)
-Assigned To:
+Assigned To: derick
Previous Comments:
[2008-08-20 03:58:45] jsnell at e-normous dot com
Description:
Feeding a decimal value to DateTime's modify() function can cause very
long execution times because the decimal point is ignored.
Reproduced on the php5.3-200808200230 snapshot.
Reproduce code:
---
$date = new DateTime();
$date->modify("+1.61538461538 day");
Expected result:
A warning or exception, or perhaps 1 day + 0.61538461538*24 hours
added.
Actual result:
--
after 32 seconds of execution, 161538461538 days are added to the date
--
Edit this bug report at http://bugs.php.net/?id=45866&edit=1
#45083 [Asn->Csd]: XML Constant Notices followed by crash
ID: 45083 Updated by: [EMAIL PROTECTED] Reported By: barry dot byrne at bcs dot org -Status: Assigned +Status: Closed Bug Type: Windows Installer Operating System: XP SP2 PHP Version: 5.2.6 Assigned To: jmertic New Comment: Extension php_domxml.dll no longer included with the package. Previous Comments: [2008-06-19 17:55:15] joseche at gmail dot com I am using 5.2.6.6 without php_domxml.dll and still having the same error. C:\>php -v PHP 5.2.6 (cli) (built: May 2 2008 18:02:07) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies Just doing php -v will crash [2008-05-24 17:32:48] [EMAIL PROTECTED] We may mark it duplicate with some other PECL-zip related issue :) [2008-05-23 23:13:27] [EMAIL PROTECTED] ext/php_domxml.dll is an old extension for php4's DOM support. You should not enable it with php 5+ I assign this bug to the installer maintainer and see if we can simply drop it. [2008-05-23 22:10:05] barry dot byrne at bcs dot org Description: Calling php -v gives about 25 notices like PHP Notice: Constant XML_ELEMENT_NODE already defined in Unknown on line 0 followed by correct version message and then a Windows crash report. I have the Windows report file if you need it. php5ts.dll and ext/php_domxml.dll were installed by the Windows installer Error signature below. Actual result: -- The error signature is AppName: php.exe AppVer: 5.2.6.6 ModName: php5ts.dll ModVer: 5.2.6.6 Offset: 0009c51d -- Edit this bug report at http://bugs.php.net/?id=45083&edit=1
#45338 [Asn->Csd]: Installer generates invalid php.ini
ID: 45338 Updated by: [EMAIL PROTECTED] Reported By: tpeterson at americaschoice dot org -Status: Assigned +Status: Closed Bug Type: Windows Installer Operating System: Windows NT PHP Version: 5.2.6 Assigned To: jmertic New Comment: I am unable to reproduce this with your steps; installing PHP with the mysql extension works correctly for me. My only guess is that somehow another version of the libmysql.dll file was being used somehow by PHP. This will be corrected in 5.3+ since mysqli will no longer depend on that dll. Also, I recommend that you keep the suggested install, and only enable the items you need. Previous Comments: [2008-08-11 15:56:26] abdullah dot a at gmail dot com Copy php.ini from the new installation to C:\WINDOWS and overwrite the php.ini present there. [2008-07-31 19:15:34] tpeterson at americaschoice dot org OK. I found a blank WIndows XP box. Installed Apache and then PHP (your installer). This time I could not get PHP to work. I tried everything. Even the Apache syntax was ok. So I got the PHP.ini file from another machine where the WAMP worked and overwrote the new install's php.ini file. Restarted PHP and PHP worked. I have not had time to set up MySQL. But there is definitely something wrong with the installer for the latest PHP build. Also, I noted that all the exentions were once again uncommented in the php.ini file. No one should/would have all those extensions turned on, at least for security reasons. Also, the problem with the MySQL was because you said you no longer supported it and it had to be uncommented out. So why does the installer install it pre-uncommented? There is something whack about that build. [2008-07-14 13:26:57] tpeterson at americaschoice dot org Thanks, SWilliams, for the comment. I did do that. I checked the path and rechecked it . . . actually I double and triple checked everything. My students also did so many installs/uninstalls/checks that on the evaluation they suggested it be installed for the next class before the class begins (which I will do and just distribute a hand out on how to set up their own environments at home or work). I will in the next few weeks install this on a brand new machine that has never had anything installed on it, including but not limited to PHP, MySQL, and Apache, and see what results I get. [2008-07-12 17:10:20] swilliams at csc dot edu Make sure that you have set your path environment variable to include your php and php extensions directory. I ran into the same problem, and after I adjusted my path variable, I restarted my computer and everything worked fine. Hope this helps. [2008-07-03 19:53:08] tpeterson at americaschoice dot org I searched for all old mysql .dll files as the documentation said and for all .ini files. I deleted any old ones. I restarted--the computer and the server. I did this so many times. I was as thorough with this as possible. Also, during the class that I taught, this was the first install as this was the first PHP class. It wasn't just me and my laptop. I also used a work laptop. It was all the students in that class. Even students who did this at home with your installer, after the class was over, couldn't get it to work. So this is not an old ini issue. The ini that was used was the one that your installer set up. And as I said the ini that your installer installed on the systems had everything uncommented. If MySQL, for instance, is not supported why was everything, including the MySQL extension uncommented upon a base install? First install? Anyway, I already thought of this and verified the ini used was the one that I was edited. I will find yet another clean laptop and install the WAMP stack on it with this installer and see if there is still an issue. 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/45338 -- Edit this bug report at http://bugs.php.net/?id=45338&edit=1
#46060 [Opn]: addEmptyDir() breaks
ID: 46060
User updated by: xl269 at cam dot ac dot uk
Reported By: xl269 at cam dot ac dot uk
Status: Open
Bug Type: PHAR related
Operating System: Debian GNU/Linux lenny
PHP Version: 5.3.0alpha2
New Comment:
the following will create an empty directory "test"
$zip->addFromString("test/", "");
Previous Comments:
[2008-09-12 03:49:50] xl269 at cam dot ac dot uk
whoops, the "* result" sections should read "test.tar" not
"test.tar.bz2" (if it isn't obvious). i was playing around with the bug
whilst editing this report, and overlooked updating that part.
[2008-09-12 03:33:30] xl269 at cam dot ac dot uk
Description:
PharData::addEmptyDir() on a tar archive adds empty files instead of
directories.
Reproduce code:
---
$zip = new PharData('test.tar');
$zip = $zip->convertToData(Phar::TAR, Phar::NONE); // compression
scheme does not affect the result.
// Phar::ZIP is not buggy, but you need to add a file to the empty
directory to see this.
$zip->startBuffering();
$zip->addEmptyDir('test/');
// $zip->addFile('file', 'test/file'); // see (*)
$zip->stopBuffering();
Expected result:
test.tar.bz2 should contain 1 empty directory "test"
Actual result:
--
test.tar.bz2 contains 1 empty *file* "test"
(*) doing this will create the directory "test" automatically, so that
the tar archive now contains both a file and a directory called "test",
and becomes unextractable.
--
Edit this bug report at http://bugs.php.net/?id=46060&edit=1
#46068 [NEW]: Incorrently reported PCRE / PREG regex named pattern
From: sv4php at fmethod dot com
Operating system: Windows, Linux
PHP version: 5.2.6
PHP Bug Type: PCRE related
Bug description: Incorrently reported PCRE / PREG regex named pattern
Description:
Under certain circumstanced, the $matches in a preg_match contain the
wrong name of a named subpattern. Refer to the example below.
Note the conditions:
1. The named patterns have the same numeric index (as they are in a switch
group: (?| .. | .. | .. ) ).
2. The last name alphabetically is always reported, never mind of the
pattern order and the actual pattern matched ('zoo' is last after 'poo',
'hoo' alphabetically in the example below).
Reproduced on Linux and Windows.
Reproduce code:
---
$c = 'yo';
$p = '/(?|(?yo)|(?fo)|(?ho))/';
preg_match ($p, $c, $m);
var_dump($m);
Expected result:
array(3) {
[0]=>
string(2) "yo"
["poo"]=> <-- notice the name
string(2) "yo"
[1]=>
string(2) "yo"
}
Actual result:
--
array(3) {
[0]=>
string(2) "yo"
["zoo"]=> <-- notice the name
string(2) "yo"
[1]=>
string(2) "yo"
}
--
Edit bug report at http://bugs.php.net/?id=46068&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46068&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46068&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46068&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=46068&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=46068&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=46068&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=46068&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=46068&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=46068&r=support
Expected behavior:http://bugs.php.net/fix.php?id=46068&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46068&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46068&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=46068&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46068&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=46068&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=46068&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=46068&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=46068&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=46068&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=46068&r=mysqlcfg
#46068 [Com]: Incorrently reported PCRE / PREG regex named pattern
ID: 46068
Comment by: andrew at linuxjedi dot co dot uk
Reported By: sv4php at fmethod dot com
Status: Open
Bug Type: PCRE related
Operating System: Windows, Linux
PHP Version: 5.2.6
New Comment:
Tried in PHP 5.2.4, also tried the (?Ppattern) method, same
problem.
Previous Comments:
[2008-09-12 19:54:10] sv4php at fmethod dot com
Description:
Under certain circumstanced, the $matches in a preg_match contain the
wrong name of a named subpattern. Refer to the example below.
Note the conditions:
1. The named patterns have the same numeric index (as they are in a
switch group: (?| .. | .. | .. ) ).
2. The last name alphabetically is always reported, never mind of the
pattern order and the actual pattern matched ('zoo' is last after 'poo',
'hoo' alphabetically in the example below).
Reproduced on Linux and Windows.
Reproduce code:
---
$c = 'yo';
$p = '/(?|(?yo)|(?fo)|(?ho))/';
preg_match ($p, $c, $m);
var_dump($m);
Expected result:
array(3) {
[0]=>
string(2) "yo"
["poo"]=> <-- notice the name
string(2) "yo"
[1]=>
string(2) "yo"
}
Actual result:
--
array(3) {
[0]=>
string(2) "yo"
["zoo"]=> <-- notice the name
string(2) "yo"
[1]=>
string(2) "yo"
}
--
Edit this bug report at http://bugs.php.net/?id=46068&edit=1
#46068 [Opn->Bgs]: Incorrently reported PCRE / PREG regex named pattern
ID: 46068
Updated by: [EMAIL PROTECTED]
Reported By: sv4php at fmethod dot com
-Status: Open
+Status: Bogus
Bug Type: PCRE related
Operating System: Windows, Linux
PHP Version: 5.2.6
New Comment:
I can reproduce this with PCRE 7.8, you need to report this upstream to
them.
http://bugs.exim.org/enter_bug.cgi?product=PCRE
Previous Comments:
[2008-09-12 20:01:44] andrew at linuxjedi dot co dot uk
Tried in PHP 5.2.4, also tried the (?Ppattern) method, same
problem.
[2008-09-12 19:54:10] sv4php at fmethod dot com
Description:
Under certain circumstanced, the $matches in a preg_match contain the
wrong name of a named subpattern. Refer to the example below.
Note the conditions:
1. The named patterns have the same numeric index (as they are in a
switch group: (?| .. | .. | .. ) ).
2. The last name alphabetically is always reported, never mind of the
pattern order and the actual pattern matched ('zoo' is last after 'poo',
'hoo' alphabetically in the example below).
Reproduced on Linux and Windows.
Reproduce code:
---
$c = 'yo';
$p = '/(?|(?yo)|(?fo)|(?ho))/';
preg_match ($p, $c, $m);
var_dump($m);
Expected result:
array(3) {
[0]=>
string(2) "yo"
["poo"]=> <-- notice the name
string(2) "yo"
[1]=>
string(2) "yo"
}
Actual result:
--
array(3) {
[0]=>
string(2) "yo"
["zoo"]=> <-- notice the name
string(2) "yo"
[1]=>
string(2) "yo"
}
--
Edit this bug report at http://bugs.php.net/?id=46068&edit=1
#45346 [Com]: object to array cast indexing error
ID: 45346
Comment by: steven at acko dot net
Reported By: xavier dot pinard at laposte dot net
Status: No Feedback
Bug Type: Arrays related
Operating System: WIN XP
PHP Version: 5.2.6
New Comment:
Here is a minimal test case:
{0} = 'foo';
$obj->{'1'} = 'bar';
$obj->{'x'} = 'baz';
$array = (array)$obj;
var_dump($array[0]);
var_dump($array['1']);
var_dump($array['x']);
?>
Expected result:
---
string(3) "foo"
string(3) "bar"
string(3) "baz"
Actual result:
--
NULL
NULL
string(3) "baz"
If you compare var_dump((array)$obj) as defined above with
var_dump(array(0 => 'foo', '1' => 'bar', 'x' => 'baz')), you can see
that the numeric array keys are stored as strings rather than
integers, which causes the array lookups to fail.
(PS: The above developer's response reads like a standard copy/paste
reply that ignores the fact that example code was already supplied. If
the example was insufficient or unclear, at least take 5 seconds to
explain why. The way this bug report is now, it does not help anyone.)
Previous Comments:
[2008-07-19 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2008-07-11 16:01:35] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2008-06-24 10:30:06] xavier dot pinard at laposte dot net
Description:
object numeric's name properties are cast in string array's index.
created indexes becomes not accessible.
Reproduce code:
---
#5.2.7.-DEV on 2007-06-24
# WANTED => cast object to array and access first element with 0 index
#RESULT => the array key with the index '0' is nor accessible by 0 or
"0", uncool ...
#¿PROBLEM? => Shouldn't the array key needs to be numeric instead of a
string after object to array cast ?
$stdclass = neW StdcLaSs() ;
$stdclass->{0} = 'index0' ;
$stdclassElement = (arRaY)$stdclass ;
$var = array_keys( $stdclassElement ) ;
$key = $var [ 0 ] ;
Echo
'$stdclassElement[ $key ] :: ' , $stdclassElement[ $key ] ,
'$stdclassElement[0] :: ' , $stdclassElement[ 0 ] ,
'$stdclassElement["0"] :: ', $stdclassElement['0']
;
Expected result:
acess neither to array index '0' by [0] or ["0"]
Actual result:
--
the index is not accessible
--
Edit this bug report at http://bugs.php.net/?id=45346&edit=1
#39858 [Asn->Csd]: Lost connection to MySQL server during query by a repeated call stored proced
ID: 39858
Updated by: [EMAIL PROTECTED]
Reported By: develar at gmail dot com
-Status: Assigned
+Status: Closed
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5.2.0
Assigned To: wez
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Fixed when using mysqlnd (Windows default, else,
--with-pdo-mysql=mysqlnd)
Previous Comments:
[2008-08-28 09:34:01] sakha5413 at gmail dot com
Fatal error: SQLSTATE[HY000]: General error: 2014 Cannot execute
queries while other unbuffered queries are active. Consider using
PDOStatement::fetchAll(). Alternatively, if your code is only ever going
to run against mysql, you may enable query buffering by setting the
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute. in
C:\xampp\htdocs\tshirtshop\business\database_handler.php on line 102
[2008-07-21 15:06:16] jpmasseria at hotmail dot com
The single line workaround worked for me!
while (mysqli_next_result($conn));
Thank you bepoteat!
This is much better than my previous workaround which was to close and
reopen my database connection before my subsequent stored procedure
call.
John
[2008-07-14 15:31:00] ile at suomi dot finland
This bug occurs with Apache/2.0.63 (Win32) PHP/5.2.6 and MySQL
5.0.51b.
I don't use PDO. I use mysqli calls.
The work-around by bepoteat helps though.
[2008-05-02 16:48:43] bepoteat at yahoo dot com
After looking at the PHP manual, I realized I could reduce the loop to
a single line:
while (mysqli_next_result($conn));
I didn't even have to use mysqli_free_result (but it is good practice).
[2008-05-02 16:24:57] bepoteat at yahoo dot com
I believe paulsidekick is correct. I am working on a page that
repeatedly calls a stored proc that returns a resultset. After using
the expected results from the first call, I tried moving to the next
resultset and displaying the column values. I got nothing. Then I
tried using
mysqli_free_result($rs);
while (mysqli_more_results($conn)) {
mysqli_next_result($conn);
echo count($row);
mysqli_free_result($rs);
}
and got "0". So I decided to just get rid of the empty resultset.
Below is the basic structure of the code that worked for me (note the
while loop).
$conn = mysqli_connect("server", "username", "password");
for ($i=1; $i<$someNumber; $i++) {
$rs = mysqli_query($conn, "CALL spMyProc(param1, param2)");
if ($rs && $row = mysqli_fetch_asoc($rs)) {
//some code to use results
} else {
//error handler
}
mysqli_free_result($rs);
//Add this section to dispose of extra resultset.
while (mysqli_more_results($conn)) {
mysqli_next_result($conn);
mysqli_free_result($rs);
}
}
mysqli_close($conn);
I know this doesn't exactly fix the problem, but it is a workaround
that involves a minimal amount of code.
(By the way, why doesn't the CAPTCHA box show up in Firefox? I had to
use Internet Exploiter to post this. I thought PHP was all about being
open source!)
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/39858
--
Edit this bug report at http://bugs.php.net/?id=39858&edit=1
#42079 [Opn->Csd]: pdo_mysql always links to 3.x libraries (== PDO* in HEAD is out-dated)
ID: 42079 Updated by: [EMAIL PROTECTED] Reported By: mjsabby at gmail dot com -Status: Open +Status: Closed Bug Type: PDO related Operating System: Linux PHP Version: 6CVS-2007-07-23 (CVS) New Comment: PDO_MYSQL in HEAD is the same as PHP_5_3 for a few weeks now Previous Comments: [2007-10-02 21:41:28] [EMAIL PROTECTED] This is not really any bug, just the fact that CVS HEAD (aka PHP 6) has very outdated PDO* sources. It's really linked with whatever libs you have. Hopefully someone gets around to syncing the sources from PHP_5_x branch where they're up-to-date. [2007-07-23 11:30:16] mjsabby at gmail dot com Description: In PHP6 CVS, the PDO driver for MySQL always uses the MySQL 3.x client API version, according to phpinfo() >From what it looks like, phpinfo() is telling the truth here, a connect to the DB failed because of password incompatibility, probably suggesting the client API is 3.x However, I could very well be wrong, and it may just be a phpinfo() output error. I've compiled 5.2.3 with the same config line (plus/minus ICU) and that works as desired. PHP 6 config line: './configure' '--with-apxs2=/usr/local/apache2/bin/apxs' / '--with-mysql=/usr/local/mysql' / '--with-mysqli=/usr/local/mysql/bin/mysql_config' / '--with-pdo-mysql=/usr/local/mysql' --with-icu-dir='/home/mukul/icu' PHP 5.2.3 config line: './configure' '--with-apxs2=/usr/local/apache2/bin/apxs' / '--with-mysql=/usr/local/mysql' / '--with-mysqli=/usr/local/mysql/bin/mysql_config' / '--with-pdo-mysql=/usr/local/mysql' PHP 5.2.3 screen: http://mjsabby.com/pdo523.jpg PHP CVS6 screen: http://mjsabby.com/phpcvs6.jpg Expected result: PHP 6 should (or if it's a phpinfo() error, then display) the correct MySQL client API that the PDO has been enabled with. -- Edit this bug report at http://bugs.php.net/?id=42079&edit=1
#16263 [Com]: session.start() create new empty session file and not resume existing session
ID: 16263 Comment by: robin dot chauhan at gmail dot com Reported By: kur at natur dot cuni dot cz Status: No Feedback Bug Type: Session related Operating System: ANY PHP Version: 4.3.0-dev New Comment: As noted on http://www.kirupa.com/forum/showthread.php?t=288773 "After 10 hours of searching over 2 days, I figured it out. The UTF-8 encoding was placing invisible characters before my johnlonely at gmail dot com 12-Oct-2005 02:32 Everytime I upgrade PHP to a new version, I used to recompile the php.ini file. Everytime I create a website, I always kept the php.ini file so that in the future I would be able to retrieve some Unique properties of the php version I used. So the last php version I've seen where session is sticking is version 4.2. I've been trying for two days with no luck searching the manual and forum, when I tried something : If you guys always fill the session.cookie_path = / to somewhere you the cookies should go, then leave the fuss. You'll save two days! Leave it be! [Session] session.cookie_path = / Happy sticking sessions. [2008-05-20 11:27:30] moi at discardmail dot com I have the same problem on: Windows XP, Apache 1.3 PHP 5.2 But only in IE6. I have set all security setting s in IE6 to lowest and the script still generates new session on every page load. The same script, the same server and FF2 or IE7 work right. Any ideas? [2008-05-14 11:12:52] pmioni at hce dot it I had the same problem with Vista and EasyPHP. $_SESSION has problems when you give it numbers as indexes. So, for example, if you're trying to register the results of a mysql_fetch_row or mysql_fetch_array (which contain numeric indexes) the thing fails, because $_SESSION does not accept the indexes - the file will be empty and nothing is saved in session Try to save the results of mysql_fetch_assoc instead. (Obviously, session permissions , path etc. must be correctly set). The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/16263 -- Edit this bug report at http://bugs.php.net/?id=16263&edit=1
ilmu wang pulang ke pangkuan
ilmu wang pulang ke pangkuan lawatilah laman berikut untuk keterangan lanjut http://ilmupengasih.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "lunch money" group. To post to this group, send email to lunch-money@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/lunch-money -~--~~~~--~~--~--~---
