Bug #61043 [Fbk]: Regression in magic_quotes_gpc fix (CVE-2012-0831)
Edit report at https://bugs.php.net/bug.php?id=61043&edit=1
ID: 61043
Updated by: ond...@php.net
Reported by:ond...@php.net
Summary:Regression in magic_quotes_gpc fix (CVE-2012-0831)
Status: Feedback
Type: Bug
Package:Variables related
PHP Version:5.3SVN-2012-02-10 (SVN)
Assigned To:johannes
Block user comment: N
Private report: N
New Comment:
Nope, r323016 is the commit which broke it.
Please look at the patch and look at the broken code before jumping to
conclusions.
Previous Comments:
[2012-03-08 13:17:17] johan...@php.net
I think this was fixed in r323016. Please verify.
[2012-03-05 22:46:30] paj...@php.net
Johannes, can you check this please?
[2012-02-13 18:37:04] sbeat...@php.net
OndÅej's patch is the patch we went with in Ubuntu. I verified in our testing
that it did address the issue.
[2012-02-10 13:19:41] ond...@php.net
I can confirm that the attached patch fixes the reported problem:
root@howl:/tmp# /tmp/buildd/php5-5.3.3/cgi-build/sapi/cli/php -c /tmp/php.ini -
r 'var_dump(ini_get("magic_quotes_gpc"));'
string(1) "1"
root@howl:/tmp# grep ^magic_quotes_gpc /tmp/php.ini
magic_quotes_gpc = On
root@howl:/tmp# /tmp/buildd/php5-5.3.3/cgi-build/sapi/cli/php -c /tmp/php.ini -
r 'var_dump(ini_get("magic_quotes_gpc"));'
string(1) "1"
root@howl:/tmp# emacs php.ini
root@howl:/tmp# grep ^magic_quotes_gpc /tmp/php.ini
magic_quotes_gpc = Off
root@howl:/tmp# /tmp/buildd/php5-5.3.3/cgi-build/sapi/cli/php -c /tmp/php.ini -
r 'var_dump(ini_get("magic_quotes_gpc"));'
string(0) ""
[2012-02-10 12:44:17] ond...@php.net
The following patch has been added/updated:
Patch Name: magic_quotes_gpc-regression
Revision: 1328877857
URL:
https://bugs.php.net/patch-display.php?bug=61043&patch=magic_quotes_gpc-regression&revision=1328877857
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=61043
--
Edit this bug report at https://bugs.php.net/bug.php?id=61043&edit=1
Bug #60268 [Com]: Compiling PHP fails
Edit report at https://bugs.php.net/bug.php?id=60268&edit=1 ID: 60268 Comment by: sander at myxt dot nl Reported by:rich06 at gmail dot com Summary:Compiling PHP fails Status: Closed Type: Bug Package:Compile Failure Operating System: Mac OS X 10.7.2 (Lion) PHP Version:5.3.8 Assigned To:patrickallaert Block user comment: N Private report: N New Comment: If you are on OSX and using Xcode 4.3, make sure you install the command line tools. That should solve a good deal of extension compiling errors. Previous Comments: [2012-03-05 18:28:47] dedalo at doramail dot com This is a still an issue men and it's not related to --with-apxs2. This is my configure command line: sudo ./configure --prefix=/usr/local --with-apxs2=/usr/sbin/apxs --with-ldap=/usr --with-kerberos=/usr --enable-cli --with-zlib-dir=/usr --enable-exif --enable-ftp --enable-mbstring --enable-mbregex --enable-sockets --with-iodbc=/usr --with-curl=/usr --with-config-file-path=/etc --sysconfdir=/private/etc --with-mysql-sock=/var/mysql/mysql.sock --with-mysql=mysqlnd --with-mysqli=mysqlnd --with-openssl=/usr --with-xmlrpc --with-xsl=/usr --without-pear --with-libxml-dir=/usr --with-iconv-dir=/opt/local --with-gd --with-jpeg-dir=/opt/local --with-png-dir=/opt/local --with-freetype-dir=/opt/local --with-mcrypt=/opt/local As you can see, there is a file path for apsx2 option: --with-apxs2=/usr/sbin/apxs But the make still fails. To make it work, I changed the Makefile, in particular the MH_BUNDLE_FLAGS, like suggested by rich06, as follow: -L/opt/local/lib This is a bug, and it's still there. Reopen it, please. [2011-12-08 10:43:44] lolautruche at gmail dot com I don't agree here, as ./configure --help says: --with-apxs2=FILE Build shared Apache 2.0 Handler module. FILE is the optional pathname to the Apache apxs tool apxs So FILE is optional [2011-12-08 10:38:54] patrickalla...@php.net Closing. Invalid usage of --with-apxs2 which expects a file argument: --with-apxs2 --with-iconv-dir=/opt/local [2011-12-08 09:59:43] lolautruche at gmail dot com There seems to be linked with --with-apxs2 option. Indeed, I first used --with-apxs2 (without value) and --with-iconv-dir=/opt/local (macports prefix). Here the compiler will take apxs system default (which is /usr/sbin/apxs), and for some reason also makes ignore --with-iconv-dir value. If I use --with-apxs2=/opt/local/apache2/bin/apxs (apache2 macports prefix), then everything will be fine. [2011-12-06 10:02:54] patrickalla...@php.net This issue should be solved, editing manually the Makefile isn't the way to go. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60268 -- Edit this bug report at https://bugs.php.net/bug.php?id=60268&edit=1
Bug #60826 [Com]: raw POST data missing with chunked encoding, FastCGI
Edit report at https://bugs.php.net/bug.php?id=60826&edit=1
ID: 60826
Comment by: florian dot fernandez at navaho dot fr
Reported by:clarkwise at gmail dot com
Summary:raw POST data missing with chunked encoding, FastCGI
Status: Assigned
Type: Bug
Package:CGI/CLI related
Operating System: Windows XP
PHP Version:5.3.9
Assigned To:ab
Block user comment: N
Private report: N
New Comment:
The problem seems to have been resolved with php 5.4.0 and apache 2.4.1. I
can't reproduce it with this configuration and chunked http requests are now
coming through to php now.
I am going to try with php 5.3.10 and apache 2.4.1 and give feedback on where
it goes.
Previous Comments:
[2012-03-05 11:46:27] florian dot fernandez at navaho dot fr
I forgot to mention that this is on a Linux system
[2012-03-05 10:08:17] florian dot fernandez at navaho dot fr
Same problem here. Apache 2.2.15 and PHP 5.3.10 running as FastCGI.
POST datas sent with "Transfer-encoding: chunked" are not received as they
should be. The raw request looks like this :
POST receiveChunk.php HTTP/1.1
User-Agent: PECL::HTTP/1.7.2 (PHP/5.3.8)
Host: www.test.fr
Accept: */*
Pragma: no-cache
Connection: keep-alive
Cache-Control: no-cache
Content-Length: 682668
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
3ff4
(here, the datas)
0
and the request as the receiving script sees it :
User-Agent: PECL::HTTP/1.7.2 (PHP/5.3.8)
Host: www.test.fr
Accept: */*
Pragma: no-cache
Connection: close
Cache-Control: no-cache
As you can see, the request body is empty.
However, this problem does not occur when PHP runs as mod_php under Apache.
Problem confirmed under PHP 5.3.8 and 5.3.9.
I don't know if that is a PHP bug and maybe the developers could confirm or not
that the request body are wrong before it reaches PHP. I think that it appears
to be a mod_fcgid bug and should be reported as one to Apache bug list.
Here are the scripts to reproduce the bug :
sendChunk.php :
'no-cache',
'Connection' => 'keep-alive',
'Cache-Control' => 'no-cache',
'Content-Length' => strlen($fileContentToUp) ,
'Transfer-Encoding' => 'chunked'
);
$options = array(headers => $header_array);
$r = new HttpRequest('receiveChunk.php', HTTP_METH_POST, $options);
$r->setContentType('text/html; charset=UTF-8');
$r->setBody($fileContentToUp);
$result = $r->send();
echo '$r->getRawRequestMessage() => ';
print_r($r->getRawRequestMessage());
echo "\n\n";
echo '$r->send()->getBody() => ';
print_r($r->send()->getBody());
echo "\n\n";
?>
receiveChunk.php :
'."\n";
print_r($HttpResponse->getRequestHeaders());
echo "\n\n";
echo 'http_get_request_body => '."\n";
print_r($HttpResponse->getRequestBody());
echo "\n\n";
?>
Hope that helps.
[2012-03-01 20:24:53] clarkwise at gmail dot com
Since I am using Windows XP, I'm stuck using IIS 5.1. When I have the
opportunity
to try nginx w/ chunkin or IIS 7.5, I'll update with further details. Thanks.
[2012-03-01 08:31:15] a...@php.net
@clarkwise at gmail dot com
So could you confirm it works with nginx+chunkin?
As well, it's was not hanging with IIS (v7.5) for me. Which IIS version do you
have?
[2012-02-09 19:17:27] a...@php.net
I've additionally tested the two files on nginx with PHP as FCGI. The request
simply doesn't go throught to PHP and nginx gives 401 back. I've attached gdb
to the PHP and set a break in the accept loop - there was no reaction when
using the two test files, but requests without data got down to PHP. So my
conclusion were - apache simply ignores the request body where nginx gives a
correct http status. Anyways, this has nothing to do with PHP. IIS, Apache and
Nginx seem to have no implementation for chunked incoming body stuff, but they
do handle that a different way.
Btw. Nginx has the "chunkin" module for such actions.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=60826
--
Edit this bug report at https://bugs.php.net/bug.php?id=60826&edit=1
Bug #60826 [Asn]: raw POST data missing with chunked encoding, FastCGI
Edit report at https://bugs.php.net/bug.php?id=60826&edit=1
ID: 60826
Updated by: paj...@php.net
Reported by:clarkwise at gmail dot com
Summary:raw POST data missing with chunked encoding, FastCGI
Status: Assigned
Type: Bug
Package:CGI/CLI related
Operating System: Windows XP
PHP Version:5.3.9
Assigned To:ab
Block user comment: N
Private report: N
New Comment:
Try a snapshot please, 5.3.10 has nothing else but security fixes unrelated to
this issue.
Previous Comments:
[2012-03-09 09:33:06] florian dot fernandez at navaho dot fr
The problem seems to have been resolved with php 5.4.0 and apache 2.4.1. I
can't reproduce it with this configuration and chunked http requests are now
coming through to php now.
I am going to try with php 5.3.10 and apache 2.4.1 and give feedback on where
it goes.
[2012-03-05 11:46:27] florian dot fernandez at navaho dot fr
I forgot to mention that this is on a Linux system
[2012-03-05 10:08:17] florian dot fernandez at navaho dot fr
Same problem here. Apache 2.2.15 and PHP 5.3.10 running as FastCGI.
POST datas sent with "Transfer-encoding: chunked" are not received as they
should be. The raw request looks like this :
POST receiveChunk.php HTTP/1.1
User-Agent: PECL::HTTP/1.7.2 (PHP/5.3.8)
Host: www.test.fr
Accept: */*
Pragma: no-cache
Connection: keep-alive
Cache-Control: no-cache
Content-Length: 682668
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
3ff4
(here, the datas)
0
and the request as the receiving script sees it :
User-Agent: PECL::HTTP/1.7.2 (PHP/5.3.8)
Host: www.test.fr
Accept: */*
Pragma: no-cache
Connection: close
Cache-Control: no-cache
As you can see, the request body is empty.
However, this problem does not occur when PHP runs as mod_php under Apache.
Problem confirmed under PHP 5.3.8 and 5.3.9.
I don't know if that is a PHP bug and maybe the developers could confirm or not
that the request body are wrong before it reaches PHP. I think that it appears
to be a mod_fcgid bug and should be reported as one to Apache bug list.
Here are the scripts to reproduce the bug :
sendChunk.php :
'no-cache',
'Connection' => 'keep-alive',
'Cache-Control' => 'no-cache',
'Content-Length' => strlen($fileContentToUp) ,
'Transfer-Encoding' => 'chunked'
);
$options = array(headers => $header_array);
$r = new HttpRequest('receiveChunk.php', HTTP_METH_POST, $options);
$r->setContentType('text/html; charset=UTF-8');
$r->setBody($fileContentToUp);
$result = $r->send();
echo '$r->getRawRequestMessage() => ';
print_r($r->getRawRequestMessage());
echo "\n\n";
echo '$r->send()->getBody() => ';
print_r($r->send()->getBody());
echo "\n\n";
?>
receiveChunk.php :
'."\n";
print_r($HttpResponse->getRequestHeaders());
echo "\n\n";
echo 'http_get_request_body => '."\n";
print_r($HttpResponse->getRequestBody());
echo "\n\n";
?>
Hope that helps.
[2012-03-01 20:24:53] clarkwise at gmail dot com
Since I am using Windows XP, I'm stuck using IIS 5.1. When I have the
opportunity
to try nginx w/ chunkin or IIS 7.5, I'll update with further details. Thanks.
[2012-03-01 08:31:15] a...@php.net
@clarkwise at gmail dot com
So could you confirm it works with nginx+chunkin?
As well, it's was not hanging with IIS (v7.5) for me. Which IIS version do you
have?
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=60826
--
Edit this bug report at https://bugs.php.net/bug.php?id=60826&edit=1
Bug #55334 [Asn]: MySQLi make mod_php crash on stress test
Edit report at https://bugs.php.net/bug.php?id=55334&edit=1 ID: 55334 Updated by: johan...@php.net Reported by:bruno at chalopin dot fr Summary:MySQLi make mod_php crash on stress test Status: Assigned Type: Bug Package:MySQLi related Operating System: Windows 2008r2 x64 PHP Version:5.3.7RC4 Assigned To:mattficken Block user comment: N Private report: N New Comment: For 5.3 please use svn snaps. Can you share more details on the test you're doing and the effects you see? Previous Comments: [2012-03-09 00:02:45] mattfic...@php.net Using apache bench locally, I can reproduce this bug on php 5.3.10 and php 5.4.0 using just mysqli. [2012-03-08 13:08:19] johan...@php.net 13:58 <@johannes> Pierre: can you check 5.3 in your stress tests regarding 55334? On Linux and Solaris I can't hit it in threaded context anymore. 5.4/trunk seems to be fixed by dmitry's property refactoring work (svn r299692) 14:05 <@Pierre> johannes, add a comment to the bug and assign it to matt. [2012-03-08 12:55:25] johan...@php.net Seems like this was a bug from very old times in mysqli. I've applied a fix to PHP_5_3 and couldn't trigger an issue anymore with lots of concurrency over a longer period. A fix for 5.4 and trunk is not needed as the code had been refactored before. Please run your tests, too. [2012-03-08 12:52:03] johan...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revision&revision=324022 Log: Use correct property ctor, should fix threading issue in bug #55334 # The code was refactored in 5_4/trunk, no need to merge [2012-01-19 07:40:46] ninzya at inbox dot lv Got apache crashing due to MySQLi as well. Here's the bug report: https://bugs.php.net/bug.php?id=55334 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=55334 -- Edit this bug report at https://bugs.php.net/bug.php?id=55334&edit=1
Bug #61043 [Fbk->Ctl]: Regression in magic_quotes_gpc fix (CVE-2012-0831)
Edit report at https://bugs.php.net/bug.php?id=61043&edit=1
ID: 61043
Updated by: ond...@php.net
Reported by:ond...@php.net
Summary:Regression in magic_quotes_gpc fix (CVE-2012-0831)
-Status: Feedback
+Status: Critical
Type: Bug
Package:Variables related
PHP Version:5.3SVN-2012-02-10 (SVN)
Assigned To:johannes
Block user comment: N
Private report: N
Previous Comments:
[2012-03-09 08:23:57] ond...@php.net
Nope, r323016 is the commit which broke it.
Please look at the patch and look at the broken code before jumping to
conclusions.
[2012-03-08 13:17:17] johan...@php.net
I think this was fixed in r323016. Please verify.
[2012-03-05 22:46:30] paj...@php.net
Johannes, can you check this please?
[2012-02-13 18:37:04] sbeat...@php.net
OndÅej's patch is the patch we went with in Ubuntu. I verified in our testing
that it did address the issue.
[2012-02-10 13:19:41] ond...@php.net
I can confirm that the attached patch fixes the reported problem:
root@howl:/tmp# /tmp/buildd/php5-5.3.3/cgi-build/sapi/cli/php -c /tmp/php.ini -
r 'var_dump(ini_get("magic_quotes_gpc"));'
string(1) "1"
root@howl:/tmp# grep ^magic_quotes_gpc /tmp/php.ini
magic_quotes_gpc = On
root@howl:/tmp# /tmp/buildd/php5-5.3.3/cgi-build/sapi/cli/php -c /tmp/php.ini -
r 'var_dump(ini_get("magic_quotes_gpc"));'
string(1) "1"
root@howl:/tmp# emacs php.ini
root@howl:/tmp# grep ^magic_quotes_gpc /tmp/php.ini
magic_quotes_gpc = Off
root@howl:/tmp# /tmp/buildd/php5-5.3.3/cgi-build/sapi/cli/php -c /tmp/php.ini -
r 'var_dump(ini_get("magic_quotes_gpc"));'
string(0) ""
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=61043
--
Edit this bug report at https://bugs.php.net/bug.php?id=61043&edit=1
Bug #55158 [Opn->Csd]: Add SORT_NATURAL type to array_multisort
Edit report at https://bugs.php.net/bug.php?id=55158&edit=1 ID: 55158 Updated by: ar...@php.net Reported by:joe dot lencioni+php at gmail dot com Summary:Add SORT_NATURAL type to array_multisort -Status: Open +Status: Closed Type: Bug Package:Arrays related PHP Version:5.3.6 -Assigned To: +Assigned To:arpad Block user comment: N Private report: N New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Previous Comments: [2012-03-09 13:47:05] ar...@php.net Automatic comment from SVN on behalf of arpad Revision: http://svn.php.net/viewvc/?view=revision&revision=324055 Log: Docs for #55158 (adding SORT_NATURAL and SORT_FLAG_CASE) [2011-08-29 20:26:04] ar...@php.net Added SORT_NATURAL and SORT_FLAG_CASE which affects sort, rsort, ksort, krsort, asort, arsort and array_multisort. [2011-08-29 20:23:58] der...@php.net Automatic comment from SVN on behalf of derick Revision: http://svn.php.net/viewvc/?view=revision&revision=315737 Log: - Zend engine part for bug #55158: Add SORT_NATURAL type to array_multisort (patch by Arpad Ray). [2011-08-04 16:01:25] ar...@php.net The following patch has been added/updated: Patch Name: php-trunk-array_multisort-natural-case-new-tests Revision: 1312473685 URL: https://bugs.php.net/patch-display.php?bug=55158&patch=php-trunk-array_multisort-natural-case-new-tests&revision=1312473685 [2011-08-04 16:01:09] ar...@php.net The following patch has been added/updated: Patch Name: php-trunk-array_multisort-natural-case-old-tests Revision: 1312473669 URL: https://bugs.php.net/patch-display.php?bug=55158&patch=php-trunk-array_multisort-natural-case-old-tests&revision=1312473669 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=55158 -- Edit this bug report at https://bugs.php.net/bug.php?id=55158&edit=1
Bug #60637 [Opn->Nab]: Lexer is full of memory leaks
Edit report at https://bugs.php.net/bug.php?id=60637&edit=1
ID: 60637
Updated by: ni...@php.net
Reported by:nlop...@php.net
Summary:Lexer is full of memory leaks
-Status: Open
+Status: Not a bug
Type: Bug
Package:Scripting Engine problem
PHP Version:trunk-SVN-2012-01-02 (SVN)
Block user comment: N
Private report: N
New Comment:
Closing as not a bug. After talking to Rasmus it seems like it is intended
behavior to not free all individual allocations on shutdown and instead rely on
the Zend MM to flush all allocated memory.
Previous Comments:
[2012-03-02 15:00:04] ni...@php.net
Ah, seems like I specified USE_ZEND_ALLOC=0 incorrectly.
Now getting this valgrind output for the require inexistent file case:
==8944==
==8944== HEAP SUMMARY:
==8944== in use at exit: 68,745 bytes in 2,588 blocks
==8944== total heap usage: 27,424 allocs, 24,836 frees, 1,842,625 bytes
allocated
==8944==
==8944== 136 bytes in 1 blocks are definitely lost in loss record 69 of 138
==8944==at 0x4028876: malloc (vg_replace_malloc.c:236)
==8944==by 0x850BF34: _emalloc (zend_alloc.c:2423)
==8944==by 0x84E40D2: compile_file (zend_language_scanner.l:548)
==8944==by 0x82E4393: phar_compile_file (phar.c:3391)
==8944==by 0x84E4419: compile_filename (zend_language_scanner.l:622)
==8944==by 0x858A90A: ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER
(zend_vm_execute.h:2592)
==8944==by 0x85806C8: execute (zend_vm_execute.h:410)
==8944==by 0x8545111: zend_execute_scripts (zend.c:1272)
==8944==by 0x84A8624: php_execute_script (main.c:2473)
==8944==by 0x868E8D0: do_cli (php_cli.c:983)
==8944==by 0x868FC4F: main (php_cli.c:1356)
==8944==
==8944== 211 bytes in 1 blocks are definitely lost in loss record 77 of 138
==8944==at 0x402896C: realloc (vg_replace_malloc.c:525)
==8944==by 0x850C08F: _erealloc (zend_alloc.c:2444)
==8944==by 0x84AC6F0: xbuf_format_converter (spprintf.c:777)
==8944==by 0x84AC9DC: vspprintf (spprintf.c:799)
==8944==by 0x84ACA3D: spprintf (spprintf.c:818)
==8944==by 0x84A3CEC: php_verror (main.c:832)
==8944==by 0x84A3FDC: php_error_docref0 (main.c:865)
==8944==by 0x84A5642: php_message_handler_for_zend (main.c:1372)
==8944==by 0x8543DE6: zend_message_dispatcher (zend.c:972)
==8944==by 0x84E41AD: compile_file (zend_language_scanner.l:568)
==8944==by 0x82E4393: phar_compile_file (phar.c:3391)
==8944==by 0x84E4419: compile_filename (zend_language_scanner.l:622)
==8944==
==8944== 252 (136 direct, 116 indirect) bytes in 1 blocks are definitely lost
in loss record 80 of 138
==8944==at 0x4028876: malloc (vg_replace_malloc.c:236)
==8944==by 0x850BF34: _emalloc (zend_alloc.c:2423)
==8944==by 0x84E40D2: compile_file (zend_language_scanner.l:548)
==8944==by 0x82E4393: phar_compile_file (phar.c:3391)
==8944==by 0x854500D: zend_execute_scripts (zend.c:1264)
==8944==by 0x84A8624: php_execute_script (main.c:2473)
==8944==by 0x868E8D0: do_cli (php_cli.c:983)
==8944==by 0x868FC4F: main (php_cli.c:1356)
==8944==
==8944== LEAK SUMMARY:
==8944==definitely lost: 483 bytes in 3 blocks
==8944==indirectly lost: 116 bytes in 4 blocks
==8944== possibly lost: 0 bytes in 0 blocks
==8944==still reachable: 68,146 bytes in 2,581 blocks
==8944== suppressed: 0 bytes in 0 blocks
==8944== Reachable blocks (those to which a pointer was found) are not shown.
==8944== To see them, rerun with: --leak-check=full --show-reachable=yes
==8944==
==8944== For counts of detected and suppressed errors, rerun with: -v
==8944== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 35 from 6)
I'm not sure how expected or not this is. All your cases are ones which will
cause a zend_bailout and unclean shutdown. I'm not sure those can really be
cleaned up correctly.
[2012-03-02 14:46:49] ni...@php.net
I can't reproduce this. How did you detect these leaks / in which form did they
manifest?
[2012-01-02 14:02:34] nlop...@php.net
Description:
zend_language_scanner.l has quite a big number of leaks:
- require('non-existent-file') - 2 leaks
- include('file-with-parse-error')
- every usage of zend_copy_value must be audited -- on a parse error it's
likely the memory will be leaked.
(run with USE_ZEND_ALLOC=0)
--
Edit this bug report at https://bugs.php.net/bug.php?id=60637&edit=1
Bug #60198 [Com]: Array to string notice from array functions
Edit report at https://bugs.php.net/bug.php?id=60198&edit=1 ID: 60198 Comment by: taneli at crasman dot fi Reported by:simon at simon dot geek dot nz Summary:Array to string notice from array functions Status: Not a bug Type: Bug Package:*General Issues PHP Version:5.4SVN-2011-11-02 (SVN) Block user comment: N Private report: N New Comment: Maybe adding an array_diff_recursive function would be a good solution? Previous Comments: [2011-11-11 00:53:18] chx1975 at gmail dot com This should be changed to a documentation bug because up until now if you had outside knowledge that those arrays are the same (for eg they are empty) then this simply worked. If you decided to break it, then it needs to be documented as a change because from a user perspective it is one. [2011-11-11 00:51:23] ras...@php.net The problem here is that these functions aren't recursive. They just go one level deep and assume arrays of scalars. This means that the notice is a good idea because the result when you pass it nested arrays is likely not the one you wanted. For example. If we change your code example slightly: $left = [ 1, 2, [3] ]; $right = [2, 'Array']; What should the intersection of these two be? Surely just the '2' since there is no nested array with a 3 in $right and there is no string 'Array' in $left. But the actual output is: [ 2, [3] ] Oops! That's not what we expected and that is why this result gives you a notice telling you that the result is likely flawed because of an array to string conversion. Now, it might be nice if array_intersect was smarter and could handle nested arrays, but that would be a different feature enhancement bug. It also looks like this is well-documented. The array_intersect() doc page has this highlighted note: Note: Two elements are considered equal if and only if (string) $elem1 === (string) $elem2. In words: when the string representation is the same. [2011-11-11 00:05:29] chx1975 at gmail dot com This affects the Drupal project. All our tests are failing because of this bug. We see it with array_intersect_assoc(). [2011-11-02 08:33:27] simon at simon dot geek dot nz Description: Some of the array_* functions that compare elements in multiple arrays do so by (string)$elem1 === (string)$elem2. If $elem1 or $elem2 is an array, then the array to string notice is thrown. Two examples of functions that can throw this are array_intersect() and array_diff(). If these functions are not expected to take arrays with other arrays as values, this should be mentioned on the documentation pages. Test script: --- b [1] => Array ( [0] => a ) ) Actual result: -- PHP Notice: Array to string conversion in /Users/simon/test.php on line 4 PHP Notice: Array to string conversion in /Users/simon/test.php on line 4 PHP Notice: Array to string conversion in /Users/simon/test.php on line 5 PHP Notice: Array to string conversion in /Users/simon/test.php on line 5 PHP Notice: Array to string conversion in /Users/simon/test.php on line 5 Notice: Array to string conversion in /Users/simon/test.php on line 4 Notice: Array to string conversion in /Users/simon/test.php on line 4 Array ( ) Notice: Array to string conversion in /Users/simon/test.php on line 5 Notice: Array to string conversion in /Users/simon/test.php on line 5 Notice: Array to string conversion in /Users/simon/test.php on line 5 Array ( [0] => b [1] => Array ( [0] => a ) ) -- Edit this bug report at https://bugs.php.net/bug.php?id=60198&edit=1
Bug #61325 [Com]: FastCGI keeps dieing
Edit report at https://bugs.php.net/bug.php?id=61325&edit=1 ID: 61325 Comment by: Alastair at adewra dot com Reported by:Alastair at adewra dot com Summary:FastCGI keeps dieing Status: Feedback Type: Bug Package:CGI/CLI related Operating System: CentOS PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Sorry, i actually ended up downgrading it to 5.3.3 as it was a live server fr other content and it wasn't a necessity to have it on 5.4.0 Unfortunately, I didnt have core dump set up and when i ran strace, it simply just hung. I rebuilt the source several times, and tried to reinstall but it returned the same error. I do still have the old php-cgi on my server (but my lighttpd config is currently pointing to the 5.3.3 one) in a different directory, and when i run -v on the 5.4.0 it now has excluded the warning. Previous Comments: [2012-03-09 02:35:53] larue...@php.net Hi, plz look into the pwd of php-cgi, check is there any core dump file generated? if find one, plz paste the bt here. thanks [2012-03-08 12:36:07] Alastair at adewra dot com Description: Currently running Lighttpd which returns a 500 - Internal Server Error with this log: 2012-03-08 12:26:32: (mod_fastcgi.c.2568) unexpected end-of-file (perhaps the fastcgi process died): pid: 10734 socket: unix:/tmp/php.socket10726-3 2012-03-08 12:26:32: (mod_fastcgi.c.3356) response not received, request sent: 879 on socket: unix:/tmp/php.socket10726-3 for /index.php?, closing connection php -v: PHP 5.4.0 (cli) (built: Mar 7 2012 20:14:12) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies php-cgi -v: PHP Warning: Unknown: function '1' not found or invalid function name in Unknown on line 0 PHP 5.4.0 (cgi-fcgi) (built: Mar 7 2012 20:14:29) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies configure line: ./configure --with-config-file-path=/etc --with-config-file-scan-dir=/etc/php.d - -with-libdir=lib64 --with-mysql --with-mysqli --with-zlib --with-curl --with- mcrypt --enable-cgi If there is anything else I can do to help I will. Sorry, this is my first bug report. -- Edit this bug report at https://bugs.php.net/bug.php?id=61325&edit=1
Bug #61246 [Com]: Error when running PHP-FPM
Edit report at https://bugs.php.net/bug.php?id=61246&edit=1 ID: 61246 Comment by: okspam01 at baimac dot com Reported by:osmanungur at gmail dot com Summary:Error when running PHP-FPM Status: Open Type: Bug Package:FPM related Operating System: Mac Os X 10.7.3 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Hello As of 2012-03-09 this bug seems to still be active. Compiled PHP 5.4.0 with php-fpm Compiled APC 3.1.9 Added apc.so to php.ini Restarted php-fpm Got a full boatload of errors similar in content and flavor to those already posted in these comments. Can post the entire output if needed. Previous Comments: [2012-03-06 22:33:51] dancom96 at gmail dot com Seems to be fixed now in latest APC dev http://pecl.php.net/get/APC [2012-03-05 21:16:12] dancom96 at gmail dot com Exact same issue with PHP 5.4.0, APC 3.1.9 but on CentOS 6. Gives error starting PHP-FPM and says failed, but PHP-FPM does actually start and APC appears to work fully. (Page generation time goes down to 1/4 of original gen time on Wordpress, like my production server) [2012-03-05 10:23:50] takida at nm dot ru If it would help, apache is running as MPM-Prefork. Everything else is pretty standard. [2012-03-05 10:02:18] takida at nm dot ru I'm experiencing the same bug as the guy with Ubuntu yet on CentOS 5.7 with Apache. Same php version, same APC version, almost the same error: *** glibc detected *** php-fpm: master process (/usr/lib/php-5.4.0- custom/etc/php-fpm.conf): free(): invalid pointer: 0xb72a1010 *** What is strange, php-apc was build from source and could not pass the "make test" step completely. When disabling APC everything is fine, otherwise php doesn't work at all. [2012-03-04 08:05:20] rnysmile at yahoo dot com similar problem in Ubuntu 10.04 # /etc/init.d/php-fpm restart Gracefully shutting down php-fpm . done Starting php-fpm *** glibc detected *** /usr/local/sbin/php-fpm: free(): invalid pointer: 0x7f78b5d45118 *** === Backtrace: = /lib/libc.so.6(+0x775b6)[0x7f78b2e6d5b6] /lib/libc.so.6(cfree+0x73)[0x7f78b2e73e83] /usr/local/sbin/php-fpm(destroy_zend_class+0x23d)[0x73953d] /usr/local/sbin/php-fpm(zend_hash_clean+0x73)[0x74e7e3] /usr/local/lib/php/extensions/no-debug-non-zts- 20100525/apc.so(apc_interned_strings_shutdown+0x20)[0x7f78b0285460] /usr/local/lib/php/extensions/no-debug-non-zts- 20100525/apc.so(apc_module_shutdown+0x12a)[0x7f78b027d8fa] /usr/local/lib/php/extensions/no-debug-non-zts-20100525/apc.so(+0xb07f) [0x7f78b027407f] /usr/local/sbin/php-fpm[0x747855] /usr/local/sbin/php-fpm[0x74e152] /usr/local/sbin/php-fpm(zend_hash_graceful_reverse_destroy+0x18)[0x74e3e8] /usr/local/sbin/php-fpm[0x742443] /usr/local/sbin/php-fpm(php_module_shutdown+0x2d)[0x6e671d] /usr/local/sbin/php-fpm[0x7f12b9] /usr/local/sbin/php-fpm[0x7e958e] /usr/local/sbin/php-fpm[0x7f693a] /usr/local/sbin/php-fpm[0x7e89c5] /usr/local/sbin/php-fpm[0x7efb68] /lib/libc.so.6(__libc_start_main+0xfd)[0x7f78b2e14c4d] /usr/local/sbin/php-fpm[0x42f989] No error if disable APC. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=61246 -- Edit this bug report at https://bugs.php.net/bug.php?id=61246&edit=1
Bug #55690 [Asn->Csd]: Wrong behavior of sessionHandler
Edit report at https://bugs.php.net/bug.php?id=55690&edit=1
ID: 55690
Updated by: ar...@php.net
Reported by:larue...@php.net
Summary:Wrong behavior of sessionHandler
-Status: Assigned
+Status: Closed
Type: Bug
Package:Session related
PHP Version:trunk-SVN-2011-09-14 (SVN)
Assigned To:arpad
Block user comment: N
Private report: N
Previous Comments:
[2011-09-14 10:36:21] ar...@php.net
SessionHandler isn't intended to work in any other context than
session_set_save_handler($handler). I'd be nervous about making such a change
now anyway.
However that error message is misleading. I'll update it.
[2011-09-14 05:57:24] larue...@php.net
I think you can remove the PS_SANITY_CHECK, and use PS(mod) instead of
PS(default_mod), this should be okey.
thanks
[2011-09-14 05:52:02] larue...@php.net
arpad plz look at this. thanks
[2011-09-14 05:50:42] larue...@php.net
Description:
in mod_use_class.c
there is a macro:
#define PS_SANITY_CHECK \
if (PS(default_mod) == NULL) { \
php_error_docref(NULL TSRMLS_CC, E_CORE_ERROR, "Called default
SessionHandler but session.save_handler is user"); \
RETURN_FALSE; \
}
but I think this is wrong.
since, the default session.save_handler is "file", and if no new
session.save_handler provide, PS(default_mod) will alyways be NULL(since
default_mod only be assign in OnUpdateSaveHandler
Test script:
---
php -dsession.save_handler=files -r
'var_dump(ini_get("session.save_handler")); $x=new SessionHandler; $x->gc(1);'
Actual result:
--
PHP Fatal error: SessionHandler::gc(): Called default SessionHandler but
session.save_handler is user in Unknown on line 0
--
Edit this bug report at https://bugs.php.net/bug.php?id=55690&edit=1
Bug #61246 [Opn]: Error when running PHP-FPM
Edit report at https://bugs.php.net/bug.php?id=61246&edit=1 ID: 61246 Updated by: ras...@php.net Reported by:osmanungur at gmail dot com Summary:Error when running PHP-FPM Status: Open Type: Bug Package:FPM related Operating System: Mac Os X 10.7.3 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: okspam01 use APC from svn for now until we get a new APC release out. Previous Comments: [2012-03-09 16:15:07] okspam01 at baimac dot com Hello As of 2012-03-09 this bug seems to still be active. Compiled PHP 5.4.0 with php-fpm Compiled APC 3.1.9 Added apc.so to php.ini Restarted php-fpm Got a full boatload of errors similar in content and flavor to those already posted in these comments. Can post the entire output if needed. [2012-03-06 22:33:51] dancom96 at gmail dot com Seems to be fixed now in latest APC dev http://pecl.php.net/get/APC [2012-03-05 21:16:12] dancom96 at gmail dot com Exact same issue with PHP 5.4.0, APC 3.1.9 but on CentOS 6. Gives error starting PHP-FPM and says failed, but PHP-FPM does actually start and APC appears to work fully. (Page generation time goes down to 1/4 of original gen time on Wordpress, like my production server) [2012-03-05 10:23:50] takida at nm dot ru If it would help, apache is running as MPM-Prefork. Everything else is pretty standard. [2012-03-05 10:02:18] takida at nm dot ru I'm experiencing the same bug as the guy with Ubuntu yet on CentOS 5.7 with Apache. Same php version, same APC version, almost the same error: *** glibc detected *** php-fpm: master process (/usr/lib/php-5.4.0- custom/etc/php-fpm.conf): free(): invalid pointer: 0xb72a1010 *** What is strange, php-apc was build from source and could not pass the "make test" step completely. When disabling APC everything is fine, otherwise php doesn't work at all. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=61246 -- Edit this bug report at https://bugs.php.net/bug.php?id=61246&edit=1
[PHP-BUG] Bug #61335 [NEW]: Access to "naked" node returns wrong truth value
From:
Operating system: Linux
PHP version: 5.4.0
Package: SimpleXML related
Bug Type: Bug
Bug description:Access to "naked" node returns wrong truth value
Description:
When accessing a simplexml node as array, I always get an empty simplexml
object.
If I cast the node to string, the behaviour is correct.
If the parent node contains nothing but the child node (not even a newline)
then
the behaviour is also correct.
Under php 5.3, the behaviour is correct.
Test script:
---
$rec1 = simplexml_load_string("aa\n");
$rec2 = simplexml_load_string("aa");
if ($rec1->bar[0]) echo "NONEMPTY1\n"; # not reached, bug
if ($rec1->bar[0] . "") echo "NONEMPTY2\n"; # correct
if ($rec2->bar[0]) echo "NONEMPTY3\n"; # correct
Expected result:
NONEMPTY1
NONEMPTY2
NONEMPTY3
Actual result:
--
NONEMPTY2
NONEMPTY3
--
Edit bug report at https://bugs.php.net/bug.php?id=61335&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61335&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61335&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61335&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61335&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61335&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61335&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61335&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61335&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61335&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61335&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61335&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61335&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61335&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61335&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61335&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61335&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61335&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61335&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61335&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61335&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61335&r=mysqlcfg
Bug #61335 [Opn]: Access to array node returns wrong truth value
Edit report at https://bugs.php.net/bug.php?id=61335&edit=1
ID: 61335
User updated by:mueller at relog dot ch
Reported by:mueller at relog dot ch
-Summary:Access to "naked" node returns wrong truth value
+Summary:Access to array node returns wrong truth value
Status: Open
Type: Bug
Package:SimpleXML related
Operating System: Linux
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
I forgot: Omitting the [0] array access will also fix the problem.
Previous Comments:
[2012-03-09 17:57:50] mueller at relog dot ch
Description:
When accessing a simplexml node as array, I always get an empty simplexml
object.
If I cast the node to string, the behaviour is correct.
If the parent node contains nothing but the child node (not even a newline)
then
the behaviour is also correct.
Under php 5.3, the behaviour is correct.
Test script:
---
$rec1 = simplexml_load_string("aa\n");
$rec2 = simplexml_load_string("aa");
if ($rec1->bar[0]) echo "NONEMPTY1\n"; # not reached, bug
if ($rec1->bar[0] . "") echo "NONEMPTY2\n"; # correct
if ($rec2->bar[0]) echo "NONEMPTY3\n"; # correct
Expected result:
NONEMPTY1
NONEMPTY2
NONEMPTY3
Actual result:
--
NONEMPTY2
NONEMPTY3
--
Edit this bug report at https://bugs.php.net/bug.php?id=61335&edit=1
Bug #61253 [Com]: Wrappers opened with errors concurrency problem
Edit report at https://bugs.php.net/bug.php?id=61253&edit=1
ID: 61253
Comment by: mattfic...@php.net
Reported by:cataphr...@php.net
Summary:Wrappers opened with errors concurrency problem
Status: Assigned
Type: Bug
Package:Streams related
Operating System: Any (ZTS)
PHP Version:5.4SVN-2012-03-02 (SVN)
Assigned To:mattficken
Block user comment: N
Private report: N
New Comment:
As of 5_4 rev324027, I can no longer reproduce this bug using Apache 2.2 on
Windows 2008r2.
I think the fix works.
Previous Comments:
[2012-03-08 12:39:39] cataphr...@php.net
Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revision&revision=324021
Log: - Oops committed old version of the patch in r324020. Fixed. See bug
#61253.
[2012-03-08 12:32:14] cataphr...@php.net
I've committed the patch. Testing would still be useful.
[2012-03-08 12:30:50] cataphr...@php.net
Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revision&revision=324020
Log: - Fixed bug #61253: Wrappers opened with errors concurrency problem
#NOTE: There is a very small possibility that this will further break
#extensions that access wrapper->{err_stack, err_count}. On PECL SVN, rar is
the
#only one and it may leak memory after this. I say "further break"
because
#extensions that do that are already broken (will segfault) under ZTS, which is
#why this patch is necessary.
#There was what I deem as tacit acceptance from 5.3/5.4 RMs on this.
[2012-03-07 14:05:35] cataphr...@php.net
The following patch has been added/updated:
Patch Name: bug61253.diff
Revision: 1331129135
URL:
https://bugs.php.net/patch-display.php?bug=61253&patch=bug61253.diff&revision=1331129135
[2012-03-03 20:42:12] paj...@php.net
Matt, can you test this patch please? and add the test to our suites while
being
at it :)
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=61253
--
Edit this bug report at https://bugs.php.net/bug.php?id=61253&edit=1
Bug #55334 [Com]: MySQLi make mod_php crash on stress test
Edit report at https://bugs.php.net/bug.php?id=55334&edit=1 ID: 55334 Comment by: mattfic...@php.net Reported by:bruno at chalopin dot fr Summary:MySQLi make mod_php crash on stress test Status: Assigned Type: Bug Package:MySQLi related Operating System: Windows 2008r2 x64 PHP Version:5.3.7RC4 Assigned To:mattficken Block user comment: N Private report: N New Comment: Using 5_3 r324027, with Apache 2.2 on Windows 2008r2sp0, I can no longer reproduce this bug. I think this bug is fixed. Previous Comments: [2012-03-09 09:52:00] johan...@php.net For 5.3 please use svn snaps. Can you share more details on the test you're doing and the effects you see? [2012-03-09 00:02:45] mattfic...@php.net Using apache bench locally, I can reproduce this bug on php 5.3.10 and php 5.4.0 using just mysqli. [2012-03-08 13:08:19] johan...@php.net 13:58 <@johannes> Pierre: can you check 5.3 in your stress tests regarding 55334? On Linux and Solaris I can't hit it in threaded context anymore. 5.4/trunk seems to be fixed by dmitry's property refactoring work (svn r299692) 14:05 <@Pierre> johannes, add a comment to the bug and assign it to matt. [2012-03-08 12:55:25] johan...@php.net Seems like this was a bug from very old times in mysqli. I've applied a fix to PHP_5_3 and couldn't trigger an issue anymore with lots of concurrency over a longer period. A fix for 5.4 and trunk is not needed as the code had been refactored before. Please run your tests, too. [2012-03-08 12:52:03] johan...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revision&revision=324022 Log: Use correct property ctor, should fix threading issue in bug #55334 # The code was refactored in 5_4/trunk, no need to merge The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=55334 -- Edit this bug report at https://bugs.php.net/bug.php?id=55334&edit=1
Bug #55334 [Asn->Csd]: MySQLi make mod_php crash on stress test
Edit report at https://bugs.php.net/bug.php?id=55334&edit=1 ID: 55334 Updated by: mattfic...@php.net Reported by:bruno at chalopin dot fr Summary:MySQLi make mod_php crash on stress test -Status: Assigned +Status: Closed Type: Bug Package:MySQLi related Operating System: Windows 2008r2 x64 PHP Version:5.3.7RC4 Assigned To:mattficken Block user comment: N Private report: N New Comment: Closing bug Previous Comments: [2012-03-09 19:03:14] mattfic...@php.net Using 5_3 r324027, with Apache 2.2 on Windows 2008r2sp0, I can no longer reproduce this bug. I think this bug is fixed. [2012-03-09 09:52:00] johan...@php.net For 5.3 please use svn snaps. Can you share more details on the test you're doing and the effects you see? [2012-03-09 00:02:45] mattfic...@php.net Using apache bench locally, I can reproduce this bug on php 5.3.10 and php 5.4.0 using just mysqli. [2012-03-08 13:08:19] johan...@php.net 13:58 <@johannes> Pierre: can you check 5.3 in your stress tests regarding 55334? On Linux and Solaris I can't hit it in threaded context anymore. 5.4/trunk seems to be fixed by dmitry's property refactoring work (svn r299692) 14:05 <@Pierre> johannes, add a comment to the bug and assign it to matt. [2012-03-08 12:55:25] johan...@php.net Seems like this was a bug from very old times in mysqli. I've applied a fix to PHP_5_3 and couldn't trigger an issue anymore with lots of concurrency over a longer period. A fix for 5.4 and trunk is not needed as the code had been refactored before. Please run your tests, too. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=55334 -- Edit this bug report at https://bugs.php.net/bug.php?id=55334&edit=1
Bug #61253 [Asn->Csd]: Wrappers opened with errors concurrency problem
Edit report at https://bugs.php.net/bug.php?id=61253&edit=1
ID: 61253
Updated by: mattfic...@php.net
Reported by:cataphr...@php.net
Summary:Wrappers opened with errors concurrency problem
-Status: Assigned
+Status: Closed
Type: Bug
Package:Streams related
Operating System: Any (ZTS)
PHP Version:5.4SVN-2012-03-02 (SVN)
Assigned To:mattficken
Block user comment: N
Private report: N
New Comment:
Closing bug.
Previous Comments:
[2012-03-09 18:29:35] mattfic...@php.net
As of 5_4 rev324027, I can no longer reproduce this bug using Apache 2.2 on
Windows 2008r2.
I think the fix works.
[2012-03-08 12:39:39] cataphr...@php.net
Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revision&revision=324021
Log: - Oops committed old version of the patch in r324020. Fixed. See bug
#61253.
[2012-03-08 12:32:14] cataphr...@php.net
I've committed the patch. Testing would still be useful.
[2012-03-08 12:30:50] cataphr...@php.net
Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revision&revision=324020
Log: - Fixed bug #61253: Wrappers opened with errors concurrency problem
#NOTE: There is a very small possibility that this will further break
#extensions that access wrapper->{err_stack, err_count}. On PECL SVN, rar is
the
#only one and it may leak memory after this. I say "further break"
because
#extensions that do that are already broken (will segfault) under ZTS, which is
#why this patch is necessary.
#There was what I deem as tacit acceptance from 5.3/5.4 RMs on this.
[2012-03-07 14:05:35] cataphr...@php.net
The following patch has been added/updated:
Patch Name: bug61253.diff
Revision: 1331129135
URL:
https://bugs.php.net/patch-display.php?bug=61253&patch=bug61253.diff&revision=1331129135
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=61253
--
Edit this bug report at https://bugs.php.net/bug.php?id=61253&edit=1
[PHP-BUG] Bug #61336 [NEW]: file_get_contents() no longer returns false on 4xx responses
From: ramsey
Operating system: CentOS 6.2
PHP version: 5.4.0
Package: Filesystem function related
Bug Type: Bug
Bug description:file_get_contents() no longer returns false on 4xx responses
Description:
In PHP 5.3, file_get_contents() returns false on 4xx responses. In PHP 5.4,
file_get_contents() is returning the actual response body, rather than
false.
Test script:
---
http://us3.php.net/manual/en/function.foobar.php');
var_dump($http_response_header);
var_dump($response);
Expected result:
With warnings turned on, this is what I get in PHP 5.3 and what I expect to
see
in PHP 5.4:
PHP Warning:
file_get_contents(http://us3.php.net/manual/en/function.foobar.php): failed
to
open stream: HTTP request failed! HTTP/1.0 404 Not Found
in /Users/ramsey/Desktop/file_get_contents.php on line 3
PHP Stack trace:
PHP 1. {main}() /Users/ramsey/Desktop/file_get_contents.php:0
PHP 2. file_get_contents() /Users/ramsey/Desktop/file_get_contents.php:3
array(11) {
[0]=>
string(22) "HTTP/1.0 404 Not Found"
[1]=>
string(35) "Date: Fri, 09 Mar 2012 21:57:32 GMT"
[2]=>
string(29) "Server: Apache/2.2.3 (CentOS)"
[3]=>
string(23) "X-Powered-By: PHP/5.3.2"
[4]=>
string(20) "Content-language: en"
[5]=>
string(88) "Set-Cookie: LAST_LANG=en; expires=Sat, 09-Mar-2013 21:57:32
GMT;
path=/; domain=.php.net"
[6]=>
string(102) "Set-Cookie: COUNTRY=USA%2C64.2.187.194; expires=Fri,
16-Mar-2012
21:57:32 GMT; path=/; domain=.php.net"
[7]=>
string(21) "Status: 404 Not Found"
[8]=>
string(20) "Content-Length: 4219"
[9]=>
string(17) "Connection: close"
[10]=>
string(37) "Content-Type: text/html;charset=utf-8"
}
bool(false)
Actual result:
--
array(11) {
[0]=>
string(22) "HTTP/1.1 404 Not Found"
[1]=>
string(35) "Date: Fri, 09 Mar 2012 21:58:44 GMT"
[2]=>
string(29) "Server: Apache/2.2.3 (CentOS)"
[3]=>
string(23) "X-Powered-By: PHP/5.3.2"
[4]=>
string(20) "Content-language: en"
[5]=>
string(88) "Set-Cookie: LAST_LANG=en; expires=Sat, 09-Mar-2013 21:58:44
GMT;
path=/; domain=.php.net"
[6]=>
string(102) "Set-Cookie: COUNTRY=USA%2C64.2.187.194; expires=Fri,
16-Mar-2012
21:58:44 GMT; path=/; domain=.php.net"
[7]=>
string(21) "Status: 404 Not Found"
[8]=>
string(20) "Content-Length: 4219"
[9]=>
string(17) "Connection: close"
[10]=>
string(37) "Content-Type: text/html;charset=utf-8"
}
string(4219) "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en">
PHP: 404 Not Found
Bug #61336 [Com]: file_get_contents() no longer returns false on 4xx responses
Edit report at https://bugs.php.net/bug.php?id=61336&edit=1
ID: 61336
Comment by: s...@php.net
Reported by:ram...@php.net
Summary:file_get_contents() no longer returns false on 4xx
responses
Status: Open
Type: Bug
Package:Filesystem function related
Operating System: CentOS 6.2
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
Just for the record, repro script works for me on Windows / 5.4.0 VC9 NTS
Previous Comments:
[2012-03-09 21:59:47] ram...@php.net
Description:
In PHP 5.3, file_get_contents() returns false on 4xx responses. In PHP 5.4,
file_get_contents() is returning the actual response body, rather than false.
Test script:
---
http://us3.php.net/manual/en/function.foobar.php');
var_dump($http_response_header);
var_dump($response);
Expected result:
With warnings turned on, this is what I get in PHP 5.3 and what I expect to see
in PHP 5.4:
PHP Warning:
file_get_contents(http://us3.php.net/manual/en/function.foobar.php): failed to
open stream: HTTP request failed! HTTP/1.0 404 Not Found
in /Users/ramsey/Desktop/file_get_contents.php on line 3
PHP Stack trace:
PHP 1. {main}() /Users/ramsey/Desktop/file_get_contents.php:0
PHP 2. file_get_contents() /Users/ramsey/Desktop/file_get_contents.php:3
array(11) {
[0]=>
string(22) "HTTP/1.0 404 Not Found"
[1]=>
string(35) "Date: Fri, 09 Mar 2012 21:57:32 GMT"
[2]=>
string(29) "Server: Apache/2.2.3 (CentOS)"
[3]=>
string(23) "X-Powered-By: PHP/5.3.2"
[4]=>
string(20) "Content-language: en"
[5]=>
string(88) "Set-Cookie: LAST_LANG=en; expires=Sat, 09-Mar-2013 21:57:32 GMT;
path=/; domain=.php.net"
[6]=>
string(102) "Set-Cookie: COUNTRY=USA%2C64.2.187.194; expires=Fri, 16-Mar-2012
21:57:32 GMT; path=/; domain=.php.net"
[7]=>
string(21) "Status: 404 Not Found"
[8]=>
string(20) "Content-Length: 4219"
[9]=>
string(17) "Connection: close"
[10]=>
string(37) "Content-Type: text/html;charset=utf-8"
}
bool(false)
Actual result:
--
array(11) {
[0]=>
string(22) "HTTP/1.1 404 Not Found"
[1]=>
string(35) "Date: Fri, 09 Mar 2012 21:58:44 GMT"
[2]=>
string(29) "Server: Apache/2.2.3 (CentOS)"
[3]=>
string(23) "X-Powered-By: PHP/5.3.2"
[4]=>
string(20) "Content-language: en"
[5]=>
string(88) "Set-Cookie: LAST_LANG=en; expires=Sat, 09-Mar-2013 21:58:44 GMT;
path=/; domain=.php.net"
[6]=>
string(102) "Set-Cookie: COUNTRY=USA%2C64.2.187.194; expires=Fri, 16-Mar-2012
21:58:44 GMT; path=/; domain=.php.net"
[7]=>
string(21) "Status: 404 Not Found"
[8]=>
string(20) "Content-Length: 4219"
[9]=>
string(17) "Connection: close"
[10]=>
string(37) "Content-Type: text/html;charset=utf-8"
}
string(4219) "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en">
PHP: 404 Not Found
Bug #55334 [Csd->ReO]: MySQLi make mod_php crash on stress test
Edit report at https://bugs.php.net/bug.php?id=55334&edit=1 ID: 55334 Updated by: mattfic...@php.net Reported by:bruno at chalopin dot fr Summary:MySQLi make mod_php crash on stress test -Status: Closed +Status: Re-Opened Type: Bug Package:MySQLi related Operating System: Windows 2008r2 x64 PHP Version:5.3.7RC4 Assigned To:mattficken Block user comment: N Private report: N New Comment: To repro this problem, your test environment needs to have 4+ cpus, which the environment I was previously using didn't have. Previous Comments: [2012-03-09 19:07:38] mattfic...@php.net Closing bug [2012-03-09 19:03:14] mattfic...@php.net Using 5_3 r324027, with Apache 2.2 on Windows 2008r2sp0, I can no longer reproduce this bug. I think this bug is fixed. [2012-03-09 09:52:00] johan...@php.net For 5.3 please use svn snaps. Can you share more details on the test you're doing and the effects you see? [2012-03-09 00:02:45] mattfic...@php.net Using apache bench locally, I can reproduce this bug on php 5.3.10 and php 5.4.0 using just mysqli. [2012-03-08 13:08:19] johan...@php.net 13:58 <@johannes> Pierre: can you check 5.3 in your stress tests regarding 55334? On Linux and Solaris I can't hit it in threaded context anymore. 5.4/trunk seems to be fixed by dmitry's property refactoring work (svn r299692) 14:05 <@Pierre> johannes, add a comment to the bug and assign it to matt. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=55334 -- Edit this bug report at https://bugs.php.net/bug.php?id=55334&edit=1
Bug #61246 [Com]: Error when running PHP-FPM
Edit report at https://bugs.php.net/bug.php?id=61246&edit=1 ID: 61246 Comment by: dancom96 at gmail dot com Reported by:osmanungur at gmail dot com Summary:Error when running PHP-FPM Status: Open Type: Bug Package:FPM related Operating System: Mac Os X 10.7.3 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: I copy pasted the wrong link in my last comment, but the latest SVN APC seems to be broken again. I compiled with SVN APC a couple days ago and it worked fine; but today I redownloaded it and recompiled, and I now have the same error once again. Previous Comments: [2012-03-09 17:26:09] ras...@php.net okspam01 use APC from svn for now until we get a new APC release out. [2012-03-09 16:15:07] okspam01 at baimac dot com Hello As of 2012-03-09 this bug seems to still be active. Compiled PHP 5.4.0 with php-fpm Compiled APC 3.1.9 Added apc.so to php.ini Restarted php-fpm Got a full boatload of errors similar in content and flavor to those already posted in these comments. Can post the entire output if needed. [2012-03-06 22:33:51] dancom96 at gmail dot com Seems to be fixed now in latest APC dev http://pecl.php.net/get/APC [2012-03-05 21:16:12] dancom96 at gmail dot com Exact same issue with PHP 5.4.0, APC 3.1.9 but on CentOS 6. Gives error starting PHP-FPM and says failed, but PHP-FPM does actually start and APC appears to work fully. (Page generation time goes down to 1/4 of original gen time on Wordpress, like my production server) [2012-03-05 10:23:50] takida at nm dot ru If it would help, apache is running as MPM-Prefork. Everything else is pretty standard. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=61246 -- Edit this bug report at https://bugs.php.net/bug.php?id=61246&edit=1
Bug #61335 [Com]: Access to array node returns wrong truth value
Edit report at https://bugs.php.net/bug.php?id=61335&edit=1
ID: 61335
Comment by: me at ktamura dot com
Reported by:mueller at relog dot ch
Summary:Access to array node returns wrong truth value
Status: Open
Type: Bug
Package:SimpleXML related
Operating System: Linux
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
I think this bug is related to https://bugs.php.net/bug.php?id=51615
Previous Comments:
[2012-03-09 18:00:28] mueller at relog dot ch
I forgot: Omitting the [0] array access will also fix the problem.
[2012-03-09 17:57:50] mueller at relog dot ch
Description:
When accessing a simplexml node as array, I always get an empty simplexml
object.
If I cast the node to string, the behaviour is correct.
If the parent node contains nothing but the child node (not even a newline)
then
the behaviour is also correct.
Under php 5.3, the behaviour is correct.
Test script:
---
$rec1 = simplexml_load_string("aa\n");
$rec2 = simplexml_load_string("aa");
if ($rec1->bar[0]) echo "NONEMPTY1\n"; # not reached, bug
if ($rec1->bar[0] . "") echo "NONEMPTY2\n"; # correct
if ($rec2->bar[0]) echo "NONEMPTY3\n"; # correct
Expected result:
NONEMPTY1
NONEMPTY2
NONEMPTY3
Actual result:
--
NONEMPTY2
NONEMPTY3
--
Edit this bug report at https://bugs.php.net/bug.php?id=61335&edit=1
