#46905 [NEW]: Update libxml2 to version 2.7.x
From: peaceable_whale at hotmail dot com Operating system: Windows PHP version: 5.3.0alpha3 PHP Bug Type: XML related Bug description: Update libxml2 to version 2.7.x Description: The libxml2 library bundled with PHP 5.3 and PHP 6 should be 2.7.x because XML 1.0 5th edition (http://www.w3.org/TR/2008/REC-xml-20081126/) is supported since libxml2 2.7.0. I am not sure if the library should be updated in PHP 5.2, as XML 1.0 5th edition changed some well-formness rules. However, for newer PHP versions and future development of XML, the library should be updated. -- Edit bug report at http://bugs.php.net/?id=46905&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46905&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46905&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46905&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46905&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46905&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46905&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46905&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46905&r=needscript Try newer version: http://bugs.php.net/fix.php?id=46905&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46905&r=support Expected behavior: http://bugs.php.net/fix.php?id=46905&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46905&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46905&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46905&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46905&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46905&r=dst IIS Stability: http://bugs.php.net/fix.php?id=46905&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46905&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46905&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46905&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46905&r=mysqlcfg
#46283 [Opn->Fbk]: array_merge_recursive() Warning recursion detected in...
ID: 46283
Updated by: j...@php.net
Reported By: name at email dot com
-Status: Open
+Status: Feedback
Bug Type: Arrays related
Operating System: *
PHP Version: 5CVS-2008-11-17
New Comment:
Explain "preserve" ?
Previous Comments:
[2008-11-28 20:04:02] name at email dot com
@lbarnaud
you are correct about the warning.
it might be unrelated to this problem, i thought it was.
about the weird output,
i thought the function supposed to preserve the object, please correct
me if im wrong.
thanks
[2008-11-26 02:41:32] lbarn...@php.net
I can't reproduce with 5.3CVS (no warnings).
The weird output is caused by two null bytes and the class name added
to private properties. You get the same output when casting a class to
an array.
[2008-11-17 13:42:33] name at email dot com
@jani
PHP Version 5.2.7RC4-dev
Build Date Nov 17 2008 11:39:11
array(1) {
["name"]=>
array(1) {
["�A�variable"]=>
array(2) {
[0]=>
string(3) "foo"
[1]=>
string(3) "foo"
}
}
}
[2008-10-29 15:18:38] name at email dot com
@jani
1. passing two arrays.
2. they both contain a reference to an object.
3. i expect the function to preserve the structure of the object.
4. notice: ["�A�variable"] <-- whats that?
[2008-10-26 19:19:46] j...@php.net
What's the problem here? You're passing an object to a function
expecting arrays and think it will work..?
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/46283
--
Edit this bug report at http://bugs.php.net/?id=46283&edit=1
#46839 [Opn->Bgs]: cant compile 5.2.8 with imap c-client compiled manually
ID: 46839 Updated by: j...@php.net Reported By: naox at o2 dot pl -Status: Open +Status: Bogus Bug Type: IMAP related Operating System: linux centos 5 PHP Version: 5.2.8 New Comment: So obviously you have now messed up your system somehow. Please cleanup all (and I mean ALL) headers and libraries from your system, recompile and reconfigure PHP and it will work. Previous Comments: [2008-12-18 01:58:49] naox at o2 dot pl linkage.h in c-client does not contain auth_gss. Also compiling wihtout '--with-kerberos' makes no diffrence [2008-12-17 02:47:01] j...@php.net So does that linkage.h contain auth_gss ? [2008-12-16 19:01:16] naox at o2 dot pl Yes, I use '--with-kerberos' on my configure. And also '--with-imap=/root/c-client-my' That has files from compiled imap-2007d - files are placed as instructed at http://pl.php.net/manual/en/imap.setup.php all of these files comes from imap-2007d... [2008-12-16 18:31:09] j...@php.net Are you sure you don't have linkage.h file from some other build than that you compiled yourself? And did you use --with-kerberos in your php configure line? [2008-12-12 00:38:44] naox at o2 dot pl Description: I use manualy compiled imap-2007d. I do this because there is a problem - c-client has small number FD_SETSIZE. If your apache httpd.conf opens a lot of log files than c-client crashes apache child if called from PHP. So I cant use standard c-client suplied with linux. Now when I try to compile PHP 5.2.8 with manualy complied c-client /root/naox/php-5.2.8.mod/ext/imap/php_imap.c: In function 'zm_startup_imap': /root/naox/php-5.2.8.mod/ext/imap/php_imap.c:477: error: 'auth_gss' undeclared (first use in this function) /root/naox/php-5.2.8.mod/ext/imap/php_imap.c:477: error: (Each undeclared identifier is reported only once /root/naox/php-5.2.8.mod/ext/imap/php_imap.c:477: error: for each function it appears in.) /root/naox/php-5.2.8.mod/ext/imap/php_imap.c: In function 'zif_imap_rfc822_parse_adrlist': /root/naox/php-5.2.8.mod/ext/imap/php_imap.c:2175: warning: passing argument 3 of 'rfc822_parse_adrlist' from incompatible pointer type make: *** [ext/imap/php_imap.lo] Error 1 Problem only occurs in PHP 5.2.8. In PHP 5.2.6 everything works fine. Also problem does not appear if I compile PHP 5.2.8 with standard c- client suplied with linux. If I copy ext/imap/php_imap.c from 5.2.6 into 5.2.8 I can compile php without problems There are some old bug reports about this problem resolved years ago with "fixed in cvs". So I suspect you reverted your php_imap.c in 5.2.8 to state where it was not fixec. -- Edit this bug report at http://bugs.php.net/?id=46839&edit=1
#45922 [Com]: data is not transmitted throught pipes created by proc_open
ID: 45922
Comment by: scruoge at gmail dot com
Reported By: TorokAlpar at Gmail dot com
Status: Open
Bug Type: Streams related
Operating System: Windows Xp
PHP Version: 5.2CVS-2008-08-27
New Comment:
PHP Version 5.2.6, Apache/2.0.63 Handler
Linux hostname 2.6.18-53.el5 #1 SMP Mon Nov 12 02:22:48 EST 2007 i686
I have exactly same bug. Script just silently dies.
here is the code:
array("pipe", "r"),
1 => array("pipe", "w"),
2 => array("file", "/home/user/error-output.txt", "a")
);
$process = proc_open('/usr/local/bin/client', $desc, $pipes);
if (is_resource($process)) {
fwrite($pipes[0], $line);
fclose($pipes[0]);
$line = '';
while (($s = fgets($pipes[1], 1000)) !== false)
{
$s = trim($s, "\r\n");
$line.= $s;
if(strpos($s, '') !== false) break;
}
fclose($pipes[1]);
$return_value = proc_close($process);
}
$line = trim($line, "\r\n");
return $line;
}
echo test1('asdfasdf')."\n";
?>
Previous Comments:
[2008-08-27 08:56:20] TorokAlpar at Gmail dot com
I have tried with the latest snapshot, the result is the same
[2008-08-26 14:31:43] TorokAlpar at Gmail dot com
Description:
After starting a program (Written in C) with proc_open the pipes
opened seem to be invalid. It looks like no data is transmitted over to
the childs stdin, On a read the script blocks.
Please bear with me, this is my firs bug report, and i am debugging
this for 7 hours now.
here are my modules:
[PHP Modules]
bcmath
calendar
com_dotnet
ctype
date
dom
domxml
exif
filter
ftp
gd
gettext
hash
iconv
imap
json
libxml
mbstring
mcrypt
mime_magic
ming
mssql
mysql
mysqli
odbc
paradox
pcre
pdf
PDO
pdo_mssql
pdo_mysql
ps
Reflection
session
SimpleXML
soap
sockets
SPL
SQLite
standard
tokenizer
wddx
xdebug
xml
xmlreader
xmlrpc
xmlwriter
xsl
zip
zlib
[Zend Modules]
Xdebug
Note tha i also tried without Xdebug
Reproduce code:
---
$aDescriptorspec = array(
0 => array("pipe", "r"), // stdin is a pipe that
the child will read from
1 => array("pipe", "w"), // stdout is a pipe that
the child will write to
2 => array("pipe", "w") // stderr is a file to
write to
);
$aOptions = array('bypass_shell' => true); // doesn't
influence the behavior
$rProcess = proc_open('F:\\checkpe-debug2.exe validpe',
$aDescriptorspec, $aPipes, null,null, $aOptions);
// $aPipes now looks like this:
// 0 => writeable handle connected to child stdin
// 1 => readable handle connected to child stdout
if (! is_resource($rProcess)) {
// stream_set_write_buffer($aPipes[0], 0);
//fputs($aPipes[0],$sPath."\n",strlen($sPath)+1);
fwrite($aPipes[0],$sPath."\n");
//fflush($aPipes[0]);
sleep(1);
$sResponse = fread($aPipes[1],2);
var_dump($sResponse);
}
/*
NOTE : Commented lines don't influence the result if they are not
commented
The executable does work right, tested on the command line
If you swap the executable with a php script that does the same
thing (reads in file paths separated with \n and writes 2 character
responses) everything functions as expected
*/
Expected result:
var_dump the 2 characters read from the output of the child
Actual result:
--
Script hangs , hang caused by the lien that reads:
$sResponse = fread($aPipes[1],2);
--
Edit this bug report at http://bugs.php.net/?id=45922&edit=1
#46814 [Opn]: Relative includes from symlinked directories fail
ID: 46814 User updated by: dennis dot birkholz at nexxes dot net Reported By: dennis dot birkholz at nexxes dot net Status: Open Bug Type: Scripting Engine problem Operating System: Gentoo/Linux PHP Version: 5.2.8 New Comment: No, you did not read my initial post correctly: a file/directory starting with a / (like /test1) means it is in the root-directory. All example pathnames where absolute pathnames, not relative. Here comes my listing for you: /htdocs/: total 12 drwxr-xr-x 3 root root 4096 Dec 18 22:23 ./ drwxr-xr-x 22 root root 4096 Dec 18 22:23 ../ drwxr-xr-x 2 root root 4096 Dec 18 22:23 docs/ lrwxrwxrwx 1 root root6 Dec 18 22:23 test2 -> /test1/ /htdocs/docs/: insgesamt 8 drwxr-xr-x 2 root root 4096 18. Dez 22:23 ./ drwxr-xr-x 3 root root 4096 18. Dez 22:23 ../ -rw-r--r-- 1 root root0 18. Dez 22:23 docs.inc.php /test1/: total 8 drwxr-xr-x 2 root root 4096 18. Dez 22:24 ./ drwxr-xr-x 22 root root 4096 18. Dez 22:23 ../ -rw-r--r-- 1 root root0 18. Dez 22:24 index.php Please note that test1 and test2 are not on the same directory level! Previous Comments: [2008-12-18 09:05:37] php at degoulet dot net I don't realy understand your problem ?! [r...@pix sdv]# ls -alR .: total 16 drwxr-xr-x 4 root root4096 Dec 17 17:44 . drwxrwxrwx 3 via ftponly 4096 Dec 17 17:44 .. drwxr-xr-x 2 root root4096 Dec 17 17:45 docs drwxr-xr-x 2 root root4096 Dec 17 17:46 test1 lrwxrwxrwx 1 root root 5 Dec 17 17:44 test2 -> test1 ./docs: total 12 drwxr-xr-x 2 root root 4096 Dec 17 17:45 . drwxr-xr-x 4 root root 4096 Dec 17 17:44 .. -rw-r--r-- 1 root root 24 Dec 17 17:45 docs.inc.php ./test1: total 12 drwxr-xr-x 2 root root 4096 Dec 17 17:46 . drwxr-xr-x 4 root root 4096 Dec 17 17:44 .. -rw-r--r-- 1 root root 50 Dec 17 17:46 index.php [r...@pix sdv]# cat test1/index.php [r...@pix sdv]# cat docs/docs.inc.php No problem when i try this with apache : http://www..com/sdv/test1/index.php http://www..com/sdv/test2/index.php ==> same output : docs ok if you try this in command line. 3 cases : - pwd= test1 : php index.php => output docs ok - pwd= test2 : php index.php => output docs ok - pwd= anywhere else : php ./test1/index.php : include(): Unable to access ../docs/docs.inc.php which is quite normal the include path is relative to the current directory where php is executed not relative to the php script which is executed ... isn't it ? [2008-12-17 22:35:25] dennis dot birkholz at nexxes dot net This IS a bug: in Linux (and Unix like systems) beeing in a symlinked directory should behave exactly like beeing in a directory with the same content. To use my example: If I use a shell and change to the folder /htdocs/test2 (which is a symlink to /test1), ls ../docs/docs.inc.php will show me the file "/htdocs/docs/docs.inc.php" and NOT "/docs/docs.inc.php". [2008-12-17 16:53:29] php at degoulet dot net quite normal : not a bug [2008-12-09 18:17:42] dennis dot birkholz at nexxes dot net Description: include statement seems to resolve the current working directory other than the rest of php so if I am in a symlinked directory an try to include a file using a relative path (containing ../), the include fails because the original path of the script is used to resolve the relative include and not the path the script is invoked from. Reproduce code: --- Asume the following files/directory structure: Directory /test1 Directory /htdocs Directory /htdocs/docs Symlink /htdocs/test2 -> /test1 File /test1/index.php File /htdocs/docs/docs.inc.php DocumentRoot is /htdocs File-Contents of /test1/index.php Expected result: No error, output generated by code after the include Actual result: -- An error: failed to open stream: No such file or directory (/test1/index.php:2) -- Edit this bug report at http://bugs.php.net/?id=46814&edit=1
#46896 [Bgs]: stream_get_meta_data() does not fill header list
ID: 46896
User updated by: christian dot lefebvre at atosorigin dot com
Reported By: christian dot lefebvre at atosorigin dot com
Status: Bogus
Bug Type: cURL related
Operating System: linux
PHP Version: 5.2.8
New Comment:
Sorry, but in the given example, the call to the function returns a
meta_data element with an EMPTY header sub-array despite the remote
server do returns headers.
The expected result is an array with header lines, and that's done only
if you use fread BEFORE.
Previous Comments:
[2008-12-18 20:31:17] il...@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
The function always puts the headers into the wrapper_data element,
this
is consistent with PHP 5.1.2 and 5.3.0.
The position of the fread() does not make any difference in the
output.
[2008-12-18 11:37:27] j...@php.net
See also bug #45092 (quite likely related)
[2008-12-18 10:22:33] christian dot lefebvre at atosorigin dot com
Description:
With php 5.2.8 and curlwrapper option, after calling fopen() on a
remote url, a call to stream_get_meta_data() returns an empty header
list.
If a call to fread() is inserted between fopen() and
stream_get_meta_data(), the headers are presents.
The problem appears during a migration from 5.0 without curl, to 5.2
with curl, so it seems curl related.
Calling the test script via strace shows that the socket is opened, but
there's no call to read() syscall before the stream_get_meta_data is
called.
The problem is not systematically reproduced (certainly due to response
latencies), but appears very often.
Reproduce code:
---
this version fails :
$src = fopen("http://www.perdu.com";, 'r');
$meta = stream_get_meta_data($src);
var_dump($meta);
var_dump($http_response_header);
$data= fread($src, 500);
echo $data."\n\n";
this one works (just call fread before get_meta) :
$src = fopen("http://www.perdu.com";, 'r');
$data= fread($src, 500);
$meta = stream_get_meta_data($src);
var_dump($meta);
var_dump($http_response_header);
echo $data."\n\n";
Expected result:
array(10) {
["wrapper_data"]=>
array(2) {
["headers"]=>
array(8) {
[0]=>
string(15) "HTTP/1.1 200 OK"
[1]=>
string(35) "Date: Thu, 18 Dec 2008 10:15:19 GMT"
[2]=>
string(14) "Server: Apache"
[3]=>
Actual result:
--
array(10) {
["wrapper_data"]=>
array(2) {
["headers"]=>
array(0) {
}
...
--
Edit this bug report at http://bugs.php.net/?id=46896&edit=1
#46268 [Asn->Csd]: When call DateTime#setTime, it seems to be called the last modify method too
ID: 46268
Updated by: der...@php.net
Reported By: shimooka at doyouphp dot jp
-Status: Assigned
+Status: Closed
Bug Type: Date/time related
Operating System: *
PHP Version: 5.3CVS-2008-11-11
Assigned To: derick
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2008-10-10 04:27:11] shimooka at doyouphp dot jp
Description:
When I call DateTime#setTime, it seems to be called the last modify
method too. If I use date_time_set function, I get the same result.
This report is similar to Bug #41599, but differ from #41599 in using
'time'(01:02:03).
With PHP5.2.6, I get the expected result.
Reproduce code:
---
format("Y-m-d H:i:s") . PHP_EOL;
$now->modify("1 day after");
echo $now->format("Y-m-d H:i:s") . PHP_EOL;
$now->modify("1 hour after");
echo $now->format("Y-m-d H:i:s") . PHP_EOL;
$now->setTime(0, 0, 0);
//date_time_set($now, 0, 0, 0);
echo $now->format("Y-m-d H:i:s") . PHP_EOL;
Expected result:
2008-10-10 01:02:03
2008-10-11 01:02:03
2008-10-11 02:02:03
2008-10-11 00:00:00
Actual result:
--
2008-10-10 01:02:03
2008-10-11 01:02:03
2008-10-11 02:02:03
2008-10-11 01:00:00
--
Edit this bug report at http://bugs.php.net/?id=46268&edit=1
#46896 [Opn->Bgs]: stream_get_meta_data() does not fill header list
ID: 46896
Updated by: il...@php.net
Reported By: christian dot lefebvre at atosorigin dot com
-Status: Open
+Status: Bogus
Bug Type: cURL related
Operating System: linux
PHP Version: 5.2.8
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The function always puts the headers into the wrapper_data element,
this
is consistent with PHP 5.1.2 and 5.3.0.
The position of the fread() does not make any difference in the
output.
Previous Comments:
[2008-12-18 11:37:27] j...@php.net
See also bug #45092 (quite likely related)
[2008-12-18 10:22:33] christian dot lefebvre at atosorigin dot com
Description:
With php 5.2.8 and curlwrapper option, after calling fopen() on a
remote url, a call to stream_get_meta_data() returns an empty header
list.
If a call to fread() is inserted between fopen() and
stream_get_meta_data(), the headers are presents.
The problem appears during a migration from 5.0 without curl, to 5.2
with curl, so it seems curl related.
Calling the test script via strace shows that the socket is opened, but
there's no call to read() syscall before the stream_get_meta_data is
called.
The problem is not systematically reproduced (certainly due to response
latencies), but appears very often.
Reproduce code:
---
this version fails :
$src = fopen("http://www.perdu.com";, 'r');
$meta = stream_get_meta_data($src);
var_dump($meta);
var_dump($http_response_header);
$data= fread($src, 500);
echo $data."\n\n";
this one works (just call fread before get_meta) :
$src = fopen("http://www.perdu.com";, 'r');
$data= fread($src, 500);
$meta = stream_get_meta_data($src);
var_dump($meta);
var_dump($http_response_header);
echo $data."\n\n";
Expected result:
array(10) {
["wrapper_data"]=>
array(2) {
["headers"]=>
array(8) {
[0]=>
string(15) "HTTP/1.1 200 OK"
[1]=>
string(35) "Date: Thu, 18 Dec 2008 10:15:19 GMT"
[2]=>
string(14) "Server: Apache"
[3]=>
Actual result:
--
array(10) {
["wrapper_data"]=>
array(2) {
["headers"]=>
array(0) {
}
...
--
Edit this bug report at http://bugs.php.net/?id=46896&edit=1
#46887 [Opn->Csd]: -Werror=format-security - compile failure with ext/xmlwriter/php_xmlwriter.c
ID: 46887
Updated by: il...@php.net
Reported By: oeriksson at mandriva dot com
-Status: Open
+Status: Closed
Bug Type: XML Writer
Operating System: Mandriva Cooker
PHP Version: 5.2.8
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2008-12-17 21:20:18] crrodriguez at opensuse dot org
Yeah, and there is another one in 5_3
Index: ext/mysqli/mysqli.c
===
RCS file: /repository/php-src/ext/mysqli/mysqli.c,v
retrieving revision 1.72.2.16.2.17.2.33
diff -u -p -r1.72.2.16.2.17.2.33 mysqli.c
--- ext/mysqli/mysqli.c 27 Nov 2008 19:01:22 -
1.72.2.16.2.17.2.33
+++ ext/mysqli/mysqli.c 17 Dec 2008 21:18:33 -
@@ -1352,7 +1352,7 @@ if (a) {\
#define LOCAL_INFILE_ERROR_MSG(source,dest)\
memset(source, 0, LOCAL_INFILE_ERROR_LEN);\
memcpy(source, dest, MIN(strlen(dest),
LOCAL_INFILE_ERROR_LEN-1));\
- php_error_docref(NULL TSRMLS_CC, E_WARNING, dest);
+ php_error_docref(NULL TSRMLS_CC, E_WARNING,"%s", dest);
/* {{{ php_local_infile_init
[2008-12-17 10:47:04] oeriksson at mandriva dot com
Description:
I get a build error when using -Werror=format-security with
php_xmlwriter.c
Reproduce code:
---
Proposed fix:
[o...@oe BUILD]$ cat
php-5.2.8-format_not_a_string_literal_and_no_format_arguments.diff
--- ext/xmlwriter/php_xmlwriter.c 2008-12-16 17:31:11.0
+0100
+++ ext/xmlwriter/php_xmlwriter.c.oden 2008-12-16 17:31:54.0
+0100
@@ -168,7 +168,7 @@ static zend_object_value xmlwriter_objec
#define XMLW_NAME_CHK(__err) \
if (xmlValidateName((xmlChar *) name, 0) != 0) {\
- php_error_docref(NULL TSRMLS_CC, E_WARNING, __err);
\
+ php_error_docref(NULL TSRMLS_CC, E_WARNING, "%s",
__err); \
RETURN_FALSE; \
} \
Expected result:
It should build?
Actual result:
--
/home/oden/RPM/BUILD/php-5.2.8/ext/xmlwriter/php_xmlwriter.c: In
function 'php_xmlwriter_string_arg':
/home/oden/RPM/BUILD/php-5.2.8/ext/xmlwriter/php_xmlwriter.c:441:
error: format not a string literal and no format arguments
--
Edit this bug report at http://bugs.php.net/?id=46887&edit=1
#16040 [Com]: nested preg_replace_callback()'s won't work
ID: 16040
Comment by: ilatypov at infradead dot org
Reported By: markus dot pfefferle at web dot de
Status: No Feedback
Bug Type: PCRE related
Operating System: Linux
PHP Version: 4.1.1
New Comment:
I downgraded to PHP 5.2.8, and the nested regexp replacement worked.
Previous Comments:
[2008-12-18 19:44:30] ilatypov at infradead dot org
This also holds true for yesterday's CVS snapshot of PHP6, in Windows
XP.
I tried installing MediaWiki with the PHP6 snapshot and found that the
table prefix replacement in includes/db/Database.php:replaceVars()
returns corrupt data sporadically.
I found that pref_replace_callback() was the source of the corruption.
This statement:
$ins = preg_replace_callback(
'/\/\*(?:\$wgDBprefix|_)\*\/([a-zA-Z_0-9]*)/',
array( &$this, 'tableNameCallback' ),
$ins );
called the tableName() method through the callback tableNameCallback().
The former method returned a proper string but the end result in $ins
was corrupted.
On finding this earlier report, I looked closer at the
Database.tableName() method and found a call to preg_match() there.
[2002-06-16 01:00:06] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a month, 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".
[2002-04-09 17:00:00] j...@php.net
the code below works fine for me. please provide a complete example of
code that fails.
function funcB($arr) {
return 'whatever';
}
function funcA($arr) {
$someotherhaystack = '%value1% foo %value2%';
$t = preg_replace_callback("/%value([0-9]+)%/", "funcB",
$someotherhaystack);
return $t; // $t still makes sense here
}
$haystack = '%text12% bar %text13%';
echo preg_replace_callback("/%text([0-9]+)%/", "funcA", $haystack);
[2002-03-13 07:31:50] markus dot pfefferle at web dot de
A preg_replace_callback() that calls a callback function which in turn
makes use of a preg_replace_callback() function too, will not work
correctly. The first preg_replace_callback() will substitute gibberisch
even though the callback function returned a valid string.
Example:
function funcB($arr)
{
...
return $whatever;
}
function funcA($arr)
{
...
$t = preg_replace_callback("/%value([0-9]+)%/", "funcB",
$someotherhaystack)
return $t; // $t still makes sense here
}
echo preg_replace_callback("/%text([0-9]+)%/", "funcA", $haystack);
// but whatever funcA returned, just some gibberisch is substituted for
/%text[0-9]+%/
--
Edit this bug report at http://bugs.php.net/?id=16040&edit=1
#16040 [Com]: nested preg_replace_callback()'s won't work
ID: 16040
Comment by: ilatypov at infradead dot org
Reported By: markus dot pfefferle at web dot de
Status: No Feedback
Bug Type: PCRE related
Operating System: Linux
PHP Version: 4.1.1
New Comment:
This also holds true for yesterday's CVS snapshot of PHP6, in Windows
XP.
I tried installing MediaWiki with the PHP6 snapshot and found that the
table prefix replacement in includes/db/Database.php:replaceVars()
returns corrupt data sporadically.
I found that pref_replace_callback() was the source of the corruption.
This statement:
$ins = preg_replace_callback(
'/\/\*(?:\$wgDBprefix|_)\*\/([a-zA-Z_0-9]*)/',
array( &$this, 'tableNameCallback' ),
$ins );
called the tableName() method through the callback tableNameCallback().
The former method returned a proper string but the end result in $ins
was corrupted.
On finding this earlier report, I looked closer at the
Database.tableName() method and found a call to preg_match() there.
Previous Comments:
[2002-06-16 01:00:06] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a month, 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".
[2002-04-09 17:00:00] j...@php.net
the code below works fine for me. please provide a complete example of
code that fails.
function funcB($arr) {
return 'whatever';
}
function funcA($arr) {
$someotherhaystack = '%value1% foo %value2%';
$t = preg_replace_callback("/%value([0-9]+)%/", "funcB",
$someotherhaystack);
return $t; // $t still makes sense here
}
$haystack = '%text12% bar %text13%';
echo preg_replace_callback("/%text([0-9]+)%/", "funcA", $haystack);
[2002-03-13 07:31:50] markus dot pfefferle at web dot de
A preg_replace_callback() that calls a callback function which in turn
makes use of a preg_replace_callback() function too, will not work
correctly. The first preg_replace_callback() will substitute gibberisch
even though the callback function returned a valid string.
Example:
function funcB($arr)
{
...
return $whatever;
}
function funcA($arr)
{
...
$t = preg_replace_callback("/%value([0-9]+)%/", "funcB",
$someotherhaystack)
return $t; // $t still makes sense here
}
echo preg_replace_callback("/%text([0-9]+)%/", "funcA", $haystack);
// but whatever funcA returned, just some gibberisch is substituted for
/%text[0-9]+%/
--
Edit this bug report at http://bugs.php.net/?id=16040&edit=1
#46511 [Bgs]: arg list too long when compiling many modules
ID: 46511 User updated by: ben dot lentz at gmail dot com Reported By: ben dot lentz at gmail dot com Status: Bogus Bug Type: Compile Failure Operating System: AIX 5.3.8.2 PHP Version: 5.2.6 New Comment: I had the right versions of GNU sed and tried changing my shell to the latest version of bash. No dice. Simply put, enabling every php extension that I needed to build was not possible because of this issue. I received absolutely no help from filing this bug report as it was simply slapped with "Bogus" and no attention was paid to it. My workaround was to compile as many extensions as I possibly could as shared modules, disabling everything that couldn't be built --with-EXTENSION=shared. Then, I rebuilt again, disabling everything that could be shared, and enabling everything that couldn't be shared. Once the two halves were smushed together, I had a working PHP install. This doesn't begin to address the third build I'll have to do t o get the CLI SAPI *AND* the Apache shared module. I still maintain that the build system provided with PHP is woefully inadequate and I would be willing to provide testing and more feedback if someone from the PHP team is willing to listen. It seems ridiculous that I can't do one build with CLI, Apache2, and all modules without the system collapsing in on itself. ./configure \ --prefix=/opt/local \ --with-config-file-path=/opt/local/etc \ --disable-bcmath \ --enable-calendar \ --disable-dbase \ --disable-dom \ --enable-exif \ --enable-ftp \ --enable-pcntl \ --enable-shmop \ --enable-sockets \ --enable-sysvmsg \ --enable-sysvsem \ --enable-sysvshm \ --enable-wddx \ --disable-xmlreader \ --disable-xmlwriter \ --with-bz2=/opt/local \ --with-curl=/opt/local \ --with-gettext=/opt/local \ --with-gmp=/opt/local \ --with-iconv-dir=/opt/local \ --with-libxml-dir=/opt/local \ --with-openssl=/opt/local \ --with-openssl-dir=/opt/local \ --with-pspell=/opt/local \ --with-zlib=/opt/local \ --with-zlib-dir=/opt/local \ --without-db4 \ --without-gd \ --without-gdbm \ --without-imap-ssl \ --without-imap \ --without-kerberos \ --without-ldap-sasl \ --without-ldap \ --without-libmbfl \ --without-mcrypt \ --without-mhash \ --without-mm \ --without-mysql \ --without-mysqli \ --without-ncurses \ --without-pdo-mysql \ --without-pdo-odbc \ --without-readline \ --without-snmp \ --without-unixODBC \ --without-xsl make make install make clean ./configure \ --prefix=/opt/local \ --with-config-file-path=/opt/local/etc \ --enable-bcmath=shared \ --disable-calendar \ --enable-dba=shared \ --enable-dbase=shared \ --enable-dom=shared \ --disable-exif \ --disable-ftp \ --disable-pcntl \ --disable-shmop \ --disable-sockets \ --disable-sysvmsg \ --disable-sysvsem \ --disable-sysvshm \ --disable-wddx \
#46883 [Asn->Csd]: ext/standard/tests/streams/bug46024.phpt hangs
ID: 46883 Updated by: lbarn...@php.net Reported By: long at ku dot edu -Status: Assigned +Status: Closed Bug Type: Streams related Operating System: Solaris 8 PHP Version: 5.2.8 Assigned To: lbarnaud New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Fixed, thanks Previous Comments: [2008-12-18 15:02:53] j...@php.net Arnaud, this test is a bit odd. Why is it reading from writable pipe? ie. shouldn't this: fread($pipes[0], 1); be this: fread($pipes[1], 1); ?? [2008-12-17 16:29:51] long at ku dot edu gdb doesn't want to seem to work with it so I just used dbx to get a backtrace: (/apps/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where [1] _read(0x5, 0x1796f20, 0x2000, 0x1641658, 0x215e4, 0x9acbc0), at 0xfed1ecc0 =>[2] php_stdiop_read(stream = 0x17939a8, buf = 0x1796f20 "", count = 8192U), line 337 in "plain_wrapper.c" [3] php_stream_fill_read_buffer(stream = 0x17939a8, size = 1U), line 556 in "streams.c" [4] _php_stream_read(stream = 0x17939a8, buf = 0x1794730 "ZZx]nDnD\x", size = 1U), line 600 in "streams.c" [5] zif_fread(ht = 2, return_value = 0x17932f0, return_value_ptr = (nil), this_ptr = (nil), return_value_used = 0), line 1873 in "file.c" [6] zend_do_fcall_common_helper_SPEC(execute_data = 0xffbeec48), line 200 in "zend_vm_execute.h" [7] ZEND_DO_FCALL_SPEC_CONST_HANDLER(execute_data = 0xffbeec48), line 1729 in "zend_vm_execute.h" [8] execute(op_array = 0x17926a0), line 92 in "zend_vm_execute.h" [9] zend_execute_scripts(type = 8, retval = (nil), file_count = 3, ...), line 1134 in "zend.c" [10] php_execute_script(primary_file = 0xffbef368), line 2023 in "main.c" [11] main(argc = 74, argv = 0xffbef3fc), line 1133 in "php_cli.c" (/apps/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) [2008-12-16 16:58:18] long at ku dot edu Description: When running 'make test' it is repeatedly freezing on ext/standard/tests/streams/bug46024.phpt. ps shows that no CPU time is being used. Reproduce code: --- Using solaris 8 with cc: Sun WorkShop 6 update 2 C 5.3 2001/05/15 configure using: #! /bin/sh # # Created by configure CFLAGS='-O' \ CC='cc' \ './configure' \ '--enable-discard-path' \ '--with-openssl=shared' \ '--with-zlib=shared' \ '--enable-bcmath' \ '--enable-calendar' \ '--enable-dba=shared' \ '--enable-dbase' \ '--enable-exif' \ '--enable-ftp' \ '--with-gd=shared' \ '--enable-gd-native-ttf' \ '--enable-gd-jis-conv' \ '--with-gettext=shared' \ '--with-kerberos' \ '--with-imap-ssl' \ '--with-ldap' \ '--enable-mbstring' \ '--with-mysql' \ '--with-oci8' \ '--enable-shmop' \ '--enable-sockets' \ '--with-sqlite' \ '--enable-sysvmsg' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--with-freetype-dir' \ '--with-jpeg-dir' \ '--with-mysqli' \ '--with-pdo-mysql' \ '--with-pdo-oci' \ '--enable-cgi' \ '--disable-libxml' \ '--disable-dom' \ '--disable-simplexml' \ '--disable-xmlreader' \ '--disable-xmlwriter' \ '--with-libexpat-dir' \ '--enable-zip' \ '--with-iconv=/usr/local' \ "$@" then make and make test Expected result: I expect the make test to complete its run. Actual result: -- I get something like this: ... PASS Bug MOPB-29 (wrong length calculation for S) [ext/standard/tests/serialize/unserializeS.phpt] PASS Bug #44818 (php://memory writeable when opened read only) [ext/standard/tests/streams/bug44818.phpt] TEST 5082/5818 [ext/standard/tests/streams/bug46024.phpt] and it has been that way for over 12 hours now. -- Edit this bug report at http://bugs.php.net/?id=46883&edit=1
#46885 [Fbk->Csd]: pass by reference does not return object created in function
ID: 46885
User updated by: Chowarmaan at gmail dot com
-Summary: pas by reference does not return object created in
function
Reported By: Chowarmaan at gmail dot com
-Status: Feedback
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.2.8
New Comment:
I retried this as you showed, and then again in my code sample. I can
not reduplicate this problem.
I have been using the 5.2.8 since it came out as it is on my
development machine, and the only PHP on that machine. I confirmed this
with the first test and this test using the php -v and phpinfo();
Originally I noticed the problem using Zend 5.5.1, but I can not
reduplicate the problem there either.
Previous Comments:
[2008-12-18 14:26:00] j...@php.net
Are you really using PHP 5.2.8? Because this works just fine for me
with both styles. Here's my simplified script:
set('Testing Complete');
}
}
class tst2
{
public $var;
public function set($s)
{
$this->var = $s;
}
}
$t = new tst;
$t->get($resp, 100);
var_dump($resp->var);
$t->get(&$resp, 100);
var_dump($resp->var);
?>
And output:
# php -dallow_call_time_pass_reference=on t.php
string(16) "Testing Complete"
string(16) "Testing Complete"
# php -dallow_call_time_pass_reference=off t.php
Warning: Call-time pass-by-reference has been deprecated in t.php on
line 25
string(16) "Testing Complete"
string(16) "Testing Complete"
[2008-12-17 23:14:39] Chowarmaan at gmail dot com
Both lines were added to show what works and what does not. The first
call is the desired call by the program and what I can see in the PHP
manual. However, $Response does not become an object of TEST_CLASS2
when the GetResponse function ends.
The second call, &$Response does maintain the TEST_CLASS2 object type.
The second line should not be in the script, it is just there to
illustrate the problem. The first call to GetResponse() is the correct
call by the language syntax, but it has the bug.
[2008-12-17 02:44:50] j...@php.net
How about you comment out the latter call and let the script work
like it does?
[2008-12-16 21:26:23] Chowarmaan at gmail dot com
Description:
Calling a function in a class that accepts a variable by reference,
then checks the variable and creates an object for it will not allow the
object to be returned outside of the function.
Reproduce code:
---
SetText_('Testing Complete');
return TRUE;
}
}
class TEST_CLASS2
{
public $Variable;
public function SetText_($s)
{
$this->Variable = $s;
}
}
$Test = new TEST_CLASS();
$Test->GetResponse($Response, 100); // Fails
$Test->GetResponse(&$Response, 100); // Works
echo $Response->Variable . "\n";
?>
Expected result:
$Response should be of type TEST_CLASS2 and the echo should return the
text:
Testing Complete
Actual result:
--
$Response is a NULL
--
Edit this bug report at http://bugs.php.net/?id=46885&edit=1
#46858 [Opn->Fbk]: Incorrect isset result on MySQLi_Result properties
ID: 46858
Updated by: j...@php.net
Reported By: eric at livejorunal dot dk
-Status: Open
+Status: Feedback
Bug Type: MySQLi related
Operating System: Linux
PHP Version: 5.2.8
New Comment:
Why do you test if that property exists anyway? It's always there, you
don't need to test for that. :)
Previous Comments:
[2008-12-13 16:46:02] eric at livejorunal dot dk
Description:
isset returns false when applied to a MySQLi_result object that does
indeed exist.
Reproduce code:
---
query('SELECT * FROM test;'); //contains 1 row
echo $result->num_rows;
if (isset($result->num_rows))
echo 'defined';
else
echo 'undefined';
?>
Expected result:
1defined
Actual result:
--
1undefined
--
Edit this bug report at http://bugs.php.net/?id=46858&edit=1
#46600 [Ver->Fbk]: "_empty_" key in objects (see #41504)
ID: 46600
Updated by: scott...@php.net
Reported By: Matt at mpcm dot com
-Status: Verified
+Status: Feedback
Bug Type: JSON related
Operating System: *
PHP Version: 5CVS, 6CVS (2008-11-18)
Previous Comments:
[2008-12-18 03:27:25] scott...@php.net
I'm not even sure what the bug is? You can't have an empty property
name hence the use of "_empty_".
The key collision thing is a very edge case, are you saying you ran
into this in a real life usage?
The best course of action may be to have this documented on the
json_encode() and json_decode() pages.
[2008-12-04 20:39:13] Matt at mpcm dot com
Thanx for the reply magicaltux, `Feature` is an interesting word
considering the possible key collision.
There are other ways to get things that are not strictly objects to
behave that way. Overloading (like example #1 at
http://us.php.net/manual/en/language.oop5.overloading.php). It works
well enough as long as you also make it iterate correctly.
What I am suggesting is that it is better to fail in decoding into an
object, than to silently cause a key collision.
Or alternatively, produce an overloaded object which can have these
keys (by default, or passed optional flag) from json_decode. It's an
opinion, but a wrapper gets me where I need to be for now, and I'm
pretty sure this is an edge case.
$a = '{"":"a","_empty_":"b"}';
echo json_encode(json_decode($a));
echo json_encode(json_decode($a, true));
output:
{"_empty_":"b"}
{"":"a","_empty_":"b"}
for some values:
$a != json_encode(json_decode($a));
[2008-12-04 10:44:29] magical...@php.net
I believe this is not a bug, but a feature.
An object *can't* have an empty property (while an array can).
If you want to use json_decode() with json containing empty key, either
access those empty key using special keyword "_empty_", or put the
optionnal $assoc parameter of json_decode() to true to get result as an
array.
If you want objects to support empty keys, I believe this is not going
to happen soon, as this is enforced by a specific error message.
Fatal error: Cannot access empty property in php shell code on line 1
Please note that a property name starting with NULL character won't
work either.
[2008-11-18 17:35:30] matt at mpcm dot com
The language seems to create a key that cannot be reached, so even if
this `bug` is fixed, we am still facing a broader issue it seems.
4,"example"=>8);
var_dump($o);
print 'blank key test:' . (isset($o->$key)?'true':'false');
print $o->{$key};
var_dump($o->$key);
?>
output:
object(stdClass)#1 (2) {
[""]=>
int(4)
["example"]=>
int(8)
}
blank key test:false
Fatal error: Cannot access empty property in
PHPDocument1 on line 8
All throws Notice: line 4 - Illegal member variable name
[2008-11-18 15:43:05] matt at mpcm dot com
All the work arounds I am looking at are throwing Error Text: Illegal
member variable name when I convert/cast an object with a blank
property.
Is this json_decode `bug` a result of a larger object mechanism
limitation inside of php's object handling?
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/46600
--
Edit this bug report at http://bugs.php.net/?id=46600&edit=1
#46862 [Opn->Fbk]: Upload and post limits
ID: 46862 Updated by: j...@php.net Reported By: alp3r at msn dot com -Status: Open +Status: Feedback Bug Type: PHP options/info functions Operating System: CENTOS Enterprise 4.7 i686 PHP Version: 5.2.8 New Comment: Delete the whole php.ini file, copy one from the distribution package (either php.ini-dist or php.ini-recommended to php.ini) and change the values again. And double check ALL .htaccess files and httpd.conf (and includes in it!) for any php_* settings. I can not reproduce this with clean and properly installed system. Previous Comments: [2008-12-17 12:29:59] alp3r at msn dot com Lines are: "post_max_size = 100M upload_max_filesize = 100M memory_limit = 100M" in php.ini. ///\\\ Yes, i'm running on Apache. Version is: Apache Version Apache/2.2.10 (Unix) mod_ssl/2.2.10 OpenSSL/0.9.7a mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 PHP/5.2.8 Apache API Version 20051115 ///\\\ There are no php_value or flag in .htaccess or httpd.conf. I'm creating a new host account (normally new .htaccess file), and trying to get phpinfo() in new account, the result is same as the others. I think, it's not a .htaccess problem. [2008-12-17 11:45:26] j...@php.net What _exactly_ are the lines defining those directives in that ini file? Are you running under Apache? Are there any php_value / php_flag or such in either httpd.conf or in _any_ .htaccess file in your system? [2008-12-17 09:06:40] alp3r at msn dot com I checked it; it's "/usr/local/lib/php.ini". Anyway, i've already worked on this file. The problem is not this. [2008-12-16 18:08:49] j...@php.net First of all, check in phpinfo() output that the correct php.ini file is loaded (if any!). This information can be found in the very first lines in the output: "Loaded Configuration File" [2008-12-14 13:44:06] alp3r at msn dot com Description: I changed my dedicated server. In the old one, php version was 5.2.5 and the new one, it's 5.2.8. I had to change the php.ini (/usr/local/lib/php.ini) file. I change safe mode to on from off, memory limit to 100M, post_max_size to 100M from 8M, upload_max_filesize to 100M from 2M. And i restarted the apache. And then, when i look to phpinfo, i saw it look like this; safe mode = on. (It's ok.) memory limit = 100M. (It's ok.) post_max_size = 8M (It's wrong! I changed it to 100M) upload_max_filesize = 2M (It's wrong! I changed it to 100M too) Is there any bug about php 5.2.8? Or how can i fix this problem? -- Edit this bug report at http://bugs.php.net/?id=46862&edit=1
#46883 [Opn->Asn]: ext/standard/tests/streams/bug46024.phpt hangs
ID: 46883 Updated by: j...@php.net Reported By: long at ku dot edu -Status: Open +Status: Assigned Bug Type: Streams related Operating System: Solaris 8 PHP Version: 5.2.8 -Assigned To: +Assigned To: lbarnaud New Comment: Arnaud, this test is a bit odd. Why is it reading from writable pipe? ie. shouldn't this: fread($pipes[0], 1); be this: fread($pipes[1], 1); ?? Previous Comments: [2008-12-17 16:29:51] long at ku dot edu gdb doesn't want to seem to work with it so I just used dbx to get a backtrace: (/apps/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where [1] _read(0x5, 0x1796f20, 0x2000, 0x1641658, 0x215e4, 0x9acbc0), at 0xfed1ecc0 =>[2] php_stdiop_read(stream = 0x17939a8, buf = 0x1796f20 "", count = 8192U), line 337 in "plain_wrapper.c" [3] php_stream_fill_read_buffer(stream = 0x17939a8, size = 1U), line 556 in "streams.c" [4] _php_stream_read(stream = 0x17939a8, buf = 0x1794730 "ZZx]nDnD\x", size = 1U), line 600 in "streams.c" [5] zif_fread(ht = 2, return_value = 0x17932f0, return_value_ptr = (nil), this_ptr = (nil), return_value_used = 0), line 1873 in "file.c" [6] zend_do_fcall_common_helper_SPEC(execute_data = 0xffbeec48), line 200 in "zend_vm_execute.h" [7] ZEND_DO_FCALL_SPEC_CONST_HANDLER(execute_data = 0xffbeec48), line 1729 in "zend_vm_execute.h" [8] execute(op_array = 0x17926a0), line 92 in "zend_vm_execute.h" [9] zend_execute_scripts(type = 8, retval = (nil), file_count = 3, ...), line 1134 in "zend.c" [10] php_execute_script(primary_file = 0xffbef368), line 2023 in "main.c" [11] main(argc = 74, argv = 0xffbef3fc), line 1133 in "php_cli.c" (/apps/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) [2008-12-16 16:58:18] long at ku dot edu Description: When running 'make test' it is repeatedly freezing on ext/standard/tests/streams/bug46024.phpt. ps shows that no CPU time is being used. Reproduce code: --- Using solaris 8 with cc: Sun WorkShop 6 update 2 C 5.3 2001/05/15 configure using: #! /bin/sh # # Created by configure CFLAGS='-O' \ CC='cc' \ './configure' \ '--enable-discard-path' \ '--with-openssl=shared' \ '--with-zlib=shared' \ '--enable-bcmath' \ '--enable-calendar' \ '--enable-dba=shared' \ '--enable-dbase' \ '--enable-exif' \ '--enable-ftp' \ '--with-gd=shared' \ '--enable-gd-native-ttf' \ '--enable-gd-jis-conv' \ '--with-gettext=shared' \ '--with-kerberos' \ '--with-imap-ssl' \ '--with-ldap' \ '--enable-mbstring' \ '--with-mysql' \ '--with-oci8' \ '--enable-shmop' \ '--enable-sockets' \ '--with-sqlite' \ '--enable-sysvmsg' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--with-freetype-dir' \ '--with-jpeg-dir' \ '--with-mysqli' \ '--with-pdo-mysql' \ '--with-pdo-oci' \ '--enable-cgi' \ '--disable-libxml' \ '--disable-dom' \ '--disable-simplexml' \ '--disable-xmlreader' \ '--disable-xmlwriter' \ '--with-libexpat-dir' \ '--enable-zip' \ '--with-iconv=/usr/local' \ "$@" then make and make test Expected result: I expect the make test to complete its run. Actual result: -- I get something like this: ... PASS Bug MOPB-29 (wrong length calculation for S) [ext/standard/tests/serialize/unserializeS.phpt] PASS Bug #44818 (php://memory writeable when opened read only) [ext/standard/tests/streams/bug44818.phpt] TEST 5082/5818 [ext/standard/tests/streams/bug46024.phpt] and it has been that way for over 12 hours now. -- Edit this bug report at http://bugs.php.net/?id=46883&edit=1
#46075 [Fbk->Opn]: repeated calls of strftime() consumes memory
ID: 46075 Updated by: paj...@php.net Reported By: acc_php at riggers dot me dot uk -Status: Feedback +Status: Open Bug Type: Date/time related Operating System: win32 only PHP Version: 5.2CVS-2008-09-15 Assigned To: pajoye New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2008-12-18 14:57:55] paj...@php.net please try the next 5.3/HEAD snapshots (could be related to #46889). [2008-09-15 19:10:39] acc_php at riggers dot me dot uk Same problem I'm afraid: C:\php-latest>php.exe C:\php-gtk2\andy\symftest\strftime.test.php === strftime() === Start: 59072 End: 124488 === date() === Start: 124488 End: 124456 C:\php-latest>php -v PHP 5.2.7-dev (cli) (built: Aug 6 2008 03:00:55) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies [2008-09-14 12:12:14] acc_php at riggers dot me dot uk Description: strftime() called many times results in increasing memory usage. date() is OK. This is on Vista x64. PHP 5.1.6 (only version i have at the moment) on linux does not exhibit the same problem. Reproduce code: --- Expected result: End memory usage for strftime() should be close to Start memory usage. Actual result: -- C:\php-gtk2>php andy\symftest\strftime.test.php === strftime() === Start: 54384 End: 119800 === date() === Start: 119800 End: 119768 C:\php-gtk2>php -v PHP 5.2.6 (cli) (built: May 2 2008 19:37:32) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies C:\php-gtk2> -- Edit this bug report at http://bugs.php.net/?id=46075&edit=1
#46075 [Asn->Fbk]: repeated calls of strftime() consumes memory
ID: 46075 Updated by: paj...@php.net Reported By: acc_php at riggers dot me dot uk -Status: Assigned +Status: Feedback Bug Type: Date/time related Operating System: win32 only PHP Version: 5.2CVS-2008-09-15 Assigned To: pajoye New Comment: please try the next 5.3/HEAD snapshots (could be related to #46889). Previous Comments: [2008-09-15 19:10:39] acc_php at riggers dot me dot uk Same problem I'm afraid: C:\php-latest>php.exe C:\php-gtk2\andy\symftest\strftime.test.php === strftime() === Start: 59072 End: 124488 === date() === Start: 124488 End: 124456 C:\php-latest>php -v PHP 5.2.7-dev (cli) (built: Aug 6 2008 03:00:55) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies [2008-09-14 12:12:14] acc_php at riggers dot me dot uk Description: strftime() called many times results in increasing memory usage. date() is OK. This is on Vista x64. PHP 5.1.6 (only version i have at the moment) on linux does not exhibit the same problem. Reproduce code: --- Expected result: End memory usage for strftime() should be close to Start memory usage. Actual result: -- C:\php-gtk2>php andy\symftest\strftime.test.php === strftime() === Start: 54384 End: 119800 === date() === Start: 119800 End: 119768 C:\php-gtk2>php -v PHP 5.2.6 (cli) (built: May 2 2008 19:37:32) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies C:\php-gtk2> -- Edit this bug report at http://bugs.php.net/?id=46075&edit=1
#46889 [Asn->Csd]: Memory leak in strtotime()
ID: 46889 Updated by: der...@php.net Reported By: tim at digicol dot de -Status: Assigned +Status: Closed Bug Type: Date/time related Operating System: * PHP Version: 5.2.8 Assigned To: derick New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2008-12-18 11:12:33] martin at 925 dot dk Reproduced here. OS: FreeBSD 7.0-RELEASE-p4 FreeBSD 7.0-RELEASE-p4 PHP: PHP 5.2.8 (cli) (built: Dec 8 2008 19:11:49) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies [2008-12-17 15:11:48] tim at digicol dot de Description: With PHP 5.2.8, strtotime() on my Linux box leaks memory; we've noticed it because we're using long-running scripts with the PHP CLI. In our case, the PHP processes grew to hundreds of MB RAM usage within minutes. This is not the case with PHP 5.2.6. The funny thing is that neither memory_get_usage(false) nor memory_get_usage(true) report the actual memory usage; here's a line from top: 22728 digicol 25 0 258m 218m 6928 R 75.4 43.4 0:42.91 php ... while the PHP functions report at the same time: memory_get_usage(false): 1738020 memory_get_usage(true): 1835008 What's also funny is that the default "memory_limit = 128M" setting doesn't help: PHP doesn't notice that this much RAM is being used and so doesn't kill the script. (But I can trigger the memory limit as usual with other PHP scripts, so PHP's memory limit isn't entirely broken.) I tested with an unchanged copy of php.ini-recommended. My configure string: './configure' '--with-apxs2=/usr/bin/apxs2' '--enable-exif' '-- enable-ftp' '--enable-mbregex' '--enable-mbstring=all' '--enable- pcntl' '--enable-soap' '--enable-zip' '--with-zlib' '--with-curl' '-- with-freetype-dir=/usr' '--with-gd' '--with-jpeg-dir=/usr' '--with- ldap' '--with-mysqli' '--with- oci8=instantclient,/usr/local/lib/instantclient' '--enable-sigchild' '--with-png-dir=/usr' '--with-xsl' '--with-mcrypt' This is Debian Linux 4.0, running in VMware Fusion on an Intel Mac. Thanks a lot for looking into this, and for the great work on PHP! Reproduce code: --- Expected result: No increase in memory usage. Actual result: -- Memory usage is increasing dramatically - on my box, the process is growing by 100 MB per second... -- Edit this bug report at http://bugs.php.net/?id=46889&edit=1
#46902 [Opn->Bgs]: IMAP functions return NULL in PHP53, false in PHP52
ID: 46902 Updated by: j...@php.net Reported By: z...@php.net -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Any PHP Version: 5.3.0alpha3 New Comment: New paremeter parsing api does that. And IIRC, that's defacto standard now. Previous Comments: [2008-12-18 14:39:25] z...@php.net Description: The imap functions in ext/imap/php_imap.c all return NULL on failure of zend_parse_parameters() rather than bool(false). In PHP52 the same functions return 'false' when parameter parsing fails. Patches here: http://pastebin.ca/1288616 http://pastebin.ca/1288620 Reproduce code: --- http://pastebin.ca/1288610 Expected result: See expected result in test case Actual result: -- NULL in test output where bool(false) is expected -- Edit this bug report at http://bugs.php.net/?id=46902&edit=1
#46903 [NEW]: ob_start(): Special $chunk_size value of 1 is not honoured in HEAD
From: robin_fernandes at uk dot ibm dot com
Operating system:
PHP version: 6CVS-2008-12-18 (snap)
PHP Bug Type: Output Control
Bug description: ob_start(): Special $chunk_size value of 1 is not honoured in
HEAD
Description:
The doc for ob_start() states:
"If the optional parameter chunk_size is passed, the buffer will be
flushed after any output call which causes the buffer's length to equal or
exceed chunk_size . Default value 0 means that the function is called only
in the end, other special value 1 sets chunk_size to 4096."
In HEAD, setting $chunk_size=1 actually does set the buffer threshold size
to 1 byte, rather than 4096 bytes as on 5_* and as documented.
Here's a simple patch for HEAD to restore the documented behaviour:
Index: output.c
===
RCS file: /repository/php-src/main/output.c,v
retrieving revision 1.214
diff -u -w -p -r1.214 output.c
--- output.c18 Aug 2008 07:45:59 - 1.214
+++ output.c18 Dec 2008 14:23:10 -
@@ -1342,6 +1342,8 @@ PHP_FUNCTION(ob_start)
}
if (chunk_size < 0) {
chunk_size = 0;
+ } else if (chunk_size == 1) {
+ chunk_size = 4096;
}
if (SUCCESS != php_output_start_user(output_handler, chunk_size, flags
TSRMLS_CC)) {
Reproduce code:
---
1, these two chars should
// come out as part of a single flush:
echo "1";
echo "2";
?>
Expected result:
[1] int(4096)
12
Actual result:
--
[1] int(1)
[2] 1
[3] 2
[4]
--
Edit bug report at http://bugs.php.net/?id=46903&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46903&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46903&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46903&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46903&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46903&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46903&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46903&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46903&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46903&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46903&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46903&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46903&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46903&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46903&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46903&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46903&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46903&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46903&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46903&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46903&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46903&r=mysqlcfg
#46902 [NEW]: IMAP functions return NULL in PHP53, false in PHP52
From: z...@php.net Operating system: Any PHP version: 5.3.0alpha3 PHP Bug Type: Scripting Engine problem Bug description: IMAP functions return NULL in PHP53, false in PHP52 Description: The imap functions in ext/imap/php_imap.c all return NULL on failure of zend_parse_parameters() rather than bool(false). In PHP52 the same functions return 'false' when parameter parsing fails. Patches here: http://pastebin.ca/1288616 http://pastebin.ca/1288620 Reproduce code: --- http://pastebin.ca/1288610 Expected result: See expected result in test case Actual result: -- NULL in test output where bool(false) is expected -- Edit bug report at http://bugs.php.net/?id=46902&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46902&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46902&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46902&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46902&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46902&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46902&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46902&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46902&r=needscript Try newer version: http://bugs.php.net/fix.php?id=46902&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46902&r=support Expected behavior: http://bugs.php.net/fix.php?id=46902&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46902&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46902&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46902&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46902&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46902&r=dst IIS Stability: http://bugs.php.net/fix.php?id=46902&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46902&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46902&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46902&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46902&r=mysqlcfg
#46005 [Csd]: [PATCH] User not consistently logged under Apache2
ID: 46005 Updated by: j...@php.net Reported By: admorten at umich dot edu Status: Closed Bug Type: Apache2 related Operating System: Linux 2.6.21.3 PHP Version: 5.2.6 New Comment: And now also in PHP_5_2 branch. :) Previous Comments: [2008-12-17 11:35:01] s...@php.net This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. applied to 5.3+, thanks [2008-12-17 11:09:02] s...@php.net It should definitely be estrdup, since SAPI.c uses efree to free it. [2008-11-06 18:57:05] admorten at umich dot edu Do you have a backtrace? [2008-11-05 10:16:01] k at kelvinlim dot com I encountered this bug as well, as our Apache configuration uses a custom single sign-on authentication module. admorten's patches successfully resolved the issue--but only after I switched back to the use of estrdup. apr_pstrdup does *not* work; instead, it causes my Apache processes (prefork MPM) to segfault. [2008-10-10 15:52:32] admorten at umich dot edu I've updated both patches to use apr_pstrdup instead of estrdup when copying r->user into SG(request_info).auth_user, which is how the rest of the request info is copied. URLs are still the same. 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/46005 -- Edit this bug report at http://bugs.php.net/?id=46005&edit=1
#46901 [Opn->Bgs]: ip2long() giving negative results
ID: 46901
Updated by: j...@php.net
Reported By: pedro at boxwg dot info
-Status: Open
+Status: Bogus
Bug Type: PHP options/info functions
Operating System: Linux
PHP Version: 5.2.8
New Comment:
Expected behaviour. To make it portable:
# php -r 'echo printf("%u", ip2long("161.51.11.2"));
270447693010
Previous Comments:
[2008-12-18 14:20:38] pedro at boxwg dot info
Description:
Just bumped into a somehow weird bug, reported a couple years ago and
it just popped up once again
$ip = "161.51.11.2";
echo(ip2long($ip));
returns -1590490366
--
Edit this bug report at http://bugs.php.net/?id=46901&edit=1
#46885 [Opn->Fbk]: pas by reference does not return object created in function
ID: 46885
Updated by: j...@php.net
Reported By: Chowarmaan at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.2.8
New Comment:
Are you really using PHP 5.2.8? Because this works just fine for me
with both styles. Here's my simplified script:
set('Testing Complete');
}
}
class tst2
{
public $var;
public function set($s)
{
$this->var = $s;
}
}
$t = new tst;
$t->get($resp, 100);
var_dump($resp->var);
$t->get(&$resp, 100);
var_dump($resp->var);
?>
And output:
# php -dallow_call_time_pass_reference=on t.php
string(16) "Testing Complete"
string(16) "Testing Complete"
# php -dallow_call_time_pass_reference=off t.php
Warning: Call-time pass-by-reference has been deprecated in t.php on
line 25
string(16) "Testing Complete"
string(16) "Testing Complete"
Previous Comments:
[2008-12-17 23:14:39] Chowarmaan at gmail dot com
Both lines were added to show what works and what does not. The first
call is the desired call by the program and what I can see in the PHP
manual. However, $Response does not become an object of TEST_CLASS2
when the GetResponse function ends.
The second call, &$Response does maintain the TEST_CLASS2 object type.
The second line should not be in the script, it is just there to
illustrate the problem. The first call to GetResponse() is the correct
call by the language syntax, but it has the bug.
[2008-12-17 02:44:50] j...@php.net
How about you comment out the latter call and let the script work
like it does?
[2008-12-16 21:26:23] Chowarmaan at gmail dot com
Description:
Calling a function in a class that accepts a variable by reference,
then checks the variable and creates an object for it will not allow the
object to be returned outside of the function.
Reproduce code:
---
SetText_('Testing Complete');
return TRUE;
}
}
class TEST_CLASS2
{
public $Variable;
public function SetText_($s)
{
$this->Variable = $s;
}
}
$Test = new TEST_CLASS();
$Test->GetResponse($Response, 100); // Fails
$Test->GetResponse(&$Response, 100); // Works
echo $Response->Variable . "\n";
?>
Expected result:
$Response should be of type TEST_CLASS2 and the echo should return the
text:
Testing Complete
Actual result:
--
$Response is a NULL
--
Edit this bug report at http://bugs.php.net/?id=46885&edit=1
#46901 [NEW]: ip2long() giving negative results
From: pedro at boxwg dot info Operating system: Linux PHP version: 5.2.8 PHP Bug Type: PHP options/info functions Bug description: ip2long() giving negative results Description: Just bumped into a somehow weird bug, reported a couple years ago and it just popped up once again $ip = "161.51.11.2"; echo(ip2long($ip)); returns -1590490366 -- Edit bug report at http://bugs.php.net/?id=46901&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46901&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46901&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46901&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46901&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46901&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46901&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46901&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46901&r=needscript Try newer version: http://bugs.php.net/fix.php?id=46901&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46901&r=support Expected behavior: http://bugs.php.net/fix.php?id=46901&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46901&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46901&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46901&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46901&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46901&r=dst IIS Stability: http://bugs.php.net/fix.php?id=46901&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46901&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46901&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46901&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46901&r=mysqlcfg
#46900 [NEW]: Unexpected behaviour in HEAD when output buffer callback returns null
From: robin_fernandes at uk dot ibm dot com
Operating system: *
PHP version: 6CVS-2008-12-18 (snap)
PHP Bug Type: Output Control
Bug description: Unexpected behaviour in HEAD when output buffer callback
returns null
Description:
In HEAD, the original input is sent to the output when the output buffer
callback returns NULL. The docs for ob_start() only state this should
happen when it returns FALSE - not NULL:
"If output_callback returns FALSE original input is sent to the
browser."
On PHP 5_2 and 5_3, the empty string is sent to the output when the output
buffer callback returns NULL.
If the 5_2 & 5_3 behaviour is correct, here is a patch for HEAD :
Index: output.c
===
RCS file: /repository/php-src/main/output.c,v
retrieving revision 1.214
diff -u -w -p -r1.214 output.c
--- output.c18 Aug 2008 07:45:59 - 1.214
+++ output.c18 Dec 2008 14:08:53 -
@@ -983,7 +983,7 @@ static inline php_output_handler_status_
ZVAL_LONG(ob_mode, (long) context->op);
zend_fcall_info_argn(&handler->func.user->fci
TSRMLS_CC, 2, &ob_data,
&ob_mode);
-#define PHP_OUTPUT_USER_SUCCESS(retval) (retval && (Z_TYPE_P(retval) !=
IS_NULL) && (Z_TYPE_P(retval) != IS_BOOL || Z_BVAL_P(retval)))
+#define PHP_OUTPUT_USER_SUCCESS(retval) (retval && !(Z_TYPE_P(retval) ==
IS_BOOL && Z_BVAL_P(retval)==0))
if (SUCCESS ==
zend_fcall_info_call(&handler->func.user->fci,
&handler->func.user->fcc, &retval, NULL TSRMLS_CC) &&
PHP_OUTPUT_USER_SUCCESS(retval)) {
/* user handler may have returned TRUE */
status = PHP_OUTPUT_HANDLER_NO_DATA;
If HEAD's current behaviour is as intended, the docs should be updated to
describe the new behaviour in PHP6.
Reproduce code:
---
Expected result:
done
Actual result:
--
You shouldn't see this.
done
--
Edit bug report at http://bugs.php.net/?id=46900&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46900&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46900&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46900&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46900&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46900&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46900&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46900&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46900&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46900&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46900&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46900&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46900&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46900&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46900&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46900&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46900&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46900&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46900&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46900&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46900&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46900&r=mysqlcfg
#46897 [Opn]: ob_flush() should fail to flush unerasable buffers
ID: 46897
Updated by: j...@php.net
Reported By: robin_fernandes at uk dot ibm dot com
Status: Open
Bug Type: Output Control
Operating System: *
PHP Version: 5.3CVS-2008-12-18 (snap)
New Comment:
In HEAD there is improved output buffering code. Hence the difference.
And IMO, the proper fix for this is to simply backport the patch. (IIRC
that's already done, just wasn't allowed to be committed to 5.3 for some
stupid reason..)
Previous Comments:
[2008-12-18 12:27:16] robin_fernandes at uk dot ibm dot com
Description:
On 5_2 and 5_3, there is an inconsistency between ob_flush() and
ob_get_flush() when attempting to flush a buffer created with the flag
$erase=false:
- ob_get_flush() raises a notice and does NOT flush the buffer;
- ob_flush() DOES flush the buffer.
Note that on HEAD, both ob_get_flush() and ob_flush() raise a notice
and do NOT flush the buffer.
I think the behaviour in HEAD is correct. Here's a simple patch for 5_3
that resolves the inconsistency and makes it behave more like HEAD:
Index: output.c
===
RCS file: /repository/php-src/main/output.c,v
retrieving revision 1.167.2.3.2.4.2.9
diff -u -w -p -r1.167.2.3.2.4.2.9 output.c
--- output.c18 Aug 2008 07:46:31 - 1.167.2.3.2.4.2.9
+++ output.c18 Dec 2008 11:30:01 -
@@ -774,6 +774,10 @@ PHP_FUNCTION(ob_flush)
php_error_docref("ref.outcontrol" TSRMLS_CC, E_NOTICE,
"failed to flush buffer. No buffer to flush.");
RETURN_FALSE;
}
+ if (OG(ob_nesting_level) && !OG(active_ob_buffer).status &&
!OG(active_ob_buffer).erase) {
+ php_error_docref("ref.outcontrol" TSRMLS_CC, E_NOTICE,
"failed to flush buffer %s", OG(active_ob_buffer).handler_name);
+ RETURN_FALSE;
+ }
php_end_ob_buffer(1, 1 TSRMLS_CC);
RETURN_TRUE;
More generally, the behaviour of output buffering functions when
dealing with unerasable buffers could benefit from better docs. I will
raise a separate doc bug with some suggestions.
Reproduce code:
---
Expected result:
[callback:1]Attempt to flush unerasable buffer - should fail...
Notice: ob_flush(): failed to flush buffer callback in %s on line 11
bool(false)
string(%d) "Attempt to flush unerasable buffer - should fail...
Notice: ob_flush(): failed to flush buffer callback in %s on line 11
bool(false)
"
Actual result:
--
[callback:1]Attempt to flush unerasable buffer - should fail...
[callback:2]bool(true)
string(11) "bool(true)
"
--
Edit this bug report at http://bugs.php.net/?id=46897&edit=1
#46893 [Com]: extract($foo) crashes if $foo['foo'] exists
ID: 46893 Comment by: crrodriguez at opensuse dot org Reported By: steffen dot weber at gmail dot com Status: Verified Bug Type: Reproducible crash Operating System: * PHP Version: 5CVS, 6CVS (2008-12-18) New Comment: Related to/Duplicated of Bug #46873 ? Previous Comments: [2008-12-18 12:25:40] j...@php.net It fails "silently" because it crashes. :) #0 0x083437ad in _zend_is_inconsistent (ht=0x1, file=0x85ffca4 "/home/jani/src/php-5.2/Zend/zend_hash.c", line=1083) at /home/jani/src/php-5.2/Zend/zend_hash.c:53 #1 0x083465be in zend_hash_move_forward_ex (ht=0x1, pos=0xbfffcd98) at /home/jani/src/php-5.2/Zend/zend_hash.c:1083 #2 0x082435a0 in zif_extract (ht=1, return_value=0x86e16f8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /home/jani/src/php-5.2/ext/standard/array.c:1491 #3 0x0835e8bf in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffcfa8) at /home/jani/src/php-5.2/Zend/zend_vm_execute.h:200 #4 0x083641f9 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xbfffcfa8) at /home/jani/src/php-5.2/Zend/zend_vm_execute.h:1729 #5 0x0835e43c in execute (op_array=0x86e1088) at /home/jani/src/php-5.2/Zend/zend_vm_execute.h:92 #6 0x083397aa in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/jani/src/php-5.2/Zend/zend.c:1134 #7 0x082e831a in php_execute_script (primary_file=0xb324) at /home/jani/src/php-5.2/main/main.c:2023 #8 0x083b4bc9 in main (argc=2, argv=0xb464) at /home/jani/src/php-5.2/sapi/cli/php_cli.c:1133 [2008-12-17 23:06:57] steffen dot weber at gmail dot com Description: Execute the following script and observe that $bar is set to a random integer (*). Furthermore $test is not set at all. This problem did not occur with PHP 5.2.6. (*) Could this have security implications? Reproduce code: --- 1, 'bar' => 2, 'test' => 3); extract($foo); var_dump($foo, $bar, $test); ?> Expected result: int(1) int(2) int(3) Actual result: -- Notice: Undefined variable: test in extract-bug.php on line 4 int(1) int(RANDOM_NUMBER) NULL -- Edit this bug report at http://bugs.php.net/?id=46893&edit=1
#46899 [Com]: Typed function arguments should allow nulls
ID: 46899
Comment by: zyss at mail dot zp dot ua
Reported By: zyss at mail dot zp dot ua
Status: Open
Bug Type: Feature/Change Request
Operating System: Irrelevant
PHP Version: 5.2.8
New Comment:
Example in more readable form:
class ExElement extends Exception { };
class Element {
// each element references document for fast access
protected /* Document */ $document;
protected /* Element */ $parent;
function __construct(
Document $document,
Element $parent = null) /* throws ExElement */
{
// is still checked to be valid Document object reference
$this->document = $document;
if ($parent && ($parent->getDocument() != $document))
throw new ExElement("Parent's document doesn't match " .
"Element constructor's argument", 1);
$this->parent = $parent;
}
function getDocument() {
return $this->document;
}
}
Previous Comments:
[2008-12-18 13:33:55] zyss at mail dot zp dot ua
Description:
Currently class type can be specified as function argument type, but it
is frequently required to pass null instead of object reference when
there is a default argument value set and it is null. In the following
example constructor's $parent argument can be null for the top-level
objects, but current PHP version doesn't allow it to be null forcing to
remove type declaration that is very undesirable:
class ExElement extends Exception { };
class Element {
protected /* Document */ $document; // each element references
document for fast access
protected /* Element */ $parent;
function __construct(Document $document, Element $parent = null) /*
throws ExElement */ {
$this->document = $document; // is still checked by PHP to be
valid Document object reference
if ($parent && ($parent->getDocument() != $document))
throw new ExElement("Parent's document doesn't match Element
constructor's argument", 1);
$this->parent = $parent;
}
function getDocument() {
return $this->document;
}
}
--
Edit this bug report at http://bugs.php.net/?id=46899&edit=1
#46899 [NEW]: Typed function arguments should allow nulls
From: zyss at mail dot zp dot ua
Operating system: Irrelevant
PHP version: 5.2.8
PHP Bug Type: Feature/Change Request
Bug description: Typed function arguments should allow nulls
Description:
Currently class type can be specified as function argument type, but it is
frequently required to pass null instead of object reference when there is
a default argument value set and it is null. In the following example
constructor's $parent argument can be null for the top-level objects, but
current PHP version doesn't allow it to be null forcing to remove type
declaration that is very undesirable:
class ExElement extends Exception { };
class Element {
protected /* Document */ $document; // each element references
document for fast access
protected /* Element */ $parent;
function __construct(Document $document, Element $parent = null) /*
throws ExElement */ {
$this->document = $document; // is still checked by PHP to be valid
Document object reference
if ($parent && ($parent->getDocument() != $document))
throw new ExElement("Parent's document doesn't match Element
constructor's argument", 1);
$this->parent = $parent;
}
function getDocument() {
return $this->document;
}
}
--
Edit bug report at http://bugs.php.net/?id=46899&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46899&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46899&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46899&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46899&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46899&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46899&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46899&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46899&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46899&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46899&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46899&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46899&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46899&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46899&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46899&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46899&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46899&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46899&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46899&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46899&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46899&r=mysqlcfg
#46866 [Bgs]: xml_parse now ignoring html entities in the xml
ID: 46866 User updated by: bill at billjill dot org Reported By: bill at billjill dot org Status: Bogus Bug Type: *XML functions Operating System: Linux PHP Version: 5.2.8 New Comment: My apologies. Many thanks for pointing me toward the correct bug report. Previous Comments: [2008-12-16 14:20:28] rricha...@php.net Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. Dupe of bug #45996 [2008-12-15 03:57:35] bill at billjill dot org Description: Under 5.2.6 and earlier version, the xml parser would correctly read in html entities (such as <) in the XML. In 5.2.8, these entities are being ignored Reproduce code: --- You can see the source for a simple test program here: http://outofthebloo.com/test/xmlparsertest.php.txt Expected result: Do a View Source on the result of the xmlparsertest.php program, and you should see this (see the portion toward the bottom near "This should be bold") Array ( [0] => Array ( [name] => OVERLAYS [attrs] => Array ( ) [children] => Array ( [0] => Array ( [name] => OVERLAY [attrs] => Array ( ) [children] => Array ( [0] => Array ( [name] => NAME [attrs] => Array ( ) [tagData] => Test ) [1] => Array ( [name] => TYPE [attrs] => Array ( ) [tagData] => template ) [2] => Array ( [name] => SYNTAX [attrs] => Array ( ) [tagData] => This should be bold ) ) ) ) ) ) Actual result: -- Here's the actual result. NOTE that the "<" and ">" tag characters are missing near the "This should be bold" text: Array ( [0] => Array ( [name] => OVERLAYS [attrs] => Array ( ) [children] => Array ( [0] => Array ( [name] => OVERLAY [attrs] => Array ( ) [children] => Array ( [0] => Array ( [name] => NAME [attrs] => Array ( ) [tagData] => Test ) [1] => Array ( [name] => TYPE [attrs] => Array ( ) [tagData] => template ) [2] => Array ( [name] => SYNTAX [attrs] => Array ( )
#46897 [NEW]: ob_flush() should fail to flush unerasable buffers
From: robin_fernandes at uk dot ibm dot com
Operating system: *
PHP version: 5.3CVS-2008-12-18 (snap)
PHP Bug Type: Output Control
Bug description: ob_flush() should fail to flush unerasable buffers
Description:
On 5_2 and 5_3, there is an inconsistency between ob_flush() and
ob_get_flush() when attempting to flush a buffer created with the flag
$erase=false:
- ob_get_flush() raises a notice and does NOT flush the buffer;
- ob_flush() DOES flush the buffer.
Note that on HEAD, both ob_get_flush() and ob_flush() raise a notice and
do NOT flush the buffer.
I think the behaviour in HEAD is correct. Here's a simple patch for 5_3
that resolves the inconsistency and makes it behave more like HEAD:
Index: output.c
===
RCS file: /repository/php-src/main/output.c,v
retrieving revision 1.167.2.3.2.4.2.9
diff -u -w -p -r1.167.2.3.2.4.2.9 output.c
--- output.c18 Aug 2008 07:46:31 - 1.167.2.3.2.4.2.9
+++ output.c18 Dec 2008 11:30:01 -
@@ -774,6 +774,10 @@ PHP_FUNCTION(ob_flush)
php_error_docref("ref.outcontrol" TSRMLS_CC, E_NOTICE,
"failed to flush buffer. No buffer to flush.");
RETURN_FALSE;
}
+ if (OG(ob_nesting_level) && !OG(active_ob_buffer).status &&
!OG(active_ob_buffer).erase) {
+ php_error_docref("ref.outcontrol" TSRMLS_CC, E_NOTICE,
"failed to flush buffer %s", OG(active_ob_buffer).handler_name);
+ RETURN_FALSE;
+ }
php_end_ob_buffer(1, 1 TSRMLS_CC);
RETURN_TRUE;
More generally, the behaviour of output buffering functions when dealing
with unerasable buffers could benefit from better docs. I will raise a
separate doc bug with some suggestions.
Reproduce code:
---
Expected result:
[callback:1]Attempt to flush unerasable buffer - should fail...
Notice: ob_flush(): failed to flush buffer callback in %s on line 11
bool(false)
string(%d) "Attempt to flush unerasable buffer - should fail...
Notice: ob_flush(): failed to flush buffer callback in %s on line 11
bool(false)
"
Actual result:
--
[callback:1]Attempt to flush unerasable buffer - should fail...
[callback:2]bool(true)
string(11) "bool(true)
"
--
Edit bug report at http://bugs.php.net/?id=46897&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46897&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46897&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46897&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46897&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46897&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46897&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46897&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46897&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46897&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46897&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46897&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46897&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46897&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46897&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46897&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46897&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46897&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46897&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46897&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46897&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46897&r=mysqlcfg
#46893 [Opn->Ver]: extract($foo) crashes if $foo['foo'] exists
ID: 46893 Updated by: j...@php.net -Summary: extract($foo) fails silently if $foo['foo'] exists Reported By: steffen dot weber at gmail dot com -Status: Open +Status: Verified -Bug Type: Arrays related +Bug Type: Reproducible crash -Operating System: Gentoo Linux x86_64 +Operating System: * -PHP Version: 5.2.8 +PHP Version: 5CVS, 6CVS (2008-12-18) New Comment: It fails "silently" because it crashes. :) #0 0x083437ad in _zend_is_inconsistent (ht=0x1, file=0x85ffca4 "/home/jani/src/php-5.2/Zend/zend_hash.c", line=1083) at /home/jani/src/php-5.2/Zend/zend_hash.c:53 #1 0x083465be in zend_hash_move_forward_ex (ht=0x1, pos=0xbfffcd98) at /home/jani/src/php-5.2/Zend/zend_hash.c:1083 #2 0x082435a0 in zif_extract (ht=1, return_value=0x86e16f8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /home/jani/src/php-5.2/ext/standard/array.c:1491 #3 0x0835e8bf in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffcfa8) at /home/jani/src/php-5.2/Zend/zend_vm_execute.h:200 #4 0x083641f9 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xbfffcfa8) at /home/jani/src/php-5.2/Zend/zend_vm_execute.h:1729 #5 0x0835e43c in execute (op_array=0x86e1088) at /home/jani/src/php-5.2/Zend/zend_vm_execute.h:92 #6 0x083397aa in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/jani/src/php-5.2/Zend/zend.c:1134 #7 0x082e831a in php_execute_script (primary_file=0xb324) at /home/jani/src/php-5.2/main/main.c:2023 #8 0x083b4bc9 in main (argc=2, argv=0xb464) at /home/jani/src/php-5.2/sapi/cli/php_cli.c:1133 Previous Comments: [2008-12-17 23:06:57] steffen dot weber at gmail dot com Description: Execute the following script and observe that $bar is set to a random integer (*). Furthermore $test is not set at all. This problem did not occur with PHP 5.2.6. (*) Could this have security implications? Reproduce code: --- 1, 'bar' => 2, 'test' => 3); extract($foo); var_dump($foo, $bar, $test); ?> Expected result: int(1) int(2) int(3) Actual result: -- Notice: Undefined variable: test in extract-bug.php on line 4 int(1) int(RANDOM_NUMBER) NULL -- Edit this bug report at http://bugs.php.net/?id=46893&edit=1
#32288 [Opn->Csd]: fopen(ftp://...) request file SIZE
ID: 32288
User updated by: romaneos at gmail dot com
Reported By: romaneos at gmail dot com
-Status: Open
+Status: Closed
Bug Type: Feature/Change Request
Operating System: Win 2000
PHP Version: 4.3.8
New Comment:
a
Previous Comments:
[2005-03-13 04:36:25] romaneos at gmail dot com
Description:
When I using fopen(ftp://...) my FTP-server show that this function
request file size:
5:09:18 - anonymous 172.31.8.72 > SIZE /Pictures/image.jpg
5:09:18 - anonymous 172.31.8.72 > 213 122387
but as I know fstat() could'n return FileSize for FTP
Reproduce code:
---
$fp =
fopen("ftp://".$ftp_server_user.":".urlencode($ftp_server_pass)."@".$ftp_server_name.":".$ftp_port.$dir_id."/".$file_id,
"r");
Expected result:
I'd like that fstat() return FileSize at least, for FTP
Your Bunny Wrote :)) (don't pay attention to this text)
--
Edit this bug report at http://bugs.php.net/?id=32288&edit=1
#46890 [Opn->Bgs]: Regex works in perl, not with preg_match
ID: 46890 Updated by: nlop...@php.net Reported By: gohanman at gmail dot com -Status: Open +Status: Bogus Bug Type: PCRE related Operating System: CentOS PHP Version: 5.2.8 New Comment: it works here. try to do a var_dump($groups); and watch it closely. (btw you shouldn't do 'echo var_dump'..) Previous Comments: [2008-12-18 08:50:07] php at degoulet dot net [r...@pix root]# cat a.php [r...@pix root]# php -v PHP 5.2.8 (cli) (built: Dec 17 2008 16:18:21) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies [r...@pix root]# php a.php int(1) [2008-12-17 20:51:06] gohanman at gmail dot com Description: I'm having a preg_match function fail periodically. I finally found a specific input string that fails in PHP but works fine in Perl. I'm at a loss why. Reproduce code: --- $pattern = "/(\w\w\w) (\d+) (\d\d\d\d) (\d+):(\d\d)(\w)M/"; $input = "Dec 17 2008 2:23PM"; $rv = preg_match($pattern, $input, $groups); echo var_dump($rv); Expected result: A non-zero result indicating the pattern matched. Actual result: -- Zero. -- Edit this bug report at http://bugs.php.net/?id=46890&edit=1
#46895 [Opn->Bgs]: Access Violation 0380AC5A
ID: 46895
Updated by: j...@php.net
Reported By: blue_s_k at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: MySQL related
Operating System: Windows2003
PHP Version: 5.2.8
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
See bug #46842
Previous Comments:
[2008-12-18 08:15:00] blue_s_k at hotmail dot com
Description:
PHP has encountered an Access Violation at 0380AC5A
Installed new MYSQL 5.1
Could not connect with PHP4.9 , said upgrade client
I upgraded the php 5.2.5 - got access violation
I upgraded the php 5.2.8 - got access violation
Windows 2003/ISAPI
PHP 5.2.8 (php info works) fine
MYSQL 5.1, PORT SETTING 3306, Can connect with credentials
Using command line/gui interface to the db
Just having trouble connecting via php to mysql db
Reproduce code:
---
Creating connection to the database: ";
if(!($conn = mysql_connect('localhost', 'test', 'test'))) {
echo "Failed!Please check the
database login details and try again.";
echo $pageFooter;
exit;
} else {
echo " OK!";
}
?>
Expected result:
Connected
--
Edit this bug report at http://bugs.php.net/?id=46895&edit=1
#45092 [Opn]: header HTTP context option not being used (--with-curlwrappers)
ID: 45092
Updated by: j...@php.net
Reported By: nweibley at gmail dot com
Status: Open
Bug Type: cURL related
Operating System: Linux (Gentoo)
PHP Version: 5.2.6
New Comment:
See also bug #46896 (quite likely related)
Previous Comments:
[2008-10-10 15:25:05] php at joerg dot wedekind dot de
Well I have the same prolem, using this Code in php 5.2.6:
'some content',
'var2' => 'doh'
)
);
$opts = array('http' =>
array(
'method' => 'POST',
'header' => 'Cookie: testcookie=1234',
'content' => $postdata
)
);
$context = stream_context_create($opts);
$result = file_get_contents('http://wedekind.de/submit.php', false,
$context);
?>
The cookie-Information is not send to the Server, see this tracelog:
0x: 0020 ed69 d4ca 000a 5e4a a34a 0800 4500 ...i^J.J..E.
0x0010: 00e7 cb3f 4000 3a06 cfea 5413 a9b3 d90b @.:...T.
0x0020: ce14 e117 0050 9419 c2ce a31a b3c2 8018 .P..
0x0030: 002e 3f79 0101 080a 0b17 09ff a78e ..?y
0x0040: 6583 504f 5354 202f 7375 626d 6974 2e70 e.POST./submit.p
0x0050: 6870 2048 5454 502f 312e 310d 0a55 7365 hp.HTTP/1.1..Use
0x0060: 722d 4167 656e 743a 2050 4850 2f35 2e32 r-Agent:.PHP/5.2
0x0070: 2e36 0d0a 486f 7374 3a20 7765 6465 6b69 .6..Host:.wedeki
0x0080: 6e64 2e64 650d 0a41 6363 6570 743a 202a nd.de..Accept:.*
0x0090: 2f2a 0d0a 436f 6e74 656e 742d 4c65 6e67 /*..Content-Leng
0x00a0: 7468 3a20 3236 0d0a 436f 6e74 656e 742d th:.26..Content-
0x00b0: 5479 7065 3a20 6170 706c 6963 6174 696f Type:.applicatio
0x00c0: 6e2f 782d 772d 666f 726d 2d75 726c n/x-www-form-url
0x00d0: 656e 636f 6465 640d 0a0d 0a76 6172 313d encodedvar1=
0x00e0: 736f 6d65 2b63 6f6e 7465 6e74 2676 6172 some+content&var
0x00f0: 323d 646f 68 2=doh
[2008-05-26 15:34:59] nweibley at gmail dot com
Ah, came to the solution.
Line 332 of ext/curl/streams.c:
if (Z_TYPE_PP(header) == IS_STRING) {
Ergo, each element of the array passed as the value of the 'header'
context option *must* be a string, not an associative key=>value pair.
I'd propose this be more clearly documented or an additional conditional
branch be added to ext/curl/streams.c to handle key=>value array pairs
and especially a simple string as the header context option.
This is the behavior when --with-curlwrappers is not used, and it seems
highly logical that it would still stand with curlwrappers enabled.
[2008-05-26 15:27:37] nweibley at gmail dot com
Since line 324 of ext/curl/streams.c reads:
if (SUCCESS == php_stream_context_get_option(context, "http", "header",
&ctx_opt) && Z_TYPE_PP(ctx_opt) == IS_ARRAY) {
I have changed my code to reflect passing an array as the value of
'header' in the context options. The problem still persists, however.
[2008-05-26 15:16:09] nweibley at gmail dot com
Description:
Pretty simple; I'm trying to create a stream context which will send
custom headers along with a simple HTTP GET request. It wasn't working
so I created a second debug script to see what was up and found that PHP
simply isn't including any of my custom headers.
This *is not* a duplicate of bug #41051, I have tried that as well.
Reproduce code:
---
array('method' => 'GET','header' => "Custom:
woot"));
$ctx = stream_context_create($params);
$fp = fopen('http://localhost/recv.php', 'r', false, $ctx);
print_r(stream_context_get_options($ctx));
print_r(stream_get_meta_data($fp));
echo stream_get_contents($fp);
?>
Expected result:
Array
(
[http] => Array
(
[method] => GET
[header] => Custom: woot
)
)
Array
(
[wrapper_data] => Array
(
[headers] => Array
(
)
[readbuf] => Resource id #4
)
[wrapper_type] => cURL
[stream_type] => cURL
[mode] => r
[unread_bytes] => 0
[seekable] =>
[uri] => http://localhost/404.php
[timed_out] =>
[blocked] => 1
[eof] =>
)
Array
(
[User-Agent] => PHP/5.2.6-pl1-gentoo
[Host] => localhost
[Accept] => */*
[Custom] => woot
)
Actual result:
--
Array
(
[http] => Array
(
[method] => GET
[header] => Custom: woot
)
)
Array
(
[wrapper_data] => Array
(
[headers] => Array
(
)
[readbuf] => Resource id #4
)
[wrapper_type] => cURL
[stream_type] => cURL
[mode] => r
[unread_bytes] => 0
[seekable] =>
[uri] => http://localhost/recv.php
[time
#46896 [Opn]: stream_get_meta_data don't fills header list
ID: 46896
Updated by: j...@php.net
Reported By: christian dot lefebvre at atosorigin dot com
Status: Open
Bug Type: cURL related
Operating System: linux
PHP Version: 5.2.8
New Comment:
See also bug #45092 (quite likely related)
Previous Comments:
[2008-12-18 10:22:33] christian dot lefebvre at atosorigin dot com
Description:
With php 5.2.8 and curlwrapper option, after calling fopen() on a
remote url, a call to stream_get_meta_data() returns an empty header
list.
If a call to fread() is inserted between fopen() and
stream_get_meta_data(), the headers are presents.
The problem appears during a migration from 5.0 without curl, to 5.2
with curl, so it seems curl related.
Calling the test script via strace shows that the socket is opened, but
there's no call to read() syscall before the stream_get_meta_data is
called.
The problem is not systematically reproduced (certainly due to response
latencies), but appears very often.
Reproduce code:
---
this version fails :
$src = fopen("http://www.perdu.com";, 'r');
$meta = stream_get_meta_data($src);
var_dump($meta);
var_dump($http_response_header);
$data= fread($src, 500);
echo $data."\n\n";
this one works (just call fread before get_meta) :
$src = fopen("http://www.perdu.com";, 'r');
$data= fread($src, 500);
$meta = stream_get_meta_data($src);
var_dump($meta);
var_dump($http_response_header);
echo $data."\n\n";
Expected result:
array(10) {
["wrapper_data"]=>
array(2) {
["headers"]=>
array(8) {
[0]=>
string(15) "HTTP/1.1 200 OK"
[1]=>
string(35) "Date: Thu, 18 Dec 2008 10:15:19 GMT"
[2]=>
string(14) "Server: Apache"
[3]=>
Actual result:
--
array(10) {
["wrapper_data"]=>
array(2) {
["headers"]=>
array(0) {
}
...
--
Edit this bug report at http://bugs.php.net/?id=46896&edit=1
#46889 [Com]: Memory leak in strtotime()
ID: 46889 Comment by: martin at 925 dot dk Reported By: tim at digicol dot de Status: Assigned Bug Type: Date/time related Operating System: * PHP Version: 5.2.8 Assigned To: derick New Comment: Reproduced here. OS: FreeBSD 7.0-RELEASE-p4 FreeBSD 7.0-RELEASE-p4 PHP: PHP 5.2.8 (cli) (built: Dec 8 2008 19:11:49) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies Previous Comments: [2008-12-17 16:55:59] php at degoulet dot net same issue on centos [2008-12-17 15:11:48] tim at digicol dot de Description: With PHP 5.2.8, strtotime() on my Linux box leaks memory; we've noticed it because we're using long-running scripts with the PHP CLI. In our case, the PHP processes grew to hundreds of MB RAM usage within minutes. This is not the case with PHP 5.2.6. The funny thing is that neither memory_get_usage(false) nor memory_get_usage(true) report the actual memory usage; here's a line from top: 22728 digicol 25 0 258m 218m 6928 R 75.4 43.4 0:42.91 php ... while the PHP functions report at the same time: memory_get_usage(false): 1738020 memory_get_usage(true): 1835008 What's also funny is that the default "memory_limit = 128M" setting doesn't help: PHP doesn't notice that this much RAM is being used and so doesn't kill the script. (But I can trigger the memory limit as usual with other PHP scripts, so PHP's memory limit isn't entirely broken.) I tested with an unchanged copy of php.ini-recommended. My configure string: './configure' '--with-apxs2=/usr/bin/apxs2' '--enable-exif' '-- enable-ftp' '--enable-mbregex' '--enable-mbstring=all' '--enable- pcntl' '--enable-soap' '--enable-zip' '--with-zlib' '--with-curl' '-- with-freetype-dir=/usr' '--with-gd' '--with-jpeg-dir=/usr' '--with- ldap' '--with-mysqli' '--with- oci8=instantclient,/usr/local/lib/instantclient' '--enable-sigchild' '--with-png-dir=/usr' '--with-xsl' '--with-mcrypt' This is Debian Linux 4.0, running in VMware Fusion on an Intel Mac. Thanks a lot for looking into this, and for the great work on PHP! Reproduce code: --- Expected result: No increase in memory usage. Actual result: -- Memory usage is increasing dramatically - on my box, the process is growing by 100 MB per second... -- Edit this bug report at http://bugs.php.net/?id=46889&edit=1
#46896 [NEW]: stream_get_meta_data don't fills header list
From: christian dot lefebvre at atosorigin dot com
Operating system: linux
PHP version: 5.2.8
PHP Bug Type: cURL related
Bug description: stream_get_meta_data don't fills header list
Description:
With php 5.2.8 and curlwrapper option, after calling fopen() on a remote
url, a call to stream_get_meta_data() returns an empty header list.
If a call to fread() is inserted between fopen() and
stream_get_meta_data(), the headers are presents.
The problem appears during a migration from 5.0 without curl, to 5.2 with
curl, so it seems curl related.
Calling the test script via strace shows that the socket is opened, but
there's no call to read() syscall before the stream_get_meta_data is
called.
The problem is not systematically reproduced (certainly due to response
latencies), but appears very often.
Reproduce code:
---
this version fails :
$src = fopen("http://www.perdu.com";, 'r');
$meta = stream_get_meta_data($src);
var_dump($meta);
var_dump($http_response_header);
$data= fread($src, 500);
echo $data."\n\n";
this one works (just call fread before get_meta) :
$src = fopen("http://www.perdu.com";, 'r');
$data= fread($src, 500);
$meta = stream_get_meta_data($src);
var_dump($meta);
var_dump($http_response_header);
echo $data."\n\n";
Expected result:
array(10) {
["wrapper_data"]=>
array(2) {
["headers"]=>
array(8) {
[0]=>
string(15) "HTTP/1.1 200 OK"
[1]=>
string(35) "Date: Thu, 18 Dec 2008 10:15:19 GMT"
[2]=>
string(14) "Server: Apache"
[3]=>
Actual result:
--
array(10) {
["wrapper_data"]=>
array(2) {
["headers"]=>
array(0) {
}
...
--
Edit bug report at http://bugs.php.net/?id=46896&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46896&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46896&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46896&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46896&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46896&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46896&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46896&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46896&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46896&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46896&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46896&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46896&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46896&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46896&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46896&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46896&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46896&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46896&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46896&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46896&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46896&r=mysqlcfg
#46814 [Com]: Relative includes from symlinked directories fail
ID: 46814 Comment by: php at degoulet dot net Reported By: dennis dot birkholz at nexxes dot net Status: Open Bug Type: Scripting Engine problem Operating System: Gentoo/Linux PHP Version: 5.2.8 New Comment: I don't realy understand your problem ?! [r...@pix sdv]# ls -alR .: total 16 drwxr-xr-x 4 root root4096 Dec 17 17:44 . drwxrwxrwx 3 via ftponly 4096 Dec 17 17:44 .. drwxr-xr-x 2 root root4096 Dec 17 17:45 docs drwxr-xr-x 2 root root4096 Dec 17 17:46 test1 lrwxrwxrwx 1 root root 5 Dec 17 17:44 test2 -> test1 ./docs: total 12 drwxr-xr-x 2 root root 4096 Dec 17 17:45 . drwxr-xr-x 4 root root 4096 Dec 17 17:44 .. -rw-r--r-- 1 root root 24 Dec 17 17:45 docs.inc.php ./test1: total 12 drwxr-xr-x 2 root root 4096 Dec 17 17:46 . drwxr-xr-x 4 root root 4096 Dec 17 17:44 .. -rw-r--r-- 1 root root 50 Dec 17 17:46 index.php [r...@pix sdv]# cat test1/index.php [r...@pix sdv]# cat docs/docs.inc.php No problem when i try this with apache : http://www..com/sdv/test1/index.php http://www..com/sdv/test2/index.php ==> same output : docs ok if you try this in command line. 3 cases : - pwd= test1 : php index.php => output docs ok - pwd= test2 : php index.php => output docs ok - pwd= anywhere else : php ./test1/index.php : include(): Unable to access ../docs/docs.inc.php which is quite normal the include path is relative to the current directory where php is executed not relative to the php script which is executed ... isn't it ? Previous Comments: [2008-12-17 22:35:25] dennis dot birkholz at nexxes dot net This IS a bug: in Linux (and Unix like systems) beeing in a symlinked directory should behave exactly like beeing in a directory with the same content. To use my example: If I use a shell and change to the folder /htdocs/test2 (which is a symlink to /test1), ls ../docs/docs.inc.php will show me the file "/htdocs/docs/docs.inc.php" and NOT "/docs/docs.inc.php". [2008-12-17 16:53:29] php at degoulet dot net quite normal : not a bug [2008-12-09 18:17:42] dennis dot birkholz at nexxes dot net Description: include statement seems to resolve the current working directory other than the rest of php so if I am in a symlinked directory an try to include a file using a relative path (containing ../), the include fails because the original path of the script is used to resolve the relative include and not the path the script is invoked from. Reproduce code: --- Asume the following files/directory structure: Directory /test1 Directory /htdocs Directory /htdocs/docs Symlink /htdocs/test2 -> /test1 File /test1/index.php File /htdocs/docs/docs.inc.php DocumentRoot is /htdocs File-Contents of /test1/index.php Expected result: No error, output generated by code after the include Actual result: -- An error: failed to open stream: No such file or directory (/test1/index.php:2) -- Edit this bug report at http://bugs.php.net/?id=46814&edit=1
#46890 [Com]: Regex works in perl, not with preg_match
ID: 46890 Comment by: php at degoulet dot net Reported By: gohanman at gmail dot com Status: Open Bug Type: PCRE related Operating System: CentOS PHP Version: 5.2.8 New Comment: [r...@pix root]# cat a.php [r...@pix root]# php -v PHP 5.2.8 (cli) (built: Dec 17 2008 16:18:21) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies [r...@pix root]# php a.php int(1) Previous Comments: [2008-12-17 20:51:06] gohanman at gmail dot com Description: I'm having a preg_match function fail periodically. I finally found a specific input string that fails in PHP but works fine in Perl. I'm at a loss why. Reproduce code: --- $pattern = "/(\w\w\w) (\d+) (\d\d\d\d) (\d+):(\d\d)(\w)M/"; $input = "Dec 17 2008 2:23PM"; $rv = preg_match($pattern, $input, $groups); echo var_dump($rv); Expected result: A non-zero result indicating the pattern matched. Actual result: -- Zero. -- Edit this bug report at http://bugs.php.net/?id=46890&edit=1
#44417 [Opn->Asn]: call function ignore http wrapper
ID: 44417 Updated by: bj...@php.net Reported By: thomas dot rabaix at gmail dot com -Status: Open +Status: Assigned Bug Type: SOAP related Operating System: Linux PHP Version: 5.2.5 -Assigned To: +Assigned To: dmitry New Comment: ext/soap does indeed re-implement some parts of the http wrapper Previous Comments: [2008-03-13 16:32:41] thomas dot rabaix at gmail dot com I have written an article where I state the problem http://rabaix.net/articles/2008/3/13/using-soap-php-with-ntlm-authentication [2008-03-12 15:03:22] thomas dot rabaix at gmail dot com Description: If you defined your own http protocol wrapper with the stream_wrapper_register function. The method call (http) does not use it. However the SoapClient uses the new wrapper to retrieve the WSDL file. So my conclusion : - SoapClient read using the wrapper - SoapClient write/send using its own methods -- Edit this bug report at http://bugs.php.net/?id=44417&edit=1
#46895 [NEW]: Access Violation 0380AC5A
From: blue_s_k at hotmail dot com
Operating system: Windows2003
PHP version: 5.2.8
PHP Bug Type: MySQL related
Bug description: Access Violation 0380AC5A
Description:
PHP has encountered an Access Violation at 0380AC5A
Installed new MYSQL 5.1
Could not connect with PHP4.9 , said upgrade client
I upgraded the php 5.2.5 - got access violation
I upgraded the php 5.2.8 - got access violation
Windows 2003/ISAPI
PHP 5.2.8 (php info works) fine
MYSQL 5.1, PORT SETTING 3306, Can connect with credentials
Using command line/gui interface to the db
Just having trouble connecting via php to mysql db
Reproduce code:
---
Creating connection to the database: ";
if(!($conn = mysql_connect('localhost', 'test', 'test'))) {
echo "Failed!Please check the database
login details and try again.";
echo $pageFooter;
exit;
} else {
echo " OK!";
}
?>
Expected result:
Connected
--
Edit bug report at http://bugs.php.net/?id=46895&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46895&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46895&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46895&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46895&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46895&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46895&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46895&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46895&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46895&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46895&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46895&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46895&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46895&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46895&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46895&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46895&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46895&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46895&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46895&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46895&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46895&r=mysqlcfg
