#50776 [NEW]: openssl_pkcs7_verify
From: gufophp at gmail dot com
Operating system: win32 apache
PHP version: 5.3.1
PHP Bug Type: OpenSSL related
Bug description: openssl_pkcs7_verify
Description:
PKCS7_verify:certificate verify error
Reproduce code:
---
\n";
echo ""; // view 1
$arr = array("To" => "j...@example.com", // keyed syntax
"From: HQ ", // indexed syntax
"Subject" => "Eyes only");
echo openssl_pkcs7_sign($file, $signed, $crt, array($key,
"gufogufogufogufogufogufo"),$arr);
while ($msg = openssl_error_string())
echo $msg . "\n";
echo "";
$body = file_get_contents($signed);
file_put_contents("signed.txt",$body);
$pa = "C:\\Programmi\\Apache Software
Foundation\\Apache2.2\\htdocs\sign\\";
// error here
echo openssl_pkcs7_verify(
$pa."signed.txt",
PKCS7_BINARY,
$pa.'test3.crt',
array($pa.'test.crt'),
$pa.'test.crt',
$pa.'content.eml'
);
// error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error
while ($msg = openssl_error_string())
echo $msg . "\n";
?>
Expected result:
1
Actual result:
--
error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error
--
Edit bug report at http://bugs.php.net/?id=50776&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50776&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50776&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50776&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50776&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50776&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50776&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50776&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50776&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50776&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50776&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50776&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50776&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50776&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50776&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50776&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50776&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50776&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50776&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50776&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50776&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50776&r=mysqlcfg
#50775 [Opn->Fbk]: Array does not serialize properly
ID: 50775
Updated by: ras...@php.net
Reported By: tolkad dot freenode at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Arrays related
Operating System: All
PHP Version: 5.2.12
New Comment:
Can you explain why you think the last var_dump() should show
recursion? Looking at it, I don't see it since you are re-assigning $x
there and you lose the recursive reference in doing so.
Previous Comments:
[2010-01-16 01:27:55] tolkad dot freenode at gmail dot com
Description:
When certain strings are unserialized they do not reserialize properly.
Reproduce code:
---
&array(1) {
[0]=>
&array(1) {
[0]=>
*RECURSION*
}
}
}
a:1:{i:0;a:1:{i:0;R:2;}}
array(1) {
[0]=>
&array(1) {
[0]=>
&array(1) {
[0]=>
*RECURSION*
}
}
}
array(1) {
[0]=>
&array(1) {
[0]=>
&array(1) {
[0]=>
*RECURSION*
}
}
}
a:1:{i:0;R:1;}
array(1) {
[0]=>
&array(1) {
[0]=>
&array(1) {
[0]=>
*RECURSION*
}
}
}
Actual result:
--
array(1) {
[0]=>
&array(1) {
[0]=>
&array(1) {
[0]=>
*RECURSION*
}
}
}
a:1:{i:0;a:1:{i:0;R:2;}}
array(1) {
[0]=>
&array(1) {
[0]=>
&array(1) {
[0]=>
*RECURSION*
}
}
}
array(1) {
[0]=>
array(1) {
[0]=>
array(1) {
[0]=>
*RECURSION*
}
}
}
a:1:{i:0;a:1:{i:0;a:1:{i:0;N;}}}
array(1) {
[0]=>
array(1) {
[0]=>
array(1) {
[0]=>
NULL
}
}
}
--
Edit this bug report at http://bugs.php.net/?id=50775&edit=1
#50775 [NEW]: Array does not serialize properly
From: tolkad dot freenode at gmail dot com
Operating system: All
PHP version: 5.2.12
PHP Bug Type: Arrays related
Bug description: Array does not serialize properly
Description:
When certain strings are unserialized they do not reserialize properly.
Reproduce code:
---
&array(1) {
[0]=>
&array(1) {
[0]=>
*RECURSION*
}
}
}
a:1:{i:0;a:1:{i:0;R:2;}}
array(1) {
[0]=>
&array(1) {
[0]=>
&array(1) {
[0]=>
*RECURSION*
}
}
}
array(1) {
[0]=>
&array(1) {
[0]=>
&array(1) {
[0]=>
*RECURSION*
}
}
}
a:1:{i:0;R:1;}
array(1) {
[0]=>
&array(1) {
[0]=>
&array(1) {
[0]=>
*RECURSION*
}
}
}
Actual result:
--
array(1) {
[0]=>
&array(1) {
[0]=>
&array(1) {
[0]=>
*RECURSION*
}
}
}
a:1:{i:0;a:1:{i:0;R:2;}}
array(1) {
[0]=>
&array(1) {
[0]=>
&array(1) {
[0]=>
*RECURSION*
}
}
}
array(1) {
[0]=>
array(1) {
[0]=>
array(1) {
[0]=>
*RECURSION*
}
}
}
a:1:{i:0;a:1:{i:0;a:1:{i:0;N;}}}
array(1) {
[0]=>
array(1) {
[0]=>
array(1) {
[0]=>
NULL
}
}
}
--
Edit bug report at http://bugs.php.net/?id=50775&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50775&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50775&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50775&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50775&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50775&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50775&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50775&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50775&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50775&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50775&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50775&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50775&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50775&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50775&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50775&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50775&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50775&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50775&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50775&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50775&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50775&r=mysqlcfg
#50774 [Opn]: libphp5.so: symbol sapi_module: referenced symbol not found
ID: 50774 User updated by: ivan at myhz dot com -Reported By: ivanpank at gmail dot com +Reported By: ivan at myhz dot com Status: Open Bug Type: Unknown/Other Function Operating System: solaris 10 PHP Version: 5.3.1 New Comment: there is some similar problems: http://www.google.com/search?hl=en&source=hp&q=libphp5.so%3A+symbol+sapi_module%3A+referenced+symbol+not+found&btnG=Google+Search&aq=f&oq=&aqi= Previous Comments: [2010-01-16 00:35:37] ivan at myhz dot com Description: apache 2.2.14 ./configure --prefix=/usr/local/apache2 --enable-so --enable-modules=all php 5.3.1 ./configure --prefix=/usr/local/php5 --with-config-file-path=/usr/local/apache2/conf --enable-json --enable-mbstring=all --with-iconv --with-zlib --enable-zip --enable-sockets --enable-ftp --disable-ipv6 --enable-static --enable-maintainer-zts --enable-zend-multibyte --enable-inline-optimization --with-xmlrpc --with-libxml-dir=/usr/local/libxml2 --enable-soap --with-curl=/usr/local/curl7 --with-bz2 --enable-sysvmsg --enable-sysvsem --enable-sysvshm --with-mysql=mysqlnd --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd --with-apxs2=/usr/local/apache2/bin/apxs after apache 2.2.14 make intall an php 5.3.1 make install, there is an error: bash-3.00# httpd -k stop httpd: Syntax error on line 53 of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/local/apache2/modules/libphp5.so into server: ld.so.1: httpd: fatal: relocation error: file /usr/local/apache2/modules/libphp5.so: symbol sapi_module: referenced symbol not found -- Edit this bug report at http://bugs.php.net/?id=50774&edit=1
#50774 [NEW]: libphp5.so: symbol sapi_module: referenced symbol not found
From: ivanpank at gmail dot com Operating system: solaris 10 PHP version: 5.3.1 PHP Bug Type: Unknown/Other Function Bug description: libphp5.so: symbol sapi_module: referenced symbol not found Description: apache 2.2.14 ./configure --prefix=/usr/local/apache2 --enable-so --enable-modules=all php 5.3.1 ./configure --prefix=/usr/local/php5 --with-config-file-path=/usr/local/apache2/conf --enable-json --enable-mbstring=all --with-iconv --with-zlib --enable-zip --enable-sockets --enable-ftp --disable-ipv6 --enable-static --enable-maintainer-zts --enable-zend-multibyte --enable-inline-optimization --with-xmlrpc --with-libxml-dir=/usr/local/libxml2 --enable-soap --with-curl=/usr/local/curl7 --with-bz2 --enable-sysvmsg --enable-sysvsem --enable-sysvshm --with-mysql=mysqlnd --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd --with-apxs2=/usr/local/apache2/bin/apxs after apache 2.2.14 make intall an php 5.3.1 make install, there is an error: bash-3.00# httpd -k stop httpd: Syntax error on line 53 of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/local/apache2/modules/libphp5.so into server: ld.so.1: httpd: fatal: relocation error: file /usr/local/apache2/modules/libphp5.so: symbol sapi_module: referenced symbol not found -- Edit bug report at http://bugs.php.net/?id=50774&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50774&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50774&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50774&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50774&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50774&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50774&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50774&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50774&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50774&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50774&r=support Expected behavior: http://bugs.php.net/fix.php?id=50774&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50774&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50774&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50774&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50774&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50774&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50774&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50774&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50774&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50774&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50774&r=mysqlcfg
#50773 [NEW]: Directives in PATH section do not get applied to subdirectories
From: millennium at qme dot nl Operating system: win 32 PHP version: 5.3.1 PHP Bug Type: PHP options/info functions Bug description: Directives in PATH section do not get applied to subdirectories Description: This is a duplicate of bug #48811. But the patch posted in there works for me, And I'll be glad to see it in 5.3.2 -- Edit bug report at http://bugs.php.net/?id=50773&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50773&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50773&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50773&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50773&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50773&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50773&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50773&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50773&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50773&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50773&r=support Expected behavior: http://bugs.php.net/fix.php?id=50773&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50773&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50773&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50773&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50773&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50773&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50773&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50773&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50773&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50773&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50773&r=mysqlcfg
#43578 [Com]: Incurred fault #6 - if returned textfield ist empty
ID: 43578
Comment by: darrick at davismedia dot org
Reported By: schulmat at cms dot hu-berlin dot de
Status: No Feedback
Bug Type: Sybase-ct (ctlib) related
Operating System: Solaris 9/10
PHP Version: 5.2.5
Assigned To: thekid
New Comment:
I get the following after running the test case:
PHP Warning: Module 'pdo_mysql' already loaded in Unknown on line 0
bool(true)
bool(true)
bool(true)
bool(true)
>>> Query: select DC_Rights from #Resource where Resource_ID = 122
<<< Return: resource
array(0) {
}
>>> Query: select DC_Rights from #Resource where Resource_ID = 123
<<< Return: resource
array(1) {
[0]=>
array(1) {
["DC_Rights"]=>
NULL
}
}
>>> Query: select DC_Rights from #Resource where Resource_ID = 124
Segmentation fault: 11 (core dumped)
This is on 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 10:35:36 UTC
2008 r...@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
amd64
But, I also have the same trouble on a ubuntu box.
PHP 5.2.12 with Suhosin-Patch 0.9.7 (cli) (built: Jan 9 2010 14:15:45)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
with eAccelerator v0.9.5.3, Copyright (c) 2004-2006 eAccelerator,
by eAccelerator
tds version = 7.0 and tds_version = 8.0 both fail
Database is MSSQL Server Express Edition version 9.00.1399.06
The following patch fixes the issue but it's a hack. I compiled
php5-sybase_ct with debug enabled and the seg fault occurred at line
1208.
--- php_sybase_ct2.c2010-01-15 14:03:13.0 -0800
+++ php_sybase_ct.c 2010-01-15 14:00:15.0 -0800
@@ -1205,6 +1205,7 @@ static int php_sybase_fetch_result_row (
default: {
/* This indicates anything
else, return it as string */
+ if(result->lengths[j] <
1){result->lengths[j]=1;}
ZVAL_STRINGL(&result->data[i][j], result->tmp_buffer[j],
result->lengths[j]- 1, 1);
break;
}
My guess is ct_bind is returning an indicator of -1 on some systems for
text fields == '' so there is no seg fault. While on systems which seg
fault the indicator from ct_bind is 0 for text fields == ''.
Previous Comments:
[2009-05-05 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".
[2009-04-27 15:57:58] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2008-11-09 10:47:01] the...@php.net
I added a testcase for this bug but am currently not able to reproduce
this issue. See:
http://cvs.php.net/viewvc.cgi/php-src/ext/sybase_ct/tests/bug43578.phpt?revision=1.1.2.1&view=markup&pathrev=PHP_5_3
[2007-12-12 10:28:24] schulmat at cms dot hu-berlin dot de
Description:
The problem can reproduced on Solaris 9 and Solaris 10.
If I compile php with
./configure \
--prefix=/usr/local/wwwbin/php-5.2.5 \
--with-apxs2=/usr/local/wwwbin/apache/bin/apxs \ (Apache 2.2.6)
--with-sybase-ct=/opt/csw (freetds-version 0.64 from blastwave)
and perform this simple query:
select DC_Rights from Resource R where R.Resource_ID = 123;
(DC_Rights type text, Resource_ID = 123 exists, should return "(empty)
not NULL, works via tsql)
i get "Incurred fault #6".
Reproduce code:
---
";
//$db->submitQuery($test); flush();
$query = "select DC_Rights from Resource R where R.Resource_ID = 122";
// expected Result: NULL
flush();
$res_id = $db->submitQuery($query); // works!
$query = "select DC_Rights from Resource R where R.Resource_ID = 123";
// expected Result: ""
flush();
$res_id = $db->submitQuery($query); // doesn't work. Apache:
Segmentation fault (11)
echo "done!";
flush();
exit();
?>
Expected result:
set textsize 262144
select DC_Rights from Resource R where R.Resource_ID = 122
select DC_Rights from Resource R where R.Resource_ID = 123
done!
Actual result:
--
Output:
Warning: sybase_connect() [function.sybase-connect]: Sybase: Server
message: Changed client character set setting to 'iso_1'. (severity 10,
procedure N/A) in /usr/local/htdocs/DBConnection.cls.php on line 7
Warning: sybase_connect() [function.sybase-connect]: Sybase: Server
message: Changed database conte
#49463 [Opn->Csd]: setAttributeNS fails setting default namespace
ID: 49463
Updated by: rricha...@php.net
-Summary:
setAttributeNS("http://www.w3.org/2000/xmlns/","xmlns","blah";)
produces error
Reported By: himajin10 at gmail dot com
-Status: Open
+Status: Closed
Bug Type: DOM XML related
Operating System: Windows XP SP3
PHP Version: 6SVN-2009-09-04 (snap)
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2010-01-15 21:29:57] s...@php.net
Automatic comment from SVN on behalf of rrichards
Revision: http://svn.php.net/viewvc/?view=revision&revision=293597
Log: fix bug #49463 (setAttributeNS fails setting default namespace)
add test
[2009-09-04 01:48:10] himajin10 at gmail dot com
Description:
STEPS TO REPRODUCE:
1.run the "Reproduce Code"
2.read the DOM Core spec from 'if the qualifiedName or its prefix is
"xmlns"'
http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-ElSetAttrNS
Reproduce code:
---
createElementNS('http://purl.org/rss/1.0/','rdf:RDF');
$root->setAttributeNS("http://www.w3.org/2000/xmlns/","xmlns","http://purl.org/rss/1.0/";
);
?>
Expected result:
No Error.
Actual result:
--
Fatal error: Uncaught exception 'DOMException' with message 'Namespace
Error' in
C:\Environment\Users\WWW\OKWave\Q5261193\Q5261193-2.php06:5
Stack trace:
#0 C:\Environment\Users\WWW\OKWave\Q5261193\Q5261193-2.php06(5):
DOMElement->setAttributeNS('http://www.w3.o...', 'xmlns',
'http://purl.org...')
#1 {main}
thrown in
C:\Environment\Users\WWW\OKWave\Q5261193\Q5261193-2.php06 on line 5
--
Edit this bug report at http://bugs.php.net/?id=49463&edit=1
#49976 [Com]: Can't read anything from serial port
ID: 49976
Comment by: stash_85 at hotmail dot com
Reported By: rpiccini at software4u dot it
Status: Open
Bug Type: Feature/Change Request
Operating System: WIN XP / UBUNTU 9.04
PHP Version: 5.2.11
New Comment:
I also have the same problem trying to connect to a gprs modem via
serial port.
I can send commands using fputs but the script hangs while trying to
read from the resource using fgets, fread or stream_get_contents...
I think the problem, at least in my case, is that the response doesn't
have an end or something and the fact that the reading limit doesn't
work in this case.
The strange thing in my case is that back in 2007 i wrote an sms
gateway using a GPRS modem and it used to work with fgets. The same
script today, does not work.
exec('mode com9 baud=9600 data=8 stop=1 parity=n xon=on');
$fd = fopen('COM9', "r+");
if ($fd){
stream_set_timeout($fd, 1);
stream_set_blocking($fd, 0);
fputs($fd, "AT\r");
$response="";
while(!feof($fd)){
$response.=stream_get_contents($fd, 2); // This will not work as it
hangs the script here.
// $response.=fread($fd, 2); // This will not work as it hangs the
script here.
// $response.=fgets($fd, 2); // This will not work as it hangs the
script here.
// $response.=fgets($fd); // This will not work as it hangs the script
here. It used to work back in 2007.
$lines=ereg_replace("\r","",$response);
$lines=explode("\n",$lines);
if (in_array("OK",$lines)) break;
if (in_array("ERROR",$lines)) break;
}
print_r($lines);
fclose($fd);
}
I managed to make it work using the php_dio extension on windows php
5.2.9.
exec('mode com9 baud=9600 data=8 stop=1 parity=n xon=on');
$fd = dio_open('COM9', O_RDWR);
if ($fd){
dio_write($fd, "AT\r");
$response="";
while(1){
$response.=dio_read($fd, 2);
// $response.=dio_read($fd, 5); // This will not work as it hangs the
script here.
$lines=ereg_replace("\r","",$response);
$lines=explode("\n",$lines);
if (in_array("OK",$lines)) break;
if (in_array("ERROR",$lines)) break;
}
print_r($lines);
dio_close($fd);
}
RESULT:
Array ( [0] => AT [1] => OK )
I hope i helped a bit with the above script. But please, someone has to
resolve this bug. Those problems make people underestimate PHP...
--
Christos.
Previous Comments:
[2009-10-26 11:12:12] rpiccini at software4u dot it
Thanks for reply, but binary mode doesn't help to make it works. On WIN
XP and Ubuntu too nothing's changed.
Anyway, I found a difference during fread instruction between WIN and
Ubuntu that I haven't seen before (doesn't matter if binary mode is
activated or not):
[CODE]
$buffer = fread($fp,128);
//$buffer = fgets($fp); // tried also with fgets
[/CODE]
On WIN XP "fread" (and fgets too) hangs (never ending loop), while on
UBUNTU $buffer is always empty (can't read reply from serial port) but
the script doesn't loop on fread and goes (for the rest of my code)
correctly to the end.
It seems like "stream_set_blocking($fp,0)" doesn't work at all on WIN.
By the way, I haven't yet solved my problem...
[2009-10-25 20:23:06] j...@php.net
Oops, and this of course:
$fp = fopen('COM1:','rb+');
[2009-10-25 20:22:36] j...@php.net
How about you open it in binary mode? Like this:
$fp = fopen('/dev/ttyS0','rb+');
Might work bit better on windows..?
[2009-10-25 15:33:32] rpiccini at software4u dot it
First of all sorry for my bad english.
Anyway. Yes, I'm sure that with my code can't read anything back on the
serial port. Can write but can't read replies.
I've already tried with other applications and the serial port has
always worked good as I expected.
As I've already wrote in my firs post I can correclty send the same
commands to the serial port using other programming languages (and also
with a specific built-up application under WIN XP) and I get back the
right reply from the port (ASCII chr(6) in this case) using always the
same hardwar during my tests.
Just for information. I've a dual-boot PC (WIN XP and Ubuntu linux
9.04) so the hardware (PC, serial port, fiscal printer) are exactly the
same for both operating system.
I'm developing a cross-platform application (WIN/Linux) so I MUST find
a way to make the serial port to be read correctly on both o.s.
I don't have much experience with dio/pecl functions...but I wouldn't
like to use them, I'd prefer to have the standard PHP functions
(fgets/fread) working "correctly" (Why can I write correctly with fputs
but can't read with fgets/fread ???).
I've also tried to insert a "sleep" between the fputs and fread
operations just to verify any eventually time-related issue...but it
still doesn't wor
#49904 [Asn]: DateTime::modify('last day') returns last day of the month
ID: 49904
Updated by: der...@php.net
Reported By: kgrecki at gmail dot com
Status: Assigned
Bug Type: Date/time related
Operating System: *
PHP Version: 5.3, 6 (2009-10-19)
Assigned To: derick
New Comment:
Good point, but there is a reason why I made that 'of' bit optional,
I'll have to have a good look at why.
Previous Comments:
[2010-01-15 14:03:31] yoarvi at gmail dot com
The cause of the problem seems to be the optional 'of' in the regex
specification for the relative date operators 'first day of' and 'last
day of'.
After applying the following patch (and regenerating parse_date.c)
$dt->modify('first day'); is handled by the "relativetext" code block
in parse_date.re
and
$dt->modify('first day of'); is handled by the "firstdayof | lastdayof"
code block in parse_date.re
Index: ext/date/lib/parse_date.re
===
--- ext/date/lib/parse_date.re (revision 293574)
+++ ext/date/lib/parse_date.re (working copy)
@@ -931,8 +931,8 @@
isoweekday = year4 "-"? "W" weekofyear "-"? [0-7];
isoweek = year4 "-"? "W" weekofyear;
exif = year4 ":" monthlz ":" daylz " " hour24lz ":"
minutelz ":" secondlz;
-firstdayof = 'first day' ' of'?;
-lastdayof= 'last day' ' of'?;
+firstdayof = 'first day of';
+lastdayof= 'last day of'?;
backof = 'back of ' hour24 space? meridian?;
frontof = 'front of ' hour24 space? meridian?;
[2009-10-19 10:36:37] j...@php.net
Obvious regression.
[2009-10-16 16:45:18] kgrecki at gmail dot com
Description:
call to modify('last day') has different effect in PHP 5.3 than in 5.2
It used to return a previous day, now it seems to return last day of
the month,
according to
http://www.gnu.org/software/automake/manual/tar/General-date-syntax.html#SEC115
"last" means -1 so 5.2 seems to get it right
Reproduce code:
---
date_default_timezone_set('Europe/London');
$dt = new DateTime('today');
var_dump($dt->format('c'));
$dt->modify('last day');
var_dump($dt->format('c'));
$dt = new DateTime('01-04-2009');
var_dump($dt->format('c'));
$dt->modify('last day');
var_dump($dt->format('c'));
Expected result:
PHP 5.2.11 (cli) (built: Sep 18 2009 10:59:00)
string(25) "2009-10-16T00:00:00+01:00"
string(25) "2009-10-15T00:00:00+01:00"
string(25) "2009-04-01T00:00:00+01:00"
string(25) "2009-03-31T00:00:00+01:00"
Actual result:
--
PHP 5.3.0 (cli) (built: Jul 21 2009 17:02:21)
string(25) "2009-10-16T00:00:00+01:00"
string(25) "2009-10-31T00:00:00+00:00"
string(25) "2009-04-01T00:00:00+01:00"
string(25) "2009-04-30T00:00:00+01:00"
--
Edit this bug report at http://bugs.php.net/?id=49904&edit=1
#50772 [NEW]: mysqli constructor without parameters does not return a working mysqli object
From: elmo dot allen at iki dot fi
Operating system: Windows 7
PHP version: 5.3.1
PHP Bug Type: MySQLi related
Bug description: mysqli constructor without parameters does not return a
working mysqli object
Description:
Documentation states that calling mysqli::__construct() without parameters
(i.e. new mysqli()) should do the same as calling mysqli_init(). It does
not, however, return a working mysqli object, but all the following calls
to its methods only return Warning "Couldn't fetch mysqli".
Using mysqli_init() directly works as intended, but using it makes making
derived mysqli classes much harder, if trying to use real_connect(),
because derived classes can only call their parent's constructor, not
mysqli_init().
The following code is by design trying a connection and failing (with
MySQL server not running) and gracefully admitting it with an error message
(warnings not tried to be silenced here).
Not working in PHP 5.2.8 either. No newer snapshots for Windows seem to be
available.
Reproduce code:
---
options(MYSQLI_OPT_CONNECT_TIMEOUT, 3);
$db1->real_connect("localhost");
if(mysqli_connect_error()) echo "error 1";
else echo "ok 1";
// This works
$db2 = mysqli_init();
// And these calls work as intended (give correct error msgs when
connection fails)
$db2->options(MYSQLI_OPT_CONNECT_TIMEOUT, 3);
$db2->real_connect("localhost");
if(mysqli_connect_error()) echo "error 2";
else echo "ok 2";
?>
Expected result:
Warning: mysqli::real_connect() [mysqli.real-connect]: [2002] A
connection attempt failed because the connected party did not (trying to
connect via tcp://localhost:3306) in C:\Users\Elmo\Documents\Web
server\test.php on line 7
Warning: mysqli::real_connect() [mysqli.real-connect]: (HY000/2002): A
connection attempt failed because the connected party did not properly
respond after a period of time, or established connection failed because
connected host has failed to respond.
in C:\Users\Elmo\Documents\Web server\test.php on line 7
error 1
Warning: mysqli::real_connect() [mysqli.real-connect]: [2002] A
connection attempt failed because the connected party did not (trying to
connect via tcp://localhost:3306) in C:\Users\Elmo\Documents\Web
server\test.php on line 13
Warning: mysqli::real_connect() [mysqli.real-connect]: (HY000/2002): A
connection attempt failed because the connected party did not properly
respond after a period of time, or established connection failed because
connected host has failed to respond.
in C:\Users\Elmo\Documents\Web server\test.php on line 13
error 2
Actual result:
--
Warning: mysqli::options() [mysqli.options]: Couldn't fetch mysqli in
C:\Users\Elmo\Documents\Web server\test.php on line 6
Warning: mysqli::real_connect() [mysqli.real-connect]: Couldn't fetch
mysqli in C:\Users\Elmo\Documents\Web server\test.php on line 7
ok 1
Warning: mysqli::real_connect() [mysqli.real-connect]: [2002] A
connection attempt failed because the connected party did not (trying to
connect via tcp://localhost:3306) in C:\Users\Elmo\Documents\Web
server\test.php on line 13
Warning: mysqli::real_connect() [mysqli.real-connect]: (HY000/2002): A
connection attempt failed because the connected party did not properly
respond after a period of time, or established connection failed because
connected host has failed to respond.
in C:\Users\Elmo\Documents\Web server\test.php on line 13
error 2
--
Edit bug report at http://bugs.php.net/?id=50772&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50772&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50772&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50772&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50772&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50772&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50772&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50772&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50772&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50772&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50772&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50772&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50772&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50772&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50772&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50772&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50772&r=dst
IIS Stability:
http://bugs.php.net/
#50771 [Opn->Csd]: ZEND_GCC_VERSION is incorrectly defined
ID: 50771 Updated by: ras...@php.net Reported By: alex dot belonosov at gmail dot com -Status: Open +Status: Closed Bug Type: *Compile Issues Operating System: Linux GCC3.4 PHP Version: 5.3.1 Previous Comments: [2010-01-15 18:27:24] ras...@php.net I don't think we want to change the ZEND_GCC_VERSION macro. We do actually want 3004 for GCC 3.4 and not 3400. The bug is the check for 3400 there. If we switched to 3400 then how do we handle the check for GCC 2.96? That wouldn't work. Right now we check for 2096. I have changed the 3400 to 3004 in zend.h. [2010-01-15 18:26:54] s...@php.net Automatic comment from SVN on behalf of rasmus Revision: http://svn.php.net/viewvc/?view=revision&revision=293590 Log: Fix gcc version check - bug #50771 [2010-01-15 17:53:48] alex dot belonosov at gmail dot com Description: The definition of ZEND_GCC_VERSION is incorrect in zend.h or further checks for version 3400 is incorrect. It's defined as ZEND_GCC_VERSION (__GNUC__ * 1000 + __GNUC_MINOR__) But __GNUC_MINOR__ is usually one digit e.g. __GNUC_MINOR__ is 4 for GCC3.4. This causes problems with php extensions compatibility built with GCC3.4 with another PHP built with GCC4+ The reason is difference in ZEND_FASTCALL definitions under different GCCs. I suppose you guys meant 3004 instead of 3400 in ZEND_GCC_VERSION conditions within zend.h as I think nobody can expect GCC with the minor version number=400 to make the condition for ZEND_FASTCALL true for GCC3. See zend.h:169 and below Or ZEND_GCC_VERSION definition should be changed to ZEND_GCC_VERSION (__GNUC__ * 1000 + __GNUC_MINOR__ * 100) but you will also need to correct other ZEND_GCC_VERSION conditions. Please correct the above in any way as the current code is inconsistent with all GCC3 since v3.4 Thanks -- Edit this bug report at http://bugs.php.net/?id=50771&edit=1
#50771 [Opn]: ZEND_GCC_VERSION is incorrectly defined
ID: 50771 Updated by: ras...@php.net Reported By: alex dot belonosov at gmail dot com Status: Open Bug Type: *Compile Issues Operating System: Linux GCC3.4 PHP Version: 5.3.1 New Comment: I don't think we want to change the ZEND_GCC_VERSION macro. We do actually want 3004 for GCC 3.4 and not 3400. The bug is the check for 3400 there. If we switched to 3400 then how do we handle the check for GCC 2.96? That wouldn't work. Right now we check for 2096. I have changed the 3400 to 3004 in zend.h. Previous Comments: [2010-01-15 18:26:54] s...@php.net Automatic comment from SVN on behalf of rasmus Revision: http://svn.php.net/viewvc/?view=revision&revision=293590 Log: Fix gcc version check - bug #50771 [2010-01-15 17:53:48] alex dot belonosov at gmail dot com Description: The definition of ZEND_GCC_VERSION is incorrect in zend.h or further checks for version 3400 is incorrect. It's defined as ZEND_GCC_VERSION (__GNUC__ * 1000 + __GNUC_MINOR__) But __GNUC_MINOR__ is usually one digit e.g. __GNUC_MINOR__ is 4 for GCC3.4. This causes problems with php extensions compatibility built with GCC3.4 with another PHP built with GCC4+ The reason is difference in ZEND_FASTCALL definitions under different GCCs. I suppose you guys meant 3004 instead of 3400 in ZEND_GCC_VERSION conditions within zend.h as I think nobody can expect GCC with the minor version number=400 to make the condition for ZEND_FASTCALL true for GCC3. See zend.h:169 and below Or ZEND_GCC_VERSION definition should be changed to ZEND_GCC_VERSION (__GNUC__ * 1000 + __GNUC_MINOR__ * 100) but you will also need to correct other ZEND_GCC_VERSION conditions. Please correct the above in any way as the current code is inconsistent with all GCC3 since v3.4 Thanks -- Edit this bug report at http://bugs.php.net/?id=50771&edit=1
#50771 [NEW]: ZEND_GCC_VERSION is incorrectly defined
From: alex dot belonosov at gmail dot com Operating system: Linux GCC3.4 PHP version: 5.3.1 PHP Bug Type: *Compile Issues Bug description: ZEND_GCC_VERSION is incorrectly defined Description: The definition of ZEND_GCC_VERSION is incorrect in zend.h or further checks for version 3400 is incorrect. It's defined as ZEND_GCC_VERSION (__GNUC__ * 1000 + __GNUC_MINOR__) But __GNUC_MINOR__ is usually one digit e.g. __GNUC_MINOR__ is 4 for GCC3.4. This causes problems with php extensions compatibility built with GCC3.4 with another PHP built with GCC4+ The reason is difference in ZEND_FASTCALL definitions under different GCCs. I suppose you guys meant 3004 instead of 3400 in ZEND_GCC_VERSION conditions within zend.h as I think nobody can expect GCC with the minor version number=400 to make the condition for ZEND_FASTCALL true for GCC3. See zend.h:169 and below Or ZEND_GCC_VERSION definition should be changed to ZEND_GCC_VERSION (__GNUC__ * 1000 + __GNUC_MINOR__ * 100) but you will also need to correct other ZEND_GCC_VERSION conditions. Please correct the above in any way as the current code is inconsistent with all GCC3 since v3.4 Thanks -- Edit bug report at http://bugs.php.net/?id=50771&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50771&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50771&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50771&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50771&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50771&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50771&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50771&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50771&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50771&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50771&r=support Expected behavior: http://bugs.php.net/fix.php?id=50771&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50771&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50771&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50771&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50771&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50771&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50771&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50771&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50771&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50771&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50771&r=mysqlcfg
#50749 [Bgs]: max_file_uploads counts empty uploads as well
ID: 50749 Updated by: ras...@php.net Reported By: anzenews at volja dot net Status: Bogus Bug Type: PHP options/info functions Operating System: Linux PHP Version: 5.2.12 New Comment: The server does actually need resources even for an empty upload because we don't necessarily know it is empty until late in the request. We have to create the filename and sit and wait for the data, even if none ever comes. So, from a server resource perspective there is very little difference between an empty upload and a non-empty one. Previous Comments: [2010-01-15 10:15:59] anzenews at volja dot net Then this function is no better than the safe mode, magic quotes and similar fiascos of PHP - useless and will be avoided, at least by me. The purpose of this function is to protect the server from DOS attacks. Does the server need many resources to process the empty files? I would guess not. On the other hand this is very limiting for forms that wish to have many _optional_ file upload input fields (which was how I stumbled across this bug). Anyway, I'll just be careful to choose a host with this "feature" turned off in the future, the same as I did with safe mode. :( Oh, and by the way, turning it on by default in the very first incarnation of this option is not very nice IMHO. It took me quite some time to figure out what is going on since there are almost no pages with this setting described yet. :( [2010-01-15 08:55:11] j...@php.net Of course it does, that's exactly it's purpose: to limit maximum number of uploads. And yes, even "empty" upload is an upload. [2010-01-14 13:46:53] anzenews at volja dot net Description: Setting max_file_uploads limits the number of file input fields on HTML page instead of limiting the number of actually uploaded files. Reproduce code: --- \n". ''."\n"; }; ?> Expected result: When you upload a single file (in the LAST!!! input box) and hit "OK!", you should see the uploaded file. Actual result: -- Instead you see just 20 empty file uploads. (if max_file_uploads is set to 20, as per default) The max_file_uploads setting should never count empty files. -- Edit this bug report at http://bugs.php.net/?id=50749&edit=1
#50763 [Fbk]: appcrash with real_connect at persistant connection
ID: 50763
Updated by: ras...@php.net
Reported By: tidustracker at freenet dot de
Status: Feedback
Bug Type: MySQLi related
Operating System: Windows Vista
PHP Version: 5.3.1
New Comment:
Give localhost an ipv4 address on your system and it should work fine.
Previous Comments:
[2010-01-15 13:40:14] johan...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-01-15 11:51:26] tidustracker at freenet dot de
Description:
mysqli::real_connect() with 'localhost' as host caused an connection
error 2002
mysqli::real_connect() with 'p:localhost' as host caused the same
connection error and ends up in an appcrash. Use of '127.0.0.1' or
'p:127.0.0.1' works fine.
Reproduce code:
---
$objMySQLi = new MySQLi();
$objMySQLi->init();
if(!$objMySQLi->options(MYSQLI_OPT_CONNECT_TIMEOUT, 3))
{
die('Setting MYSQLI_OPT_CONNECT_TIMEOUT failed');
}
$objMySQLi->real_connect('p:localhost',
'root',
'',
'db');
Expected result:
a working (p)connection like on php 5.3.0
Actual result:
--
php.ini:
mysqli.default_host =
php 5.3.0
'p:127.0.0.1' = ok
'127.0.0.1' = ok
'localhost' = ok
'p:localhost' = ok
php 5.3.1
'p:127.0.0.1' = ok
'127.0.0.1' = ok
'localhost' = connection error 2002
Warning: mysqli::real_connect(): (HY000/2002): Ein
Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer
bestimmten Zeitspanne nicht richtig reagiert hat,
oder die hergestellte Verbindung war fehlerhaft, da der
verbundene
Host nicht reagiert hat.
in D:\Webdevelopment\Scripts\test.php on line 68
'p:localhost' = connection error 2002 and appcrash
Fehlerhafte Anwendung php_531.exe, Version 5.3.1.0,
Zeitstempel
0x4b051712, fehlerhaftes Modul php_mysqli.dll, Version 5.3.1.0,
Zeitstempel 0x4b051769, Ausnahmecode 0xc005,
Fehleroffset 0x12a5, Prozess-ID 0x1f68,
Anwendungsstartzeit
01ca95d36ea6609e.
--
Edit this bug report at http://bugs.php.net/?id=50763&edit=1
#50770 [Com]: Incorrect writting date and boolean lengths in header
ID: 50770 Comment by: sergio at entrecables dot com Reported By: sergio at entrecables dot com Status: Open Bug Type:dBase related PHP Version: 5.3.1 New Comment: I'm pasting the patch here because I can't see how to upload files Index: dbf_head.c === --- dbf_head.c (revisi�n: 293584) +++ dbf_head.c (copia de trabajo) @@ -200,9 +200,11 @@ break; case 'D': dbf->db_flen = 8; + put_short(dbfield.dbf_flen, dbf->db_flen); break; case 'L': dbf->db_flen = 1; + put_short(dbfield.dbf_flen, dbf->db_flen); break; default: put_short(dbfield.dbf_flen, dbf->db_flen); Previous Comments: [2010-01-15 16:20:50] sergio at entrecables dot com Description: Rev 246377 (http://svn.php.net:80/viewvc?view=revision&revision=246377) in PECL repository breaks writting dbase header with date or boolean fields, because skip setting dbfield.dbf_flen Adding "put_short(dbfield.dbf_flen, dbf->db_flen);" after setting dbf->db_flen fixes it. -- Edit this bug report at http://bugs.php.net/?id=50770&edit=1
#50770 [NEW]: Incorrect writting date and boolean lengths in header
From: sergio at entrecables dot com Operating system: PHP version: 5.3.1 PHP Bug Type: dBase related Bug description: Incorrect writting date and boolean lengths in header Description: Rev 246377 (http://svn.php.net:80/viewvc?view=revision&revision=246377) in PECL repository breaks writting dbase header with date or boolean fields, because skip setting dbfield.dbf_flen Adding "put_short(dbfield.dbf_flen, dbf->db_flen);" after setting dbf->db_flen fixes it. -- Edit bug report at http://bugs.php.net/?id=50770&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50770&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50770&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50770&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50770&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50770&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50770&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50770&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50770&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50770&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50770&r=support Expected behavior: http://bugs.php.net/fix.php?id=50770&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50770&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50770&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50770&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50770&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50770&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50770&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50770&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50770&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50770&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50770&r=mysqlcfg
#50767 [Fbk->Opn]: XMLReader does not accept zip stream
ID: 50767
User updated by: jhgundersen at gmail dot com
Reported By: jhgundersen at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Streams related
Operating System: Ubuntu 9.10
PHP Version: 5.3.1
New Comment:
Zip stream works with file_get_contents, I can open the test.xml with
zip archive
Previous Comments:
[2010-01-15 14:34:27] johan...@php.net
Are you sure you have the zip extension loaded?
[2010-01-15 14:30:13] jhgundersen at gmail dot com
Description:
XMLReader has stopped working with zip streams.
It easy to reproduce:
Make a zip file named test.zip with a single file named test.xml
Reproduce code:
---
echo file_get_contents('zip://test.zip#test.xml');
$reader = new XMLReader()
$reader->open('zip://test.zip#test.xml');
Expected result:
output of test.xml and no crash from xmlreader
Actual result:
--
output from test.xml is ok, but xmlreader crashes with:
XMLReader::open(): Unable to open source data
--
Edit this bug report at http://bugs.php.net/?id=50767&edit=1
#50768 [NEW]: SoapClient parsing error on complex types
From: alrik dot zachert at erento dot com
Operating system: Ubuntu 9.04
PHP version: 5.3.1
PHP Bug Type: SOAP related
Bug description: SoapClient parsing error on complex types
Description:
the native php soapclient throws a soapfault when passing complex types to
a soap-service on php5.3.1 whereas php5.2.6-soapclient works correctly.
both, 5.3.1 and 5.2.6 ran on same machine with same modules enabled and
almost same config.
the soapserver provides a test method that accepts exactly one parameter
of type TestUser (see below) and returns the modified test object.
I've tested the soapserver with soapUI and checked the wdsl, it 100%ly
valid.
But the client on php5.3.1 troubles. See the actual soap-request (php5.3.1
vs. php5.2.6) below.
I guess it's a parsing error, but i couldn't find any hint in the
releasenotes and changelogs.
You can also reproduce the bug??? by using Zend_Soap_Client, since it uses
the native one.
Reproduce code:
---
array (
'TestUser' => 'TestUser'
)
));
var_dump( $sc->test($objUser) );
?>
intUserId = 123456789;
$objUser->strName = 'somename';
return $objUser;
}
?>
the wsdl: ==>
http://schemas.xmlsoap.org/wsdl/";
xmlns:tns="urn:SoaptestControllerwsdl"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/";
name="SoaptestController"
targetNamespace="urn:SoaptestControllerwsdl">
http://schemas.xmlsoap.org/soap/http"/>
http://schemas.xmlsoap.org/soap/encoding/"/>
http://schemas.xmlsoap.org/soap/encoding/"/>
http://localhost:81/yii/fTest/index.php/soaptest/test/ws/1"/>
Expected result:
the expacted service result:
object(TestUser)#3 (2) {
["intUserId"]=>
int(123456789)
["strName"]=>
string(8) "somename"
}
the expacted client-request :
..
...
Actual result:
--
php5.3.1 =>
Fatal error: Uncaught SoapFault exception: [Client] looks like we got no
XML document in /home/alrik/-:13
Stack trace:
#0 [internal function]: SoapClient->__call('test', Array)
#1 /home/alrik/-(13): SoapClient->test(Object(TestUser))
#2 {main}
thrown in /home/alrik/- on line 13
php5.2.6 service result =>
object(TestUser)#3 (2) {
["intUserId"]=>
int(123456789)
["strName"]=>
string(8) "somename"
}
php5.3.1 client-request :
--
Edit bug report at http://bugs.php.net/?id=50768&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50768&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50768&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50768&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50768&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50768&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50768&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50768&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50768&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50768&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50768&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50768&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50768&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50768&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50768&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50768&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50768&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50768&r=isapi
Install GNU Sed:
#50767 [Opn->Fbk]: XMLReader does not accept zip stream
ID: 50767
Updated by: johan...@php.net
Reported By: jhgundersen at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Streams related
Operating System: Ubuntu 9.10
PHP Version: 5.3.1
New Comment:
Are you sure you have the zip extension loaded?
Previous Comments:
[2010-01-15 14:30:13] jhgundersen at gmail dot com
Description:
XMLReader has stopped working with zip streams.
It easy to reproduce:
Make a zip file named test.zip with a single file named test.xml
Reproduce code:
---
echo file_get_contents('zip://test.zip#test.xml');
$reader = new XMLReader()
$reader->open('zip://test.zip#test.xml');
Expected result:
output of test.xml and no crash from xmlreader
Actual result:
--
output from test.xml is ok, but xmlreader crashes with:
XMLReader::open(): Unable to open source data
--
Edit this bug report at http://bugs.php.net/?id=50767&edit=1
#50767 [NEW]: XMLReader does not accept zip stream
From: jhgundersen at gmail dot com
Operating system: Ubuntu 9.10
PHP version: 5.3.1
PHP Bug Type: Streams related
Bug description: XMLReader does not accept zip stream
Description:
XMLReader has stopped working with zip streams.
It easy to reproduce:
Make a zip file named test.zip with a single file named test.xml
Reproduce code:
---
echo file_get_contents('zip://test.zip#test.xml');
$reader = new XMLReader()
$reader->open('zip://test.zip#test.xml');
Expected result:
output of test.xml and no crash from xmlreader
Actual result:
--
output from test.xml is ok, but xmlreader crashes with:
XMLReader::open(): Unable to open source data
--
Edit bug report at http://bugs.php.net/?id=50767&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50767&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50767&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50767&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50767&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50767&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50767&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50767&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50767&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50767&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50767&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50767&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50767&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50767&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50767&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50767&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50767&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50767&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50767&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50767&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50767&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50767&r=mysqlcfg
#49904 [Com]: DateTime::modify('last day') returns last day of the month
ID: 49904
Comment by: yoarvi at gmail dot com
Reported By: kgrecki at gmail dot com
Status: Assigned
Bug Type: Date/time related
Operating System: *
PHP Version: 5.3, 6 (2009-10-19)
Assigned To: derick
New Comment:
The cause of the problem seems to be the optional 'of' in the regex
specification for the relative date operators 'first day of' and 'last
day of'.
After applying the following patch (and regenerating parse_date.c)
$dt->modify('first day'); is handled by the "relativetext" code block
in parse_date.re
and
$dt->modify('first day of'); is handled by the "firstdayof | lastdayof"
code block in parse_date.re
Index: ext/date/lib/parse_date.re
===
--- ext/date/lib/parse_date.re (revision 293574)
+++ ext/date/lib/parse_date.re (working copy)
@@ -931,8 +931,8 @@
isoweekday = year4 "-"? "W" weekofyear "-"? [0-7];
isoweek = year4 "-"? "W" weekofyear;
exif = year4 ":" monthlz ":" daylz " " hour24lz ":"
minutelz ":" secondlz;
-firstdayof = 'first day' ' of'?;
-lastdayof= 'last day' ' of'?;
+firstdayof = 'first day of';
+lastdayof= 'last day of'?;
backof = 'back of ' hour24 space? meridian?;
frontof = 'front of ' hour24 space? meridian?;
Previous Comments:
[2009-10-19 10:36:37] j...@php.net
Obvious regression.
[2009-10-16 16:45:18] kgrecki at gmail dot com
Description:
call to modify('last day') has different effect in PHP 5.3 than in 5.2
It used to return a previous day, now it seems to return last day of
the month,
according to
http://www.gnu.org/software/automake/manual/tar/General-date-syntax.html#SEC115
"last" means -1 so 5.2 seems to get it right
Reproduce code:
---
date_default_timezone_set('Europe/London');
$dt = new DateTime('today');
var_dump($dt->format('c'));
$dt->modify('last day');
var_dump($dt->format('c'));
$dt = new DateTime('01-04-2009');
var_dump($dt->format('c'));
$dt->modify('last day');
var_dump($dt->format('c'));
Expected result:
PHP 5.2.11 (cli) (built: Sep 18 2009 10:59:00)
string(25) "2009-10-16T00:00:00+01:00"
string(25) "2009-10-15T00:00:00+01:00"
string(25) "2009-04-01T00:00:00+01:00"
string(25) "2009-03-31T00:00:00+01:00"
Actual result:
--
PHP 5.3.0 (cli) (built: Jul 21 2009 17:02:21)
string(25) "2009-10-16T00:00:00+01:00"
string(25) "2009-10-31T00:00:00+00:00"
string(25) "2009-04-01T00:00:00+01:00"
string(25) "2009-04-30T00:00:00+01:00"
--
Edit this bug report at http://bugs.php.net/?id=49904&edit=1
#50763 [Opn->Fbk]: appcrash with real_connect at persistant connection
ID: 50763
Updated by: johan...@php.net
Reported By: tidustracker at freenet dot de
-Status: Open
+Status: Feedback
Bug Type: MySQLi related
Operating System: Windows Vista
PHP Version: 5.3.1
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2010-01-15 11:51:26] tidustracker at freenet dot de
Description:
mysqli::real_connect() with 'localhost' as host caused an connection
error 2002
mysqli::real_connect() with 'p:localhost' as host caused the same
connection error and ends up in an appcrash. Use of '127.0.0.1' or
'p:127.0.0.1' works fine.
Reproduce code:
---
$objMySQLi = new MySQLi();
$objMySQLi->init();
if(!$objMySQLi->options(MYSQLI_OPT_CONNECT_TIMEOUT, 3))
{
die('Setting MYSQLI_OPT_CONNECT_TIMEOUT failed');
}
$objMySQLi->real_connect('p:localhost',
'root',
'',
'db');
Expected result:
a working (p)connection like on php 5.3.0
Actual result:
--
php.ini:
mysqli.default_host =
php 5.3.0
'p:127.0.0.1' = ok
'127.0.0.1' = ok
'localhost' = ok
'p:localhost' = ok
php 5.3.1
'p:127.0.0.1' = ok
'127.0.0.1' = ok
'localhost' = connection error 2002
Warning: mysqli::real_connect(): (HY000/2002): Ein
Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer
bestimmten Zeitspanne nicht richtig reagiert hat,
oder die hergestellte Verbindung war fehlerhaft, da der
verbundene
Host nicht reagiert hat.
in D:\Webdevelopment\Scripts\test.php on line 68
'p:localhost' = connection error 2002 and appcrash
Fehlerhafte Anwendung php_531.exe, Version 5.3.1.0,
Zeitstempel
0x4b051712, fehlerhaftes Modul php_mysqli.dll, Version 5.3.1.0,
Zeitstempel 0x4b051769, Ausnahmecode 0xc005,
Fehleroffset 0x12a5, Prozess-ID 0x1f68,
Anwendungsstartzeit
01ca95d36ea6609e.
--
Edit this bug report at http://bugs.php.net/?id=50763&edit=1
#50766 [Opn->Bgs]: Problems Windows 7 with PDO version PHP 5.3.1
ID: 50766 Updated by: johan...@php.net Reported By: rcastardo at gmail dot com -Status: Open +Status: Bogus Bug Type: PDO related Operating System: Windows 7 PHP Version: 5.3.1 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. . Previous Comments: [2010-01-15 13:01:08] rcastardo at gmail dot com Description: I,m have problems with PDO in Windows Seven, not having support. On phpinfo.php show no value for sources the PDO Thanks. -- Edit this bug report at http://bugs.php.net/?id=50766&edit=1
#50766 [NEW]: Problems Windows 7 with PDO version PHP 5.3.1
From: rcastardo at gmail dot com Operating system: Windows 7 PHP version: 5.3.1 PHP Bug Type: PDO related Bug description: Problems Windows 7 with PDO version PHP 5.3.1 Description: I,m have problems with PDO in Windows Seven, not having support. On phpinfo.php show no value for sources the PDO Thanks. -- Edit bug report at http://bugs.php.net/?id=50766&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50766&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50766&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50766&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50766&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50766&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50766&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50766&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50766&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50766&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50766&r=support Expected behavior: http://bugs.php.net/fix.php?id=50766&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50766&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50766&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50766&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50766&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50766&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50766&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50766&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50766&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50766&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50766&r=mysqlcfg
#50765 [Opn->Asn]: Error message executing php - oci.dll was not found
ID: 50765 Updated by: paj...@php.net Reported By: andreas dot mohr at teraport dot de -Status: Open +Status: Assigned Bug Type: Windows Installer Operating System: Windows Server 2006 64bit PHP Version: 5.3.1 -Assigned To: +Assigned To: pajoye New Comment: Agreed, it should not even be installed by default. Previous Comments: [2010-01-15 12:15:34] andreas dot mohr at teraport dot de As mentioned: my problem is actually solved. Nevertheless i consider this to be a bug during installation. If PDO extension for oracle is installed, the dependancy from oci.dll should be taken care of or informed about during installation. If installation is an update and if pdo for oracle is NOT previously installed, do not install it (disable preset in installation because dependancy raises an error). [2010-01-15 12:12:26] andreas dot mohr at teraport dot de Description: Pre-Installed php 5.2.11 running without error messages. - Initially no oracle extensions were installed After Updating to 5.3.1, running any php command in command window produces the error message "The application has failed to start because oci.dll was not found. Re-Installing the application might solve the "... Reinstalled using php-5.3.1-nts-Win32-VC9-x86.msi... ...with Oracle 10 extension. Did not fix the issue... Result: error now occurs twice when running the php version check Reinstalled once more... ...with 11g Extension. Did not fix the issue... Result: error occurs three times - disabled all extensions containing "oci" in php.ini. Found additional extension extension=php_pdo_oci.dll In previous versions, when PDO extensions are installed no dependancy issues occured when the database (or client) behind the extension was not installed. The necessity to install an oracle client with PHP 5.3.1 is not well documented. So the problem is actually solved. If PDO extension for oracle is installed, the dependancy from oci.dll should be taken care of or informed about during installation. If installation is an update and if pdo for oracle is NOT previously installed, do not install it. Reproduce code: --- In php.ini of a running PHP 5.2.11, only have pdo extensions for mysql installed. Update an installed PHP 5.2.11 to 5.3.1 (with or without oracle extensions) using the windows installer and run c:\your-path-to-php\php-cgi.exe -v in the command prompt. Note: pdo extension is installed (because pdo was previously installed?). Unfolding the tree reveals that the feature is fully installed, including PDO for Oracle 10g client and above. There is no awareness of this. Expected result: Execute php after Update without an error message. Actual result: -- The version info is correctly displayed - following an error message. "The application has failed to start because oci.dll was not found. Re-installing the application might solve the problem." -- Edit this bug report at http://bugs.php.net/?id=50765&edit=1
#50762 [Opn->Asn]: in WSDL mode Soap Header handler function only being called if defined in WSDL
ID: 50762
Updated by: tony2...@php.net
Reported By: mephius at gmail dot com
-Status: Open
+Status: Assigned
Bug Type: SOAP related
Operating System: Any
PHP Version: 5.2.12
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2010-01-15 10:36:52] mephius at gmail dot com
May be linked to bug #49530
[2010-01-15 10:33:22] mephius at gmail dot com
Description:
While in WSDL mode, SoapServer looks for soap header handler function
in the WSDL only. Why one should expose his internal handling methods to
WSDL?
Suggested simple patch eliminates necessity to describe handle function
in WSDL. (but it just fixes symptoms, therefore should be revised)
--- soap.c 2009-11-21 21:43:00.0 +0200
+++ soap.c.patched 2010-01-15 12:06:55.0 +0200
@@ -1705,14 +1705,14 @@
soapHeader *h = header;
header = header->next;
- if (service->sdl && !h->function && !h->hdr) {
+/* if (service->sdl && !h->function && !h->hdr) {
if (h->mustUnderstand) {
soap_server_fault("MustUnderstand","Header not understood", NULL, NULL,
NULL TSRMLS_CC);
} else {
continue;
}
}
-
+*/
fn_name =
estrndup(Z_STRVAL(h->function_name),Z_STRLEN(h->function_name));
if (zend_hash_exists(function_table,
php_strtolower(fn_name, Z_STRLEN(h->function_name)),
Z_STRLEN(h->function_name) + 1) ||
((service->type == SOAP_CLASS ||
service->type == SOAP_OBJECT) &&
Reproduce code:
---
WSDL: http://pastebin.com/f7cd32e16
You'll need to adjust soap endpoint to be able to run the code.
=== Server Code ===
auth=true;
}
public function testHeader($param){
return 'header handler ' . ($this->auth ? 'called' : 'not
called');
}
}
$server = new SoapServer('bug.wsdl',
array('cache_wsdl'=>WSDL_CACHE_NONE));
$server->setObject(new testSoap());
$server->handle();
?>
=== Client Code ===
WSDL_CACHE_NONE, 'trace'=>true));
class authToken{
public function __construct($token){
$this->authToken=$token;
}
}
$cl->__setSoapHeaders(array(new SoapHeader('http://sova.pronto.ru/',
'authToken', new authToken('tokendata';
echo $cl->testHeader('param') . PHP_EOL;
?>
Expected result:
client code should echo "header handler called"
Actual result:
--
client code should echoes "header handler not called"
--
Edit this bug report at http://bugs.php.net/?id=50762&edit=1
#50765 [Com]: Error message executing php - oci.dll was not found
ID: 50765 Comment by: andreas dot mohr at teraport dot de Reported By: andreas dot mohr at teraport dot de Status: Open Bug Type: Windows Installer Operating System: Windows Server 2006 64bit PHP Version: 5.3.1 New Comment: As mentioned: my problem is actually solved. Nevertheless i consider this to be a bug during installation. If PDO extension for oracle is installed, the dependancy from oci.dll should be taken care of or informed about during installation. If installation is an update and if pdo for oracle is NOT previously installed, do not install it (disable preset in installation because dependancy raises an error). Previous Comments: [2010-01-15 12:12:26] andreas dot mohr at teraport dot de Description: Pre-Installed php 5.2.11 running without error messages. - Initially no oracle extensions were installed After Updating to 5.3.1, running any php command in command window produces the error message "The application has failed to start because oci.dll was not found. Re-Installing the application might solve the "... Reinstalled using php-5.3.1-nts-Win32-VC9-x86.msi... ...with Oracle 10 extension. Did not fix the issue... Result: error now occurs twice when running the php version check Reinstalled once more... ...with 11g Extension. Did not fix the issue... Result: error occurs three times - disabled all extensions containing "oci" in php.ini. Found additional extension extension=php_pdo_oci.dll In previous versions, when PDO extensions are installed no dependancy issues occured when the database (or client) behind the extension was not installed. The necessity to install an oracle client with PHP 5.3.1 is not well documented. So the problem is actually solved. If PDO extension for oracle is installed, the dependancy from oci.dll should be taken care of or informed about during installation. If installation is an update and if pdo for oracle is NOT previously installed, do not install it. Reproduce code: --- In php.ini of a running PHP 5.2.11, only have pdo extensions for mysql installed. Update an installed PHP 5.2.11 to 5.3.1 (with or without oracle extensions) using the windows installer and run c:\your-path-to-php\php-cgi.exe -v in the command prompt. Note: pdo extension is installed (because pdo was previously installed?). Unfolding the tree reveals that the feature is fully installed, including PDO for Oracle 10g client and above. There is no awareness of this. Expected result: Execute php after Update without an error message. Actual result: -- The version info is correctly displayed - following an error message. "The application has failed to start because oci.dll was not found. Re-installing the application might solve the problem." -- Edit this bug report at http://bugs.php.net/?id=50765&edit=1
#50765 [NEW]: Error message executing php - oci.dll was not found
From: andreas dot mohr at teraport dot de Operating system: Windows Server 2006 64bit PHP version: 5.3.1 PHP Bug Type: Windows Installer Bug description: Error message executing php - oci.dll was not found Description: Pre-Installed php 5.2.11 running without error messages. - Initially no oracle extensions were installed After Updating to 5.3.1, running any php command in command window produces the error message "The application has failed to start because oci.dll was not found. Re-Installing the application might solve the "... Reinstalled using php-5.3.1-nts-Win32-VC9-x86.msi... ...with Oracle 10 extension. Did not fix the issue... Result: error now occurs twice when running the php version check Reinstalled once more... ...with 11g Extension. Did not fix the issue... Result: error occurs three times - disabled all extensions containing "oci" in php.ini. Found additional extension extension=php_pdo_oci.dll In previous versions, when PDO extensions are installed no dependancy issues occured when the database (or client) behind the extension was not installed. The necessity to install an oracle client with PHP 5.3.1 is not well documented. So the problem is actually solved. If PDO extension for oracle is installed, the dependancy from oci.dll should be taken care of or informed about during installation. If installation is an update and if pdo for oracle is NOT previously installed, do not install it. Reproduce code: --- In php.ini of a running PHP 5.2.11, only have pdo extensions for mysql installed. Update an installed PHP 5.2.11 to 5.3.1 (with or without oracle extensions) using the windows installer and run c:\your-path-to-php\php-cgi.exe -v in the command prompt. Note: pdo extension is installed (because pdo was previously installed?). Unfolding the tree reveals that the feature is fully installed, including PDO for Oracle 10g client and above. There is no awareness of this. Expected result: Execute php after Update without an error message. Actual result: -- The version info is correctly displayed - following an error message. "The application has failed to start because oci.dll was not found. Re-installing the application might solve the problem." -- Edit bug report at http://bugs.php.net/?id=50765&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50765&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50765&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50765&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50765&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50765&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50765&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50765&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50765&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50765&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50765&r=support Expected behavior: http://bugs.php.net/fix.php?id=50765&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50765&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50765&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50765&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50765&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50765&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50765&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50765&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50765&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50765&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50765&r=mysqlcfg
#50675 [Fbk->Opn]: SoapClient can't handle object references correctly.
ID: 50675 User updated by: margaritisz dot oresztesz at dotroll dot hu Reported By: margaritisz dot oresztesz at dotroll dot hu -Status: Feedback +Status: Open Bug Type: SOAP related Operating System: Linux PHP Version: 5.2.12 New Comment: Package on the previous link is damaged. Source code can be found at: http://code.dotroll.com/files/bugreports/php-50675-soaprefs/soap.tar.gz Previous Comments: [2010-01-13 13:53:38] srina...@php.net the client.php that you attached is tar.gz of the same server side code. pl.attach / provide appropriate client reproduce code [2010-01-06 08:46:33] margaritisz dot oresztesz at dotroll dot hu Description: When sending the same object multiple times in a SOAP call, SoapClient replaces the object with a href='..' object reference. However the client generates the request envelope with an incorrect parameter name, so the server does not get the referenced object. Reproduce code: --- Sources of a simple server and client could be found at the following URL: http://charlie.extra.hu/php-soap/soap.tar.gz If I run client.php, it gets back an object filled with null parameters. It should recieve the first object sent to the server. If I change the reference's parameter name to 'secondUser', the SOAP response includes the correct object. Expected result: Expected the following soap envelope to be sent: 1 user Actual result: -- Got this request: 1 user -- Edit this bug report at http://bugs.php.net/?id=50675&edit=1
#50763 [NEW]: appcrash with real_connect at persistant connection
From: tidustracker at freenet dot de
Operating system: Windows Vista
PHP version: 5.3.1
PHP Bug Type: MySQLi related
Bug description: appcrash with real_connect at persistant connection
Description:
mysqli::real_connect() with 'localhost' as host caused an connection error
2002
mysqli::real_connect() with 'p:localhost' as host caused the same
connection error and ends up in an appcrash. Use of '127.0.0.1' or
'p:127.0.0.1' works fine.
Reproduce code:
---
$objMySQLi = new MySQLi();
$objMySQLi->init();
if(!$objMySQLi->options(MYSQLI_OPT_CONNECT_TIMEOUT, 3))
{
die('Setting MYSQLI_OPT_CONNECT_TIMEOUT failed');
}
$objMySQLi->real_connect('p:localhost',
'root',
'',
'db');
Expected result:
a working (p)connection like on php 5.3.0
Actual result:
--
php.ini:
mysqli.default_host =
php 5.3.0
'p:127.0.0.1' = ok
'127.0.0.1' = ok
'localhost' = ok
'p:localhost' = ok
php 5.3.1
'p:127.0.0.1' = ok
'127.0.0.1' = ok
'localhost' = connection error 2002
Warning: mysqli::real_connect(): (HY000/2002): Ein
Verbindungsversuch
ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne
nicht richtig reagiert hat,
oder die hergestellte Verbindung war fehlerhaft, da der
verbundene Host
nicht reagiert hat.
in D:\Webdevelopment\Scripts\test.php on line 68
'p:localhost' = connection error 2002 and appcrash
Fehlerhafte Anwendung php_531.exe, Version 5.3.1.0,
Zeitstempel
0x4b051712, fehlerhaftes Modul php_mysqli.dll, Version 5.3.1.0, Zeitstempel
0x4b051769, Ausnahmecode 0xc005,
Fehleroffset 0x12a5, Prozess-ID 0x1f68,
Anwendungsstartzeit
01ca95d36ea6609e.
--
Edit bug report at http://bugs.php.net/?id=50763&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50763&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50763&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50763&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50763&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50763&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50763&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50763&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50763&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50763&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50763&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50763&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50763&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50763&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50763&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50763&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50763&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50763&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50763&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50763&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50763&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50763&r=mysqlcfg
#50737 [Bgs]: stream_set_blocking creates high cpu usage
ID: 50737 User updated by: jason at lentink dot net Reported By: jason at lentink dot net Status: Bogus Bug Type: Streams related Operating System: Linux PHP Version: 5.2.12 New Comment: Then we go back to the first post and there is a 2 line example of the problem. Reproduce code: --- http://www.grasvezel.nl/media/software/cpuload.txt Here is a complete undressed file which only has the problem. [2010-01-14 12:17:19] j...@php.net I asked for small, complete script NOT for a framework. [2010-01-14 12:13:36] jason at lentink dot net I could provide you guys with a small script bug i can also point you to the place where the problem exists since it happens in Zend Framework. http://framework.zend.com/svn/framework/standard/trunk/library/Zend/Queu e/Stomp/Client/Connection.php The function is used at line 79. What i see on my servers is that when there are simultaneous request made to the same script the problem increases more rapidly. [2010-01-13 12:07:10] j...@php.net 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. 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/50737 -- Edit this bug report at http://bugs.php.net/?id=50737&edit=1
#50762 [Com]: in WSDL mode Soap Header handler function only being called if defined in WSDL
ID: 50762
Comment by: mephius at gmail dot com
Reported By: mephius at gmail dot com
Status: Open
Bug Type: SOAP related
Operating System: Any
PHP Version: 5.2.12
New Comment:
May be linked to bug #49530
Previous Comments:
[2010-01-15 10:33:22] mephius at gmail dot com
Description:
While in WSDL mode, SoapServer looks for soap header handler function
in the WSDL only. Why one should expose his internal handling methods to
WSDL?
Suggested simple patch eliminates necessity to describe handle function
in WSDL. (but it just fixes symptoms, therefore should be revised)
--- soap.c 2009-11-21 21:43:00.0 +0200
+++ soap.c.patched 2010-01-15 12:06:55.0 +0200
@@ -1705,14 +1705,14 @@
soapHeader *h = header;
header = header->next;
- if (service->sdl && !h->function && !h->hdr) {
+/* if (service->sdl && !h->function && !h->hdr) {
if (h->mustUnderstand) {
soap_server_fault("MustUnderstand","Header not understood", NULL, NULL,
NULL TSRMLS_CC);
} else {
continue;
}
}
-
+*/
fn_name =
estrndup(Z_STRVAL(h->function_name),Z_STRLEN(h->function_name));
if (zend_hash_exists(function_table,
php_strtolower(fn_name, Z_STRLEN(h->function_name)),
Z_STRLEN(h->function_name) + 1) ||
((service->type == SOAP_CLASS ||
service->type == SOAP_OBJECT) &&
Reproduce code:
---
WSDL: http://pastebin.com/f7cd32e16
You'll need to adjust soap endpoint to be able to run the code.
=== Server Code ===
auth=true;
}
public function testHeader($param){
return 'header handler ' . ($this->auth ? 'called' : 'not
called');
}
}
$server = new SoapServer('bug.wsdl',
array('cache_wsdl'=>WSDL_CACHE_NONE));
$server->setObject(new testSoap());
$server->handle();
?>
=== Client Code ===
WSDL_CACHE_NONE, 'trace'=>true));
class authToken{
public function __construct($token){
$this->authToken=$token;
}
}
$cl->__setSoapHeaders(array(new SoapHeader('http://sova.pronto.ru/',
'authToken', new authToken('tokendata';
echo $cl->testHeader('param') . PHP_EOL;
?>
Expected result:
client code should echo "header handler called"
Actual result:
--
client code should echoes "header handler not called"
--
Edit this bug report at http://bugs.php.net/?id=50762&edit=1
#50762 [NEW]: in WSDL mode Soap Header handler function only being called if defined in WSDL
From: mephius at gmail dot com
Operating system: Any
PHP version: 5.2.12
PHP Bug Type: SOAP related
Bug description: in WSDL mode Soap Header handler function only being called
if defined in WSDL
Description:
While in WSDL mode, SoapServer looks for soap header handler function in
the WSDL only. Why one should expose his internal handling methods to
WSDL?
Suggested simple patch eliminates necessity to describe handle function in
WSDL. (but it just fixes symptoms, therefore should be revised)
--- soap.c 2009-11-21 21:43:00.0 +0200
+++ soap.c.patched 2010-01-15 12:06:55.0 +0200
@@ -1705,14 +1705,14 @@
soapHeader *h = header;
header = header->next;
- if (service->sdl && !h->function && !h->hdr) {
+/* if (service->sdl && !h->function && !h->hdr) {
if (h->mustUnderstand) {
soap_server_fault("MustUnderstand","Header not understood", NULL, NULL,
NULL TSRMLS_CC);
} else {
continue;
}
}
-
+*/
fn_name =
estrndup(Z_STRVAL(h->function_name),Z_STRLEN(h->function_name));
if (zend_hash_exists(function_table,
php_strtolower(fn_name, Z_STRLEN(h->function_name)),
Z_STRLEN(h->function_name) + 1) ||
((service->type == SOAP_CLASS || service->type
== SOAP_OBJECT) &&
Reproduce code:
---
WSDL: http://pastebin.com/f7cd32e16
You'll need to adjust soap endpoint to be able to run the code.
=== Server Code ===
auth=true;
}
public function testHeader($param){
return 'header handler ' . ($this->auth ? 'called' : 'not
called');
}
}
$server = new SoapServer('bug.wsdl',
array('cache_wsdl'=>WSDL_CACHE_NONE));
$server->setObject(new testSoap());
$server->handle();
?>
=== Client Code ===
WSDL_CACHE_NONE, 'trace'=>true));
class authToken{
public function __construct($token){
$this->authToken=$token;
}
}
$cl->__setSoapHeaders(array(new SoapHeader('http://sova.pronto.ru/',
'authToken', new authToken('tokendata';
echo $cl->testHeader('param') . PHP_EOL;
?>
Expected result:
client code should echo "header handler called"
Actual result:
--
client code should echoes "header handler not called"
--
Edit bug report at http://bugs.php.net/?id=50762&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50762&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50762&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50762&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50762&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50762&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50762&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50762&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50762&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50762&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50762&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50762&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50762&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50762&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50762&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50762&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50762&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50762&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50762&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50762&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50762&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50762&r=mysqlcfg
#50754 [Bgs]: var_export emits erroneous outputs on vars that contain recursive references
ID: 50754 User updated by: andrew at trib dot tv Reported By: andrew at trib dot tv Status: Bogus Bug Type: Output Control -Operating System: Fed +Operating System: Fedora PHP Version: 5.3.1 New Comment: Incidentally, I'm aware that removing the @ reveals a fatal error - in fact I said so in my OP. For the sake of absolute clarity, this is what you get without the @ (and with display_errors enabled): PrivateThing::__set_state(array( 'publicvar' => 'notsecret', 'password' => 'supersecret', 'reftoself' => PrivateThing::__set_state(array( 'publicvar' => 'notsecret', 'password' => 'supersecret', 'reftoself' => PrivateThing::__set_state(array( 'publicvar' => 'notsecret', 'password' => 'supersecret', 'reftoself' => PrivateThing::__set_state(array( Fatal error: Nesting level too deep - recursive dependency? in /root/test.php on line 9 So you still get the spurious output, prior to the fatal error. I'm not objecting to a recursive input triggering an error, but it should ideally not be fatal, and most importantly it surely shouldn't cause a half-complete serialisation to be sent to the browser when you don't expect this function to produce any output at all. Previous Comments: [2010-01-15 08:29:09] andrew at trib dot tv Derek, Thank you for taking the time to select a canned response, though it would be much more encouraging to bug reporters if you actually responded to the points made (at length and in the correct manner) in the bug report before dismissing it as bogus. Could you comment on why this is not a security vulnerability? The security implications were initally raised *eight years ago* in bug 17874 by icecube at fr dot fm, but there has been no followup, hence my fresh bug report. If serialize($GLOBALS) manages to finish without crashing PHP and sending a half-complete invalid and potentially sensitive serialisation string to the browser / console, I don't understand why var_export can't do the same, nor what the justification is for claiming that the current behaviour is desirable. Cheers, Andrew [2010-01-14 22:00:57] der...@php.net 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 Remove the @ and you see what really happens: Fatal error: Nesting level too deep - recursive dependency? in - on line 9 [2010-01-14 16:52:57] andrew at trib dot tv Description: My case is one in which var_export is being used to expose private members of classes present in the context of an error. So an error occurs, a custom handler is invoked, and it var_exports any variables in the error context which are objects, so that developers investigating the problem can see the values of private vars within these objects at the time the error occured. However, doing this: $str = var_export($object, true); If $object contains recursive references, var_export not only fails with a fatal error that cannot be handled or suppressed, but also flushes its internal output buffer, so if you've set the second argument to true, wanting the output returned rather than sent to the browser, you're out of luck, because it's gone. This is a security issue, because in some situations, a developer may have implemented var_export on objects with passwords stored within, and expects to get the object returned in a string. If the entire content of the object (up to the recursive reference) is instead output to the browser, this data is inadvertently exposed. I'd say that in such situations var_export should trigger an E_WARNING and return null or false. Then it can be safely used on objects that do not contain recursive references without having to know whether they do or not before you call the function. I'm aware of previous bugs filed on this issue, notably 17874 and 16074, so I raise this specifically in relation to te security implications, and also making the point that it is not possible to detect whether an object contains *private* recursive references before you take your life in your hands by throwing it at var_export and crossing your fingers! Cheers, Andrew Reproduce code: --- reftoself = $this; } } $x = new PrivateThing; $y = @var_export($x, true); echo "No passwords here!"; ?> Expected result: No passwords here! Actual result: -- PrivateThing::__set_state(array( 'publicvar' => 'notsecret', 'password' => 'supersecret', 'reftoself' => PrivateThing::__set_state(array( 'publicvar' => 'notsecret', 'password' => 'supersecret',
#50749 [Bgs]: max_file_uploads counts empty uploads as well
ID: 50749 User updated by: anzenews at volja dot net Reported By: anzenews at volja dot net Status: Bogus Bug Type: PHP options/info functions Operating System: Linux PHP Version: 5.2.12 New Comment: Then this function is no better than the safe mode, magic quotes and similar fiascos of PHP - useless and will be avoided, at least by me. The purpose of this function is to protect the server from DOS attacks. Does the server need many resources to process the empty files? I would guess not. On the other hand this is very limiting for forms that wish to have many _optional_ file upload input fields (which was how I stumbled across this bug). Anyway, I'll just be careful to choose a host with this "feature" turned off in the future, the same as I did with safe mode. :( Oh, and by the way, turning it on by default in the very first incarnation of this option is not very nice IMHO. It took me quite some time to figure out what is going on since there are almost no pages with this setting described yet. :( Previous Comments: [2010-01-15 08:55:11] j...@php.net Of course it does, that's exactly it's purpose: to limit maximum number of uploads. And yes, even "empty" upload is an upload. [2010-01-14 13:46:53] anzenews at volja dot net Description: Setting max_file_uploads limits the number of file input fields on HTML page instead of limiting the number of actually uploaded files. Reproduce code: --- \n". ''."\n"; }; ?> Expected result: When you upload a single file (in the LAST!!! input box) and hit "OK!", you should see the uploaded file. Actual result: -- Instead you see just 20 empty file uploads. (if max_file_uploads is set to 20, as per default) The max_file_uploads setting should never count empty files. -- Edit this bug report at http://bugs.php.net/?id=50749&edit=1
#50761 [Com]: system.multiCall crashes
ID: 50761
Comment by: hiroaki dot kawai at gmail dot com
Reported By: hiroaki dot kawai at gmail dot com
Status: Verified
Bug Type: XMLRPC-EPI related
Operating System: *
PHP Version: 5.*, 6
New Comment:
Created a patch files.
PHP_5_2 http://mp.i-revo.jp/user.php/kcvcrlkq/attach/188
PHP_5_3 http://mp.i-revo.jp/user.php/kcvcrlkq/attach/189
trunk http://mp.i-revo.jp/user.php/kcvcrlkq/attach/190
Previous Comments:
[2010-01-15 08:52:45] j...@php.net
I hope that patch is against latest SVN checkout of PHP_5_3 and
propably applies also to trunk and PHP_5_2 ? Could you please put the
patch somewhere to be downloaded from.
[2010-01-15 07:03:28] hiroaki dot kawai at gmail dot com
Description:
xmlrpc-epi supports system.multiCall(), which packs multiple xmlrpc
method call transactions into one. Using this method in php extension
cause php process crash.
The point was that we must let xmlrpc-epi to decode the multicall
request. We must check the method name in the callback function.
This bug exists very long time. http://bugs.php.net/bug.php?id=27446
patch is available:
-
--- xmlrpc-epi-php.c.orig 2009-08-18 09:41:43.0 +0900
+++ xmlrpc-epi-php.c2010-01-14 13:58:48.028867000 +0900
@@ -892,12 +892,23 @@
static XMLRPC_VALUE php_xmlrpc_callback(XMLRPC_SERVER server,
XMLRPC_REQUEST xRequest, void* data) /* {{{ */
{
xmlrpc_callback_data* pData = (xmlrpc_callback_data*)data;
+ zval** php_function;
zval* xmlrpc_params;
zval* callback_params[3];
TSRMLS_FETCH();
/* convert xmlrpc to native php types */
+ ZVAL_STRING(pData->xmlrpc_method,
XMLRPC_RequestGetMethodName(xRequest), 1);
xmlrpc_params =
XMLRPC_to_PHP(XMLRPC_RequestGetData(xRequest));
+
+ /* check if the called method has been previous registered */
+ if(zend_hash_find(Z_ARRVAL_P(pData->server->method_map),
+ Z_STRVAL_P(pData->xmlrpc_method),
+ Z_STRLEN_P(pData->xmlrpc_method) + 1,
+ (void**)&php_function) == SUCCESS) {
+
+ pData->php_function = *php_function;
+ }
/* setup data hoojum */
callback_params[0] = pData->xmlrpc_method;
@@ -913,7 +924,7 @@
zval_ptr_dtor(&xmlrpc_params);
- return NULL;
+ return PHP_to_XMLRPC(pData->return_data TSRMLS_CC);
}
/* }}} */
@@ -1082,34 +1093,17 @@
if (xRequest) {
const char* methodname =
XMLRPC_RequestGetMethodName(xRequest);
- zval **php_function;
XMLRPC_VALUE xAnswer = NULL;
MAKE_STD_ZVAL(data.xmlrpc_method); /* init.
very important. spent a frustrating day finding this out. */
MAKE_STD_ZVAL(data.return_data);
Z_TYPE_P(data.return_data) = IS_NULL; /* in
case value is never init'd, we don't dtor to think it is a string or
something */
Z_TYPE_P(data.xmlrpc_method) = IS_NULL;
- if (!methodname) {
- methodname = "";
- }
-
/* setup some data to pass to the callback
function */
- Z_STRVAL_P(data.xmlrpc_method) =
estrdup(methodname);
- Z_STRLEN_P(data.xmlrpc_method) =
strlen(methodname);
- Z_TYPE_P(data.xmlrpc_method) = IS_STRING;
data.caller_params = *caller_params;
data.php_executed = 0;
data.server = server;
- /* check if the called method has been
previous registered */
- if (zend_hash_find(Z_ARRVAL_P(server-
>method_map),
-
Z_STRVAL_P(data.xmlrpc_method),
-
Z_STRLEN_P(data.xmlrpc_method) + 1,
-
(void**)&php_function) == SUCCESS) {
-
- data.php_function = *php_function;
- }
-
/* We could just call the php method directly
ourselves at this point, but we do this
* with a C callback in case the xmlrpc
library ever implements some cool usage stats,
* or somesuch.
@@ -1119,7 +1113,7 @@
zval_dtor(data.return_data);
FREE_ZVAL(data.return_data);
data.return_data =
XMLRPC_to_PHP(xAnswer);
- } else if (data.php_executed &&
!out.b_php_out) {
+
#50717 [Ana->Fbk]: Slow download speed
ID: 50717 Updated by: j...@php.net Reported By: abaddon_a2006 at yahoo dot com -Status: Analyzed +Status: Feedback Bug Type: cURL related Operating System: fedora 12 PHP Version: 5.3.1 -Assigned To: +Assigned To: rasmus Previous Comments: [2010-01-14 21:46:51] ras...@php.net I doubt this is a PHP issue, if it even is an issue at all. From the PHP side there is no difference between a request with a cookie and one without. That's all inside libcurl. Try emulating the same thing from the command-line curl client with and without a cookie jar and see if you see the same effect. I predict you will. [2010-01-12 10:59:56] abaddon_a2006 at yahoo dot com curl 7.19.7 (i386-redhat-linux-gnu) libcurl/7.19.7 NSS/3.12.4.5 zlib/1.2.3 libidn/1.9 libssh2/1.2 Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp Features: GSS-Negotiate IDN IPv6 Largefile SSL libz [2010-01-12 10:19:25] j...@php.net What curl version have you compiled PHP with? [2010-01-11 16:02:15] abaddon_a2006 at yahoo dot com here it is a code that reproduce the problem $ch = curl_init(); curl_setopt($ch, CURLOPT_COOKIEJAR, "name"); curl_setopt($ch, CURLOPT_URL,"http://url/login.php";); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, 'user=username&password=pass'); ob_start(); // prevent any output curl_exec ($ch); // execute the curl command ob_end_clean(); // stop preventing output curl_close ($ch); unset($ch); $opt = array( CURLOPT_RETURNTRANSFER => 1, CURLOPT_COOKIEFILE => "name", CURLOPT_USERAGENT => "Mozilla/5.001 (windows; U; NT4.0; en-US; rv:1.0) Gecko/25250101", CURLOPT_PORT => "80" ); if i submit this code everything is ok 0.21246290206909 seconds this is the time response but if i add this under it $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, 'http://url'); curl_setopt_array($ch,$opt); $content = curl_exec($ch); print_r(curl_getinfo($ch)); curl_close($ch); here is what it does return and it's weird yesterday i had no problem with namelookup_time and today it does seem that it's unable to calculate it... Array ( [url] => http://url [content_type] => text/html; charset=utf-8 [http_code] => 200 [header_size] => 244 [request_size] => 227 [filetime] => -1 [ssl_verify_result] => 0 [redirect_count] => 0 [total_time] => 5.878797 [namelookup_time] => 2.6E-5 [connect_time] => 0.06947 [pretransfer_time] => 0.069475 [size_upload] => 0 [size_download] => 19463 [speed_download] => 3310 [speed_upload] => 0 [download_content_length] => -1 [upload_content_length] => 0 [starttransfer_time] => 5.74344 [redirect_time] => 0 ) This page was created in 6.0242450237274 seconds hope this will be fixed soon thank you [2010-01-10 22:35:20] j...@php.net 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. 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/50717 -- Edit this bug report at http://bugs.php.net/?id=50717&edit=1
#50737 [Opn->Bgs]: stream_set_blocking creates high cpu usage
ID: 50737 Updated by: j...@php.net Reported By: jason at lentink dot net -Status: Open +Status: Bogus Bug Type: Streams related Operating System: Linux PHP Version: 5.2.12 New Comment: Strike 3. As long as you can not provide a short reproducing script (like described in my first comment to this report) the bug is most likely something you did wrong. Previous Comments: [2010-01-14 12:53:42] jason at lentink dot net Whatever you want :) http://www.grasvezel.nl/media/software/cpuload.txt Here is a complete undressed file which only has the problem. [2010-01-14 12:17:19] j...@php.net I asked for small, complete script NOT for a framework. [2010-01-14 12:13:36] jason at lentink dot net I could provide you guys with a small script bug i can also point you to the place where the problem exists since it happens in Zend Framework. http://framework.zend.com/svn/framework/standard/trunk/library/Zend/Queu e/Stomp/Client/Connection.php The function is used at line 79. What i see on my servers is that when there are simultaneous request made to the same script the problem increases more rapidly. [2010-01-13 12:07:10] j...@php.net 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. [2010-01-13 09:58:52] jason at lentink dot net Description: When using stream_set_blocking on a stream will create a huge load on cpu. When using this function it uses up to 50% of the cpu. When not using this function it will only use 0.1% cpu usage. Reproduce code: --- $this->_socket = fsockopen($str, $port, $errno, $errstr); stream_set_blocking($this->_socket, 0); // non blocking Expected result: An socket which will be opened fast. in a non-blocking mode. Actual result: -- An open socket. But the cpu use is enormous. -- Edit this bug report at http://bugs.php.net/?id=50737&edit=1
#50749 [Opn->Bgs]: max_file_uploads counts empty uploads as well
ID: 50749 Updated by: j...@php.net Reported By: anzenews at volja dot net -Status: Open +Status: Bogus Bug Type: PHP options/info functions Operating System: Linux PHP Version: 5.2.12 New Comment: Of course it does, that's exactly it's purpose: to limit maximum number of uploads. And yes, even "empty" upload is an upload. Previous Comments: [2010-01-14 13:46:53] anzenews at volja dot net Description: Setting max_file_uploads limits the number of file input fields on HTML page instead of limiting the number of actually uploaded files. Reproduce code: --- \n". ''."\n"; }; ?> Expected result: When you upload a single file (in the LAST!!! input box) and hit "OK!", you should see the uploaded file. Actual result: -- Instead you see just 20 empty file uploads. (if max_file_uploads is set to 20, as per default) The max_file_uploads setting should never count empty files. -- Edit this bug report at http://bugs.php.net/?id=50749&edit=1
#50751 [Opn->Bgs]: Setting memcache handler by ini_set doesn't work with enabled safe_mode
ID: 50751 Updated by: j...@php.net Reported By: kukulich at kukulich dot cz -Status: Open +Status: Bogus Bug Type:Session related PHP Version: 5.3.1 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2010-01-14 14:29:31] kukulich at kukulich dot cz Description: Setting memcache handler by ini_set doesn't work with enabled safe_mode. It works with disabled safe_mode. It also works if handler and save_path are set in php.ini. Reproduce code: --- http://bugs.php.net/?id=50751&edit=1
#50761 [Ver]: system.multiCall crashes
ID: 50761
Updated by: j...@php.net
Reported By: hiroaki dot kawai at gmail dot com
Status: Verified
Bug Type: XMLRPC-EPI related
Operating System: *
PHP Version: 5.*, 6
New Comment:
I hope that patch is against latest SVN checkout of PHP_5_3 and
propably applies also to trunk and PHP_5_2 ? Could you please put the
patch somewhere to be downloaded from.
Previous Comments:
[2010-01-15 07:03:28] hiroaki dot kawai at gmail dot com
Description:
xmlrpc-epi supports system.multiCall(), which packs multiple xmlrpc
method call transactions into one. Using this method in php extension
cause php process crash.
The point was that we must let xmlrpc-epi to decode the multicall
request. We must check the method name in the callback function.
This bug exists very long time. http://bugs.php.net/bug.php?id=27446
patch is available:
-
--- xmlrpc-epi-php.c.orig 2009-08-18 09:41:43.0 +0900
+++ xmlrpc-epi-php.c2010-01-14 13:58:48.028867000 +0900
@@ -892,12 +892,23 @@
static XMLRPC_VALUE php_xmlrpc_callback(XMLRPC_SERVER server,
XMLRPC_REQUEST xRequest, void* data) /* {{{ */
{
xmlrpc_callback_data* pData = (xmlrpc_callback_data*)data;
+ zval** php_function;
zval* xmlrpc_params;
zval* callback_params[3];
TSRMLS_FETCH();
/* convert xmlrpc to native php types */
+ ZVAL_STRING(pData->xmlrpc_method,
XMLRPC_RequestGetMethodName(xRequest), 1);
xmlrpc_params =
XMLRPC_to_PHP(XMLRPC_RequestGetData(xRequest));
+
+ /* check if the called method has been previous registered */
+ if(zend_hash_find(Z_ARRVAL_P(pData->server->method_map),
+ Z_STRVAL_P(pData->xmlrpc_method),
+ Z_STRLEN_P(pData->xmlrpc_method) + 1,
+ (void**)&php_function) == SUCCESS) {
+
+ pData->php_function = *php_function;
+ }
/* setup data hoojum */
callback_params[0] = pData->xmlrpc_method;
@@ -913,7 +924,7 @@
zval_ptr_dtor(&xmlrpc_params);
- return NULL;
+ return PHP_to_XMLRPC(pData->return_data TSRMLS_CC);
}
/* }}} */
@@ -1082,34 +1093,17 @@
if (xRequest) {
const char* methodname =
XMLRPC_RequestGetMethodName(xRequest);
- zval **php_function;
XMLRPC_VALUE xAnswer = NULL;
MAKE_STD_ZVAL(data.xmlrpc_method); /* init.
very important. spent a frustrating day finding this out. */
MAKE_STD_ZVAL(data.return_data);
Z_TYPE_P(data.return_data) = IS_NULL; /* in
case value is never init'd, we don't dtor to think it is a string or
something */
Z_TYPE_P(data.xmlrpc_method) = IS_NULL;
- if (!methodname) {
- methodname = "";
- }
-
/* setup some data to pass to the callback
function */
- Z_STRVAL_P(data.xmlrpc_method) =
estrdup(methodname);
- Z_STRLEN_P(data.xmlrpc_method) =
strlen(methodname);
- Z_TYPE_P(data.xmlrpc_method) = IS_STRING;
data.caller_params = *caller_params;
data.php_executed = 0;
data.server = server;
- /* check if the called method has been
previous registered */
- if (zend_hash_find(Z_ARRVAL_P(server-
>method_map),
-
Z_STRVAL_P(data.xmlrpc_method),
-
Z_STRLEN_P(data.xmlrpc_method) + 1,
-
(void**)&php_function) == SUCCESS) {
-
- data.php_function = *php_function;
- }
-
/* We could just call the php method directly
ourselves at this point, but we do this
* with a C callback in case the xmlrpc
library ever implements some cool usage stats,
* or somesuch.
@@ -1119,7 +1113,7 @@
zval_dtor(data.return_data);
FREE_ZVAL(data.return_data);
data.return_data =
XMLRPC_to_PHP(xAnswer);
- } else if (data.php_executed &&
!out.b_php_out) {
+ } else if (data.php_executed && !out.b_php_out
&& !xAnswer) {
xAnswer =
PHP_to_XMLRPC(data.return_data TSRMLS_CC);
}
Reproduce code:
---
system.multiCall
methodNametestMethodA
paramsA
methodNametestMethodB
paramsB
';
function test
#50761 [Opn->Ver]: system.multiCall cause Segmentation fault
ID: 50761
Updated by: j...@php.net
Reported By: hiroaki dot kawai at gmail dot com
-Status: Open
+Status: Verified
Bug Type: XMLRPC-EPI related
-Operating System:
+Operating System: *
-PHP Version: 5.3.1
+PHP Version: 5.*, 6
Previous Comments:
[2010-01-15 07:03:28] hiroaki dot kawai at gmail dot com
Description:
xmlrpc-epi supports system.multiCall(), which packs multiple xmlrpc
method call transactions into one. Using this method in php extension
cause php process crash.
The point was that we must let xmlrpc-epi to decode the multicall
request. We must check the method name in the callback function.
This bug exists very long time. http://bugs.php.net/bug.php?id=27446
patch is available:
-
--- xmlrpc-epi-php.c.orig 2009-08-18 09:41:43.0 +0900
+++ xmlrpc-epi-php.c2010-01-14 13:58:48.028867000 +0900
@@ -892,12 +892,23 @@
static XMLRPC_VALUE php_xmlrpc_callback(XMLRPC_SERVER server,
XMLRPC_REQUEST xRequest, void* data) /* {{{ */
{
xmlrpc_callback_data* pData = (xmlrpc_callback_data*)data;
+ zval** php_function;
zval* xmlrpc_params;
zval* callback_params[3];
TSRMLS_FETCH();
/* convert xmlrpc to native php types */
+ ZVAL_STRING(pData->xmlrpc_method,
XMLRPC_RequestGetMethodName(xRequest), 1);
xmlrpc_params =
XMLRPC_to_PHP(XMLRPC_RequestGetData(xRequest));
+
+ /* check if the called method has been previous registered */
+ if(zend_hash_find(Z_ARRVAL_P(pData->server->method_map),
+ Z_STRVAL_P(pData->xmlrpc_method),
+ Z_STRLEN_P(pData->xmlrpc_method) + 1,
+ (void**)&php_function) == SUCCESS) {
+
+ pData->php_function = *php_function;
+ }
/* setup data hoojum */
callback_params[0] = pData->xmlrpc_method;
@@ -913,7 +924,7 @@
zval_ptr_dtor(&xmlrpc_params);
- return NULL;
+ return PHP_to_XMLRPC(pData->return_data TSRMLS_CC);
}
/* }}} */
@@ -1082,34 +1093,17 @@
if (xRequest) {
const char* methodname =
XMLRPC_RequestGetMethodName(xRequest);
- zval **php_function;
XMLRPC_VALUE xAnswer = NULL;
MAKE_STD_ZVAL(data.xmlrpc_method); /* init.
very important. spent a frustrating day finding this out. */
MAKE_STD_ZVAL(data.return_data);
Z_TYPE_P(data.return_data) = IS_NULL; /* in
case value is never init'd, we don't dtor to think it is a string or
something */
Z_TYPE_P(data.xmlrpc_method) = IS_NULL;
- if (!methodname) {
- methodname = "";
- }
-
/* setup some data to pass to the callback
function */
- Z_STRVAL_P(data.xmlrpc_method) =
estrdup(methodname);
- Z_STRLEN_P(data.xmlrpc_method) =
strlen(methodname);
- Z_TYPE_P(data.xmlrpc_method) = IS_STRING;
data.caller_params = *caller_params;
data.php_executed = 0;
data.server = server;
- /* check if the called method has been
previous registered */
- if (zend_hash_find(Z_ARRVAL_P(server-
>method_map),
-
Z_STRVAL_P(data.xmlrpc_method),
-
Z_STRLEN_P(data.xmlrpc_method) + 1,
-
(void**)&php_function) == SUCCESS) {
-
- data.php_function = *php_function;
- }
-
/* We could just call the php method directly
ourselves at this point, but we do this
* with a C callback in case the xmlrpc
library ever implements some cool usage stats,
* or somesuch.
@@ -1119,7 +1113,7 @@
zval_dtor(data.return_data);
FREE_ZVAL(data.return_data);
data.return_data =
XMLRPC_to_PHP(xAnswer);
- } else if (data.php_executed &&
!out.b_php_out) {
+ } else if (data.php_executed && !out.b_php_out
&& !xAnswer) {
xAnswer =
PHP_to_XMLRPC(data.return_data TSRMLS_CC);
}
Reproduce code:
---
system.multiCall
methodNametestMethodA
paramsA
methodNametestMethodB
paramsB
';
function testA($methodName, $params, $var){ return "C"; }
function testB($methodName, $params, $var){ return "D"; }
$server = xmlrp
#50754 [Bgs]: var_export emits erroneous outputs on vars that contain recursive references
ID: 50754 User updated by: andrew at trib dot tv Reported By: andrew at trib dot tv Status: Bogus Bug Type: Output Control Operating System: Fed PHP Version: 5.3.1 New Comment: Derek, Thank you for taking the time to select a canned response, though it would be much more encouraging to bug reporters if you actually responded to the points made (at length and in the correct manner) in the bug report before dismissing it as bogus. Could you comment on why this is not a security vulnerability? The security implications were initally raised *eight years ago* in bug 17874 by icecube at fr dot fm, but there has been no followup, hence my fresh bug report. If serialize($GLOBALS) manages to finish without crashing PHP and sending a half-complete invalid and potentially sensitive serialisation string to the browser / console, I don't understand why var_export can't do the same, nor what the justification is for claiming that the current behaviour is desirable. Cheers, Andrew Previous Comments: [2010-01-14 22:00:57] der...@php.net 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 Remove the @ and you see what really happens: Fatal error: Nesting level too deep - recursive dependency? in - on line 9 [2010-01-14 16:52:57] andrew at trib dot tv Description: My case is one in which var_export is being used to expose private members of classes present in the context of an error. So an error occurs, a custom handler is invoked, and it var_exports any variables in the error context which are objects, so that developers investigating the problem can see the values of private vars within these objects at the time the error occured. However, doing this: $str = var_export($object, true); If $object contains recursive references, var_export not only fails with a fatal error that cannot be handled or suppressed, but also flushes its internal output buffer, so if you've set the second argument to true, wanting the output returned rather than sent to the browser, you're out of luck, because it's gone. This is a security issue, because in some situations, a developer may have implemented var_export on objects with passwords stored within, and expects to get the object returned in a string. If the entire content of the object (up to the recursive reference) is instead output to the browser, this data is inadvertently exposed. I'd say that in such situations var_export should trigger an E_WARNING and return null or false. Then it can be safely used on objects that do not contain recursive references without having to know whether they do or not before you call the function. I'm aware of previous bugs filed on this issue, notably 17874 and 16074, so I raise this specifically in relation to te security implications, and also making the point that it is not possible to detect whether an object contains *private* recursive references before you take your life in your hands by throwing it at var_export and crossing your fingers! Cheers, Andrew Reproduce code: --- reftoself = $this; } } $x = new PrivateThing; $y = @var_export($x, true); echo "No passwords here!"; ?> Expected result: No passwords here! Actual result: -- PrivateThing::__set_state(array( 'publicvar' => 'notsecret', 'password' => 'supersecret', 'reftoself' => PrivateThing::__set_state(array( 'publicvar' => 'notsecret', 'password' => 'supersecret', 'reftoself' => PrivateThing::__set_state(array( 'publicvar' => 'notsecret', 'password' => 'supersecret', 'reftoself' => PrivateThing::__set_state(array( -- Edit this bug report at http://bugs.php.net/?id=50754&edit=1
