Bug #55438 [Asn]: race condition: curlwapper is not sending http header randomly
Edit report at https://bugs.php.net/bug.php?id=55438&edit=1
ID: 55438
Updated by: pierr...@php.net
Reported by:xuefer at gmail dot com
Summary:race condition: curlwapper is not sending http
header randomly
Status: Assigned
Type: Bug
Package:cURL related
Operating System: gentoo
PHP Version:5.3.6
Assigned To:pierrick
Block user comment: N
Private report: N
New Comment:
Ok, I finally reproduced the problem.
I was trying the code snippet on my local network and everything was fine, once
I modified the code to fetch an URL on a slower network I had the problem.
Since curl multi is used, it sometime happen that the resource is freed before
the curl multi really execute the query. The patch looks good, I'll have a
second look tomorrow and will commit it.
Thanks for your help on this one :)
Previous Comments:
[2012-12-19 06:01:04] phpnet at lostreality dot org
I have curl-7.15.5-15.el5 according to rpm -q, but I can only locate
/usr/lib/libcurl.so.3.0.0 and /usr/lib64/libcurl.so.3.0.0 on my machine I'm
testing on (CentOS 5.8). The binary says: /usr/bin/curl -V
curl 7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3
libidn/0.6.5
Normally, I use the stock RPMs for PHP, but a recent project I was working on
failed to run properly on another machine, where the owners also use CentOS
5.8, but use CPanel/WHM instead of the CentOS RPMs for PHP. CPanel uses the
--with-curlwrappers option, where as the stock CentOS and RHEL RPMs have never
used that option on any of their builds. It took a lot of digging before I
realized that it was the --with-curlwrappers option that caused the scripts to
fail on that machine while working perfectly on mine.
To verify if the headers were actually sent, I used: tcpdump -i eth1 -Als0 host
www.example.com
I had two PuTTY windows open, one with tcpdump, the other running the test
script I mentioned before with: ./php-5.4.9/sapi/cli/php ./test.php
It was pretty clear to me that the headers were never sent before the patch,
and always sent after the patch.
[2012-12-19 05:50:16] pierr...@php.net
I tried to reproduce this bug but wasn't able to do it.
Could you give me more details on the libcurl version used by your PHP instance
?
And also, how do you make sure that the headers are not properly sent ?
[2012-12-19 04:33:11] phpnet at lostreality dot org
I submitted a patch that moves the slist from a local variable in
php_curl_stream_opener() into the php_curl_stream struct. The headers are no
longer cleared and freed at the end of php_curl_stream_opener(). The code to
free the slist is moved into php_curl_stream_close() instead. I'm not sure if
this is the best approach, but it clearly gives me a 100% success rate with
having headers get sent, where as I had a literal 0% success rate before (not
sure if there is really a race condition or not, just that the headers get
cleared and the slist freed before they get used.)
The test code I used was as follows (Actual cookie and URL redacted)
array('method' => 'GET', 'header' => 'Cookie: foo=bar'));
$ctx = stream_context_create($opt);
$f = fopen('http://www.example.com/', 'r', false, $ctx);
fread($f, 1); //work-around curl-wrappers bug where meta_data doesn't exist
until the stream is read
$data = stream_get_meta_data($f);
fclose($f);
var_dump($data);
?>
I compiled PHP with the following flags (not that I think anything matters to
this bug other than --with-curlwrappers):
--enable-static --with-mcrypt --with-ldap --with-iconv --enable-mbstring
--with-gd --enable-mbregex --with-zlib --with-imap --enable-ftp --with-gettext
--enable-sockets --with-mysql=/usr --enable-cgi --with-imap-ssl
--enable-sockets --with-pdo-mysql --with-openssl --with-kerberos --with-curl
--with-curlwrappers --with-tidy --with-pcre-regex --with-bz2 --enable-zip
--with-libdir=/lib64
[2012-12-18 19:29:56] phpnet at lostreality dot org
I think I am seeing this same problem too (On 5.3.10, but nothing has changed
in the source in 5.4.9 either).
Can you explain how this is happening, or suggest a work-around? I was digging
into the PHP source, expecting that the --with-curlwrappers option was
basically broken and incomplete. I was surprised to find the line:
curl_easy_setopt(curlstream->curl, CURLOPT_HTTPHEADER, slist);
Because that code all seems to indicate that the headers should be sent, but no
matter what I try, nothing I put in headers ever appears in the actual request.
I keep running tcpdump but I never see the headers I put in http->header.
-
Bug #63462 [Opn->Asn]: Magic methods called twice for unset protected properties
Edit report at https://bugs.php.net/bug.php?id=63462&edit=1 ID: 63462 Updated by: dmi...@php.net Reported by:ocramius at gmail dot com Summary:Magic methods called twice for unset protected properties -Status: Open +Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Irrelevant PHP Version:5.4.8 -Assigned To: +Assigned To:dmitry Block user comment: N Private report: N Previous Comments: [2012-11-08 07:34:06] larue...@php.net similar to #55731 [2012-11-08 05:47:23] ocramius at gmail dot com I've added the failing test case as a PR at https://github.com/php/php-src/pull/229 [2012-11-08 05:40:59] ocramius at gmail dot com Description: When un-setting a private or protected property of an object, magic methods get called twice when that property is accessed. Test script: --- https://gist.github.com/4037010 (will provide PR with the test later) Expected result: Each of the magic methods presented in the test script should be called only once per checked property. Actual result: -- Each of the magic methods are called twice for private or protected properties that were unset. -- Edit this bug report at https://bugs.php.net/bug.php?id=63462&edit=1
Bug #55438 [Com]: race condition: curlwapper is not sending http header randomly
Edit report at https://bugs.php.net/bug.php?id=55438&edit=1
ID: 55438
Comment by: phpnet at lostreality dot org
Reported by:xuefer at gmail dot com
Summary:race condition: curlwapper is not sending http
header randomly
Status: Assigned
Type: Bug
Package:cURL related
Operating System: gentoo
PHP Version:5.3.6
Assigned To:pierrick
Block user comment: N
Private report: N
New Comment:
I have curl-7.15.5-15.el5 according to rpm -q, but I can only locate
/usr/lib/libcurl.so.3.0.0 and /usr/lib64/libcurl.so.3.0.0 on my machine I'm
testing on (CentOS 5.8). The binary says: /usr/bin/curl -V
curl 7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3
libidn/0.6.5
Normally, I use the stock RPMs for PHP, but a recent project I was working on
failed to run properly on another machine, where the owners also use CentOS
5.8, but use CPanel/WHM instead of the CentOS RPMs for PHP. CPanel uses the
--with-curlwrappers option, where as the stock CentOS and RHEL RPMs have never
used that option on any of their builds. It took a lot of digging before I
realized that it was the --with-curlwrappers option that caused the scripts to
fail on that machine while working perfectly on mine.
To verify if the headers were actually sent, I used: tcpdump -i eth1 -Als0 host
www.example.com
I had two PuTTY windows open, one with tcpdump, the other running the test
script I mentioned before with: ./php-5.4.9/sapi/cli/php ./test.php
It was pretty clear to me that the headers were never sent before the patch,
and always sent after the patch.
Previous Comments:
[2012-12-19 05:50:16] pierr...@php.net
I tried to reproduce this bug but wasn't able to do it.
Could you give me more details on the libcurl version used by your PHP instance
?
And also, how do you make sure that the headers are not properly sent ?
[2012-12-19 04:33:11] phpnet at lostreality dot org
I submitted a patch that moves the slist from a local variable in
php_curl_stream_opener() into the php_curl_stream struct. The headers are no
longer cleared and freed at the end of php_curl_stream_opener(). The code to
free the slist is moved into php_curl_stream_close() instead. I'm not sure if
this is the best approach, but it clearly gives me a 100% success rate with
having headers get sent, where as I had a literal 0% success rate before (not
sure if there is really a race condition or not, just that the headers get
cleared and the slist freed before they get used.)
The test code I used was as follows (Actual cookie and URL redacted)
array('method' => 'GET', 'header' => 'Cookie: foo=bar'));
$ctx = stream_context_create($opt);
$f = fopen('http://www.example.com/', 'r', false, $ctx);
fread($f, 1); //work-around curl-wrappers bug where meta_data doesn't exist
until the stream is read
$data = stream_get_meta_data($f);
fclose($f);
var_dump($data);
?>
I compiled PHP with the following flags (not that I think anything matters to
this bug other than --with-curlwrappers):
--enable-static --with-mcrypt --with-ldap --with-iconv --enable-mbstring
--with-gd --enable-mbregex --with-zlib --with-imap --enable-ftp --with-gettext
--enable-sockets --with-mysql=/usr --enable-cgi --with-imap-ssl
--enable-sockets --with-pdo-mysql --with-openssl --with-kerberos --with-curl
--with-curlwrappers --with-tidy --with-pcre-regex --with-bz2 --enable-zip
--with-libdir=/lib64
[2012-12-18 19:29:56] phpnet at lostreality dot org
I think I am seeing this same problem too (On 5.3.10, but nothing has changed
in the source in 5.4.9 either).
Can you explain how this is happening, or suggest a work-around? I was digging
into the PHP source, expecting that the --with-curlwrappers option was
basically broken and incomplete. I was surprised to find the line:
curl_easy_setopt(curlstream->curl, CURLOPT_HTTPHEADER, slist);
Because that code all seems to indicate that the headers should be sent, but no
matter what I try, nothing I put in headers ever appears in the actual request.
I keep running tcpdump but I never see the headers I put in http->header.
[2011-08-17 11:45:54] xuefer at gmail dot com
sorry for the mismatch http url string. i was trying to remove some string for
privacy
[2011-08-17 11:38:50] xuefer at gmail dot com
Description:
background: php is configured with curl wrapper, which make file_get_contents
use curl. i haven't tested with calling curl functions directly
php unset curl header too soon before curl make the request
expected order
Bug #55438 [Opn]: race condition: curlwapper is not sending http header randomly
Edit report at https://bugs.php.net/bug.php?id=55438&edit=1
ID: 55438
Updated by: pierr...@php.net
Reported by:xuefer at gmail dot com
Summary:race condition: curlwapper is not sending http
header randomly
Status: Open
Type: Bug
Package:cURL related
Operating System: gentoo
PHP Version:5.3.6
-Assigned To:
+Assigned To:pierrick
Block user comment: N
Private report: N
New Comment:
I tried to reproduce this bug but wasn't able to do it.
Could you give me more details on the libcurl version used by your PHP instance
?
And also, how do you make sure that the headers are not properly sent ?
Previous Comments:
[2012-12-19 04:33:11] phpnet at lostreality dot org
I submitted a patch that moves the slist from a local variable in
php_curl_stream_opener() into the php_curl_stream struct. The headers are no
longer cleared and freed at the end of php_curl_stream_opener(). The code to
free the slist is moved into php_curl_stream_close() instead. I'm not sure if
this is the best approach, but it clearly gives me a 100% success rate with
having headers get sent, where as I had a literal 0% success rate before (not
sure if there is really a race condition or not, just that the headers get
cleared and the slist freed before they get used.)
The test code I used was as follows (Actual cookie and URL redacted)
array('method' => 'GET', 'header' => 'Cookie: foo=bar'));
$ctx = stream_context_create($opt);
$f = fopen('http://www.example.com/', 'r', false, $ctx);
fread($f, 1); //work-around curl-wrappers bug where meta_data doesn't exist
until the stream is read
$data = stream_get_meta_data($f);
fclose($f);
var_dump($data);
?>
I compiled PHP with the following flags (not that I think anything matters to
this bug other than --with-curlwrappers):
--enable-static --with-mcrypt --with-ldap --with-iconv --enable-mbstring
--with-gd --enable-mbregex --with-zlib --with-imap --enable-ftp --with-gettext
--enable-sockets --with-mysql=/usr --enable-cgi --with-imap-ssl
--enable-sockets --with-pdo-mysql --with-openssl --with-kerberos --with-curl
--with-curlwrappers --with-tidy --with-pcre-regex --with-bz2 --enable-zip
--with-libdir=/lib64
[2012-12-18 19:29:56] phpnet at lostreality dot org
I think I am seeing this same problem too (On 5.3.10, but nothing has changed
in the source in 5.4.9 either).
Can you explain how this is happening, or suggest a work-around? I was digging
into the PHP source, expecting that the --with-curlwrappers option was
basically broken and incomplete. I was surprised to find the line:
curl_easy_setopt(curlstream->curl, CURLOPT_HTTPHEADER, slist);
Because that code all seems to indicate that the headers should be sent, but no
matter what I try, nothing I put in headers ever appears in the actual request.
I keep running tcpdump but I never see the headers I put in http->header.
[2011-08-17 11:45:54] xuefer at gmail dot com
sorry for the mismatch http url string. i was trying to remove some string for
privacy
[2011-08-17 11:38:50] xuefer at gmail dot com
Description:
background: php is configured with curl wrapper, which make file_get_contents
use curl. i haven't tested with calling curl functions directly
php unset curl header too soon before curl make the request
expected order: set header, build and send request. unset header
actual order 1: set header, build and send request. unset header (good)
actual order 2: set header, unset header, build and send request (bad)
"send request" comes after php "unset header"
curl behavior randomly, by sending request before or after php unset the header
Test script:
---
#!/usr/lib/php5.3/bin/php
http://localhost/";;
$context = stream_context_create(array(
'http' => array(
'header' => "Authorization: Basic " .
base64_encode("$username:$password")
)
));
$http_response_header = array();
$data = file_get_contents($authUrl, false, $context);
sleep(1);
}
?>
tcpdump -nilo dst port 80 -w- -s0
Expected result:
GET / HTTP/1.1
User-Agent: PHP/5.3.6-pl0-gentoo
Host: localhost
Accept: */*
Authorization: Basic
dGVzdDE6MTQzNjEuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4=
GET / HTTP/1.1
User-Agent: PHP/5.3.6-pl0-gentoo
Host: localhost
Accept: */*
Authorization: Basic
dGVzdDE6NTY3MDQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uL
Bug #63795 [Asn]: url-7.28.1 breaks PHP curl_getinfo and curl_multi_getcontent
Edit report at https://bugs.php.net/bug.php?id=63795&edit=1
ID: 63795
Updated by: pierr...@php.net
Reported by:blueness at gentoo dot org
Summary:url-7.28.1 breaks PHP curl_getinfo and
curl_multi_getcontent
Status: Assigned
Type: Bug
Package:cURL related
Operating System: Linux
PHP Version:5.4.9
Assigned To:pierrick
Block user comment: N
Private report: N
New Comment:
This bug was introduced when the support of the value 1 for
CURLOPT_SSL_VERIFYHOST was removed in 7.28.1.
In your code sample, you're using curl_setopt_array. How this function work
internally is that it will loop over all your options and set them one by one
on
your curl handle using the libcurl curl_easy_setopt function. If one of this
set
fail, the function will break the iteration and will return false.
In your case, when you're using libcurl 7.28.1, curl_setopt_array will fail
when
it will try to set CURLOPT_SSL_VERIFYHOST to 1, and then will not set
CURLOPT_HEADER. The result of your curl_exec function will then not include the
headers. Then when you remove the begining of your string to remove your
header,
you're in fact removing the begining of your content since there is no header
included in the original string.
If you move your CURLOPT_SSL_VERIFYHOST to the end of your array this should
fix
your problem. Can you confirm ?
I started a discussion on internal to see how we want to deal with this problem.
Previous Comments:
[2012-12-18 02:26:43] blueness at gentoo dot org
Description:
When php 5.4.9 is built against curl-7.28.1, curl_multi_getcontent($stuff) does
not return the full content of the web page but truncates some characters from
the beginning. See the following downstream bugs for more details:
https://sourceforge.net/p/curl/bugs/1172/
https://bugs.gentoo.org/show_bug.cgi?id=444788
In the gentoo bug, please look at comment #14 since it pin points the curl
commit that deprecated CURLOPT_SSL_VERIFYHOST=1 and led to the breakage in php.
Test script:
---
'http://www.google.ca',
CURLOPT_RETURNTRANSFER => 1,
CURLOPT_SSL_VERIFYHOST => 0,// these are the problem
CURLOPT_SSL_VERIFYPEER => 0,// toggle 0/1 to test
CURLOPT_HEADER => 1
);
curl_setopt_array($stuffs, $curl_options);
curl_multi_add_handle($cm, $stuffs);
do { curl_multi_exec($cm, $running); } while($running > 0);
$content = curl_multi_getcontent($stuffs);
$info = curl_getinfo($stuffs);
curl_multi_remove_handle($cm, $stuffs);
curl_multi_close($cm);
print_r($info);
// cuts off too much, the header size is incorrect
echo mb_substr($content, $info['header_size']);
?>
Expected result:
For the expected and actual results, please see
https://bugs.gentoo.org/show_bug.cgi?id=444788
comments #10-13
--
Edit this bug report at https://bugs.php.net/bug.php?id=63795&edit=1
Bug #55438 [Com]: race condition: curlwapper is not sending http header randomly
Edit report at https://bugs.php.net/bug.php?id=55438&edit=1
ID: 55438
Comment by: phpnet at lostreality dot org
Reported by:xuefer at gmail dot com
Summary:race condition: curlwapper is not sending http
header randomly
Status: Open
Type: Bug
Package:cURL related
Operating System: gentoo
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
I submitted a patch that moves the slist from a local variable in
php_curl_stream_opener() into the php_curl_stream struct. The headers are no
longer cleared and freed at the end of php_curl_stream_opener(). The code to
free the slist is moved into php_curl_stream_close() instead. I'm not sure if
this is the best approach, but it clearly gives me a 100% success rate with
having headers get sent, where as I had a literal 0% success rate before (not
sure if there is really a race condition or not, just that the headers get
cleared and the slist freed before they get used.)
The test code I used was as follows (Actual cookie and URL redacted)
array('method' => 'GET', 'header' => 'Cookie: foo=bar'));
$ctx = stream_context_create($opt);
$f = fopen('http://www.example.com/', 'r', false, $ctx);
fread($f, 1); //work-around curl-wrappers bug where meta_data doesn't exist
until the stream is read
$data = stream_get_meta_data($f);
fclose($f);
var_dump($data);
?>
I compiled PHP with the following flags (not that I think anything matters to
this bug other than --with-curlwrappers):
--enable-static --with-mcrypt --with-ldap --with-iconv --enable-mbstring
--with-gd --enable-mbregex --with-zlib --with-imap --enable-ftp --with-gettext
--enable-sockets --with-mysql=/usr --enable-cgi --with-imap-ssl
--enable-sockets --with-pdo-mysql --with-openssl --with-kerberos --with-curl
--with-curlwrappers --with-tidy --with-pcre-regex --with-bz2 --enable-zip
--with-libdir=/lib64
Previous Comments:
[2012-12-18 19:29:56] phpnet at lostreality dot org
I think I am seeing this same problem too (On 5.3.10, but nothing has changed
in the source in 5.4.9 either).
Can you explain how this is happening, or suggest a work-around? I was digging
into the PHP source, expecting that the --with-curlwrappers option was
basically broken and incomplete. I was surprised to find the line:
curl_easy_setopt(curlstream->curl, CURLOPT_HTTPHEADER, slist);
Because that code all seems to indicate that the headers should be sent, but no
matter what I try, nothing I put in headers ever appears in the actual request.
I keep running tcpdump but I never see the headers I put in http->header.
[2011-08-17 11:45:54] xuefer at gmail dot com
sorry for the mismatch http url string. i was trying to remove some string for
privacy
[2011-08-17 11:38:50] xuefer at gmail dot com
Description:
background: php is configured with curl wrapper, which make file_get_contents
use curl. i haven't tested with calling curl functions directly
php unset curl header too soon before curl make the request
expected order: set header, build and send request. unset header
actual order 1: set header, build and send request. unset header (good)
actual order 2: set header, unset header, build and send request (bad)
"send request" comes after php "unset header"
curl behavior randomly, by sending request before or after php unset the header
Test script:
---
#!/usr/lib/php5.3/bin/php
http://localhost/";;
$context = stream_context_create(array(
'http' => array(
'header' => "Authorization: Basic " .
base64_encode("$username:$password")
)
));
$http_response_header = array();
$data = file_get_contents($authUrl, false, $context);
sleep(1);
}
?>
tcpdump -nilo dst port 80 -w- -s0
Expected result:
GET / HTTP/1.1
User-Agent: PHP/5.3.6-pl0-gentoo
Host: localhost
Accept: */*
Authorization: Basic
dGVzdDE6MTQzNjEuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4=
GET / HTTP/1.1
User-Agent: PHP/5.3.6-pl0-gentoo
Host: localhost
Accept: */*
Authorization: Basic
dGVzdDE6NTY3MDQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4=
GET / HTTP/1.1
User-Agent: PHP/5.3.6-pl0-gentoo
Host: localhost
Accept: */*
Authorization: Basic
dGVzdDE6MTQzNjEuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4=
GET / HTTP/1.1
User-Agent: PHP/5.3.6-pl0-gentoo
Host: localhost
Accept: */*
Authorization:
Bug #63642 [Asn]: No "out of memory" error during ->fetchAll() from PostgreSQL
Edit report at https://bugs.php.net/bug.php?id=63642&edit=1
ID: 63642
User updated by:amex at bucksvsbytes dot com
Reported by:amex at bucksvsbytes dot com
Summary:No "out of memory" error during ->fetchAll() from
PostgreSQL
Status: Assigned
Type: Bug
Package:PDO related
Operating System: Ubuntu
PHP Version:5.3.19
Assigned To:willfitch
Block user comment: N
Private report: N
New Comment:
Yes, my PHP development system displays every error, warning, and notice on
screen.
Previous Comments:
[2012-12-18 21:17:38] willfi...@php.net
Without looking into this too far, have you verified that
error_reporting/display_errors are set to levels that are sufficient to display
or
record this error?
[2012-11-29 00:25:41] amex at bucksvsbytes dot com
Description:
In PHP 5.3.10 and PostgreSQL 9.1, when executing PDOStatement::fetchAll(), if
the retrieved data busts the PHP memory limit, the script dies quietly, without
throwing an "out of memory" error.
Test script:
---
//ini_set('memory_limit','256M');
$dsn=;//appropriate Data Source Name string
$sql=;//any query that returns slightly more data than the PHP memory limit
allows (default limit is 128 MB on my server)
$db=new PDO($dsn);
$result=$db->query($sql);
$datarray=$result->fetchAll();//fetch all rows into an array
Expected result:
When fetchAll() retrieves too much data, the script dies quietly, instead of
throwing an "out of memory" error.
When I uncomment the first line, the script runs to completion, thus proving
that the quiet death was due to lack of memory.
The problem seems to relate to the postgresql driver, as the same thing happens
when I use pg_connect/pg_query/pg_fetch_all instead of PDO to get data from the
same query.
This is the only PHP "out of memory" condition I've ever seen where no error is
thrown.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63642&edit=1
Bug #49664 [Com]: Clone causes Segmentation fault
Edit report at https://bugs.php.net/bug.php?id=49664&edit=1
ID: 49664
Comment by: kurt at kurtrose dot com
Reported by:patrik dot lermon at gmail dot com
Summary:Clone causes Segmentation fault
Status: Not a bug
Type: Bug
Package:Reproducible crash
Operating System: Linux
PHP Version:5.*, 6 (2009-09-20)
Block user comment: N
Private report: N
New Comment:
Python handles this kind of recursion fine:
class F(object):
def __repr__(self): return self.__repr__()
>>> repr(F())
File "", line 2, in __repr__
File "", line 2, in __repr__
...
File "", line 2, in __repr__
File "", line 2, in __repr__
RuntimeError: maximum recursion depth exceeded
No segfault.
Previous Comments:
[2009-10-19 15:31:17] patrik dot lermon at gmail dot com
I don't agree. Perhaps my knowledge is not detailed enough, but an infinte
recursion should:
a) run out of memory and die, or
b) detect the recursion and die.
In both these cases PHP should die in a controlled manner, not segfault.
My understanding is that segfault is never ok - that means the code is faulty.
[2009-10-19 15:10:24] j...@php.net
Infinite recursion crashes. There's no fix for that.
[2009-09-28 12:06:43] patrik dot lermon at gmail dot com
I get the same result with http://snaps.php.net/php5.3-latest.tar.gz
on Slackware.
[2009-09-25 07:50:31] patrik dot lermon at gmail dot com
I am aware that the cloning will be recursive in some circumstances, but PHP
should not segfault because of this.
[2009-09-25 07:46:10] patrik dot lermon at gmail dot com
Description:
Under certain circumstances the clone keyword causes a Segmentation fault. This
code is reproducible and tested with the same result on:
- Ubuntu 9.04 / PHP 5.2.10 (cli) (built: Jun 22 2009 12:32:02)
- Slackware 13.0.0.0.0 / PHP 5.3.0 (cli) (built: Sep 25 2009 08:58:26) (DEBUG)
- Mac OS X 10.5.8 / PHP 5.2.10 (cli) (built: Aug 24 2009 12:47:12)
- Mac OS X 10.6.1 / PHP 5.3.0 (cli) (built: Jul 19 2009 00:34:29)
The Ubuntu and Mac OS X versions are standard builds from Zend, and the
Slackware is built by me like this:
EXTENSION_DIR=/usr/lib/php/extensions \
CFLAGS="-O2 -march=i486 -mtune=i686" \
./configure \
--enable-force-cgi-redirect \
--enable-pcntl \
--enable-sigchild \
--prefix=/usr \
--libdir=/usr/lib \
--with-libdir=lib \
--sysconfdir=/etc \
--disable-safe-mode \
--disable-magic-quotes \
--enable-zend-multibyte \
--enable-mbregex \
--enable-tokenizer=shared \
--with-config-file-scan-dir=/etc/php \
--with-config-file-path=/etc/httpd \
--enable-mod_charset \
--with-layout=PHP \
--enable-sigchild \
--enable-xml \
--with-libxml-dir=/usr \
--enable-simplexml \
--enable-spl \
--enable-filter \
--enable-debug \
--with-openssl=shared \
--with-pcre-regex=/usr \
--with-zlib=shared,/usr \
--enable-bcmath=shared \
--with-bz2=shared,/usr \
--enable-calendar=shared \
--enable-ctype=shared \
--with-curl=shared \
--with-curlwrappers \
--with-mcrypt=/usr \
--enable-dba=shared \
--with-gdbm=/usr \
--with-db4=/usr \
--enable-exif=shared \
--enable-ftp=shared \
--with-gd=shared \
--with-jpeg-dir=/usr \
--with-png-dir=/usr \
--with-zlib-dir=/usr \
--with-xpm-dir=/usr \
--with-freetype-dir=/usr \
--with-t1lib=/usr \
--enable-gd-native-ttf \
--enable-gd-jis-conv \
--with-gettext=shared,/usr \
--with-gmp=shared,/usr \
--with-iconv=shared \
--with-imap-ssl=/usr \
--with-imap=/usr/local/lib/c-client \
--with-ldap=shared \
--enable-mbstring=shared \
--enable-hash \
--with-mysql=shared,/usr \
--with-mysqli=shared,/usr/bin/mysql_config \
--enable-pdo=shared \
--with-pdo-mysql=shared,/usr \
--with-pdo-sqlite=shared \
--with-pspell=shared,/usr \
--with-mm=/usr \
--enable-shmop=shared \
--with-snmp=shared,/usr \
--enable-soap=shared \
--enable-sockets \
--with-sqlite=shared \
--enable-sqlite-utf8 \
--with-regex=php \
--enable-sysvmsg \
--enable-sysvsem \
--enable-sysvshm \
--enable-wddx=shared \
--with-xsl=shared,/usr \
--enable-zip=shared \
--with-tsrm-pthreads \
--enable-shared=yes \
--enable-static=no \
--with-gnu-ld \
--with-pic \
--build=i486-slackware-linux
Reproduce code:
---
previous != NULL ? $this->previous = clone $this->previous :
$this->previous = NULL;
$this->next != NULL ? $this->next = clone $this->next : $this->next =
NULL;
}
public function __toString() {
return '[' . ($this->previous != NULL ? '<' : '-') . ' ' . ($this->next
!= NULL ? '>' : '-') . ']';
}
}
// Create some test objects
$a = new Test(); $b = new Test();
// Link them together
$a->next =& $b; $b->previo
Bug #63463 [Nab]: ReflectionProperty::setValue and ::getValue trigger magic methods
Edit report at https://bugs.php.net/bug.php?id=63463&edit=1 ID: 63463 User updated by:ocramius at gmail dot com Reported by:ocramius at gmail dot com Summary:ReflectionProperty::setValue and ::getValue trigger magic methods Status: Not a bug Type: Bug Package:Reflection related Operating System: Irrelevant PHP Version:5.4.8 Block user comment: N Private report: N New Comment: Isn't reflection able to handle properties in a different way from how userland code acts? I wouldn't consider Reflection at the same level of other code, or at least I'm not aware of any way of achieving the same functionality without having access to internal APIs. I'm not denying the fact that this is probably a design issue and that it would require major refactoring to workaround it, but the fact that such effort is needed doesn't mean that this is not a bug. Want to mark it as improvement instead? Or as a documentation issue and therefore language limitation (with relative improvement issue)? Previous Comments: [2012-12-18 21:15:18] s...@php.net I am sorry, but I think your opinion is incorrect. Reflection works the same way and uses the same engine methods as other ways of accessing properties. Making Reflection work differently from the rest of the object model would require special exceptions in all object engine for Reflection and seems to make little sense to me in general. Reflection is just another way of doing the same thing as regular property access. I am sorry that your code does not work as you wanted it to, and you are welcome to propose ways to improve it, including participating in getters/setters discussion ongoing, but I do not think in this particular case reflection is doing something wrong. In any case, it is not a bug as the code is doing exactly as the intent of the code was for it to do. [2012-12-10 02:04:46] ocramius at gmail dot com @stas let me put it into a more "practical" use case I currently have: I use reflection to populate instances of proxy objects that have "lazy" marked properties unset at instantiation time. This is good to achieve lazy loading of public properties, but any r/w access to the property itself via reflection triggers `__get` or `__set`. This makes it impossible to use reflection to populate the property. I worked around it by disabling `__get` in particular situations (see https://github.com/Ocramius/common/blob/DCOM-96/lib/Doctrine/Common/Reflection/RuntimePublicReflectionProperty.php), but at a terrible cost in performance terms and broken behaviour in rare cases. Back to the issue itself: I consider Reflection as my last resource to access and modify status of objects without affecting anything else within my environment. Having reflection trigger any logic during an assignment is an unwanted and dangerous behaviour in my opinion. [2012-12-10 01:51:32] s...@php.net I'm not sure why you think this is what should be happening. When you unset properties, they are no longer set. And when you access unset properties, magic methods kick in. So where's the problem here? [2012-11-08 06:22:43] ocramius at gmail dot com I've added the failing test case as a PR at https://github.com/php/php-src/pull/230 [2012-11-08 06:15:03] ocramius at gmail dot com Description: When unset properties are requested, ReflectionProperty::setValue and ReflectionProperty::getValue trigger __get and __set magic methods. Test script: --- https://gist.github.com/4037155 Expected result: The test script should report NULL for each of the requested values, and never call __set nor __get Actual result: -- __set and __get are called when ReflectionProperty tries to read or write to the requested properties. -- Edit this bug report at https://bugs.php.net/bug.php?id=63463&edit=1
Bug #63719 [Opn->Fbk]: mail function becomes slow until apache restart
Edit report at https://bugs.php.net/bug.php?id=63719&edit=1 ID: 63719 Updated by: willfi...@php.net Reported by:skunk at ipfrom dot com Summary:mail function becomes slow until apache restart -Status: Open +Status: Feedback Type: Bug Package:Mail related Operating System: gentoo linux PHP Version:5.3.19 Block user comment: N Private report: N New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. You need to provide a sample script that's causing the issue. This sounds like an environment specific problem. Previous Comments: [2012-12-07 13:38:20] skunk at ipfrom dot com i forgot to say the sendmail command works fine and even executing from the command line a script containing the mail() function is practically instantaneous, it happens only if apache (2.2.23) executes the script. [2012-12-07 13:12:58] skunk at ipfrom dot com Description: i'm seeing this on more than one production servers: after some days of uptime the mail() function starts to take about a minute to execute and only a restart of apache (prefork) makes it fast again. one of the web servers is running roundcube which has the possibility to either use the mail() function or to connect directly to a smtp server, with the former after few days sending a mail becomes very slow while with the latest it's always fast, on a side note, when the slowness starts happening apache takes a long time to kill all processes on restart. thank you. Test script: --- sorry, i'm unable to replicate this issue because it happens on production servers with real traffic. Expected result: mail() function should exec fast Actual result: -- when mail() slows down a restart of apache is required -- Edit this bug report at https://bugs.php.net/bug.php?id=63719&edit=1
Bug #63800 [Com]: CURLOPT_MUTE not defined but mentioned on http://nz1.php.net/manual/en/function
Edit report at https://bugs.php.net/bug.php?id=63800&edit=1 ID: 63800 Comment by: hugh at davenport dot net dot nz Reported by:hugh at davenport dot net dot nz Summary:CURLOPT_MUTE not defined but mentioned on http://nz1.php.net/manual/en/function Status: Open Type: Bug Package:cURL related Operating System: Linux PHP Version:5.4.9 Block user comment: N Private report: N New Comment: Oh, the version is from debian testing PHP 5.4.4-10 (cli) (built: Nov 24 2012 11:21:26) Previous Comments: [2012-12-18 21:35:38] hugh at davenport dot net dot nz Description: echo -e 'http://localhost";);curl_setopt($ch, CURLOPT_MUTE, true);\n?>' | php PHP Notice: Use of undefined constant CURLOPT_MUTE - assumed 'CURLOPT_MUTE' in - on line 2 PHP Warning: curl_setopt() expects parameter 2 to be long, string given in - on line 2 Test script: --- echo -e 'http://localhost";);curl_setopt($ch, CURLOPT_MUTE, true);\n?>' | php PHP Notice: Use of undefined constant CURLOPT_MUTE - assumed 'CURLOPT_MUTE' in - on line 2 PHP Warning: curl_setopt() expects parameter 2 to be long, string given in - on line 2 Expected result: CURLOPT_MUTE is defined, and setting that option mutes cURL Actual result: -- undefined constant, setopt fails -- Edit this bug report at https://bugs.php.net/bug.php?id=63800&edit=1
[PHP-BUG] Bug #63800 [NEW]: CURLOPT_MUTE not defined but mentioned on http://nz1.php.net/manual/en/function
From: hugh at davenport dot net dot nz Operating system: Linux PHP version: 5.4.9 Package: cURL related Bug Type: Bug Bug description:CURLOPT_MUTE not defined but mentioned on http://nz1.php.net/manual/en/function Description: echo -e 'http://localhost";);curl_setopt($ch, CURLOPT_MUTE, true);\n?>' | php PHP Notice: Use of undefined constant CURLOPT_MUTE - assumed 'CURLOPT_MUTE' in - on line 2 PHP Warning: curl_setopt() expects parameter 2 to be long, string given in - on line 2 Test script: --- echo -e 'http://localhost";);curl_setopt($ch, CURLOPT_MUTE, true);\n?>' | php PHP Notice: Use of undefined constant CURLOPT_MUTE - assumed 'CURLOPT_MUTE' in - on line 2 PHP Warning: curl_setopt() expects parameter 2 to be long, string given in - on line 2 Expected result: CURLOPT_MUTE is defined, and setting that option mutes cURL Actual result: -- undefined constant, setopt fails -- Edit bug report at https://bugs.php.net/bug.php?id=63800&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63800&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63800&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63800&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63800&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63800&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63800&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63800&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63800&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63800&r=support Expected behavior: https://bugs.php.net/fix.php?id=63800&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63800&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63800&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63800&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63800&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63800&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63800&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63800&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63800&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63800&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63800&r=mysqlcfg
Req #63799 [Opn]: Make interface for prepared statements easier
Edit report at https://bugs.php.net/bug.php?id=63799&edit=1
ID: 63799
User updated by:thbley at gmail dot com
Reported by:thbley at gmail dot com
Summary:Make interface for prepared statements easier
Status: Open
Type: Feature/Change Request
Package:MySQLi related
Operating System: win7 x64
PHP Version:5.5.0alpha1
Block user comment: N
Private report: N
New Comment:
or sprintf-style instead of auto-detection:
foreach ($db->query('select * from bla where someint=%d and somechar=%s',
MYSQLI_STORE_RESULT, [10, 'hello_world']) as $row) {...}
Previous Comments:
[2012-12-18 21:27:07] thbley at gmail dot com
Description:
Please offer an easier interface to run prepared statements, e.g.
$db = new mysqli_db('127.0.0.1', 'root', 'some_pw', 'test');
foreach ($db->query('select * from bla where someint=? and somechar=?',
MYSQLI_STORE_RESULT, [10, 'hello_world']) as $row) {...}
--
Edit this bug report at https://bugs.php.net/bug.php?id=63799&edit=1
[PHP-BUG] Req #63799 [NEW]: Make interface for prepared statements easier
From: thbley at gmail dot com
Operating system: win7 x64
PHP version: 5.5.0alpha1
Package: MySQLi related
Bug Type: Feature/Change Request
Bug description:Make interface for prepared statements easier
Description:
Please offer an easier interface to run prepared statements, e.g.
$db = new mysqli_db('127.0.0.1', 'root', 'some_pw', 'test');
foreach ($db->query('select * from bla where someint=? and somechar=?',
MYSQLI_STORE_RESULT, [10, 'hello_world']) as $row) {...}
--
Edit bug report at https://bugs.php.net/bug.php?id=63799&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63799&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63799&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63799&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63799&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63799&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63799&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63799&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63799&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63799&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63799&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63799&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63799&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63799&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63799&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63799&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63799&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63799&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63799&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63799&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63799&r=mysqlcfg
Bug #62571 [Opn->Asn]: Postgres PDO connections fail after SIGCHLD called
Edit report at https://bugs.php.net/bug.php?id=62571&edit=1 ID: 62571 Updated by: willfi...@php.net Reported by:spiros_ioannou at yahoo dot gr Summary:Postgres PDO connections fail after SIGCHLD called -Status: Open +Status: Assigned Type: Bug Package:PDO related Operating System: Linux PHP Version:5.3.14 -Assigned To: +Assigned To:willfitch Block user comment: N Private report: N New Comment: Can you provide a test script for your issue? Previous Comments: [2012-07-21 11:46:39] spiros_ioannou at yahoo dot gr When using persistent connections, even if reopening a new connection *after* forking, the connection fails. The only way to have DB connections is to reopen them after forking, with PDO::ATTR_PERSISTENT => false [2012-07-16 00:12:14] spiros_ioannou at yahoo dot gr I revoke the statement of SIGCHLD, it happens even without the handler in some situations, the behaviour seems erratic. Perhaps the database connection is shared with the children, and when the child dies the db variable the connection is closed. I tried closing the DB connection first thing on the child but with no results, the error still appears when the child dies. [2012-07-15 23:27:50] spiros_ioannou at yahoo dot gr Description: When using pcntl_fork to fork children, and *only* the parent uses the Postgres PDO database connection, the connection becomes unusable after the first child exits and the signal handler is called. If SIGCHLD signal handler is omitted PDO works normally for parent. Tested with and without persistent connections. Possible relevant bugs: 48447, 45797 Actual result: -- PHP Warning: PDOStatement::execute(): SQLSTATE[HY000]: General error: 7 server closed the connection unexpectedly This probably means the server terminated abnormally -- Edit this bug report at https://bugs.php.net/bug.php?id=62571&edit=1
Req #62911 [ReO->Wfx]: Add DateTime::__toString()
Edit report at https://bugs.php.net/bug.php?id=62911&edit=1 ID: 62911 Updated by: willfi...@php.net Reported by:bdurand-php at ssji dot net Summary:Add DateTime::__toString() -Status: Re-Opened +Status: Wont fix Type: Feature/Change Request Package:Date/time related PHP Version:Irrelevant Assigned To:willfitch Block user comment: N Private report: N Previous Comments: [2012-09-01 10:18:12] willfi...@php.net I have reopened this as I've introduced an RFC here: https://wiki.php.net/rfc/datetime_tostring. [2012-08-27 17:50:28] willfi...@php.net It's not a matter of whether PHP can or not; it's a matter of gathering a consensus among developers on what standard *should* be default. I personally agree with adding __tostring, but this needs to be proposed in an RFC, which I will do tonight. [2012-08-27 17:27:15] bdurand-php at ssji dot net The timezone can be defined in the constructor, with the directive tz php.ini, or with date_default_timezone_get() function. A DateTime is a string in fact, so it's logic to have a string cast available. Which format is more standard than ISO format? Another common format is the timestamp, but it can not represent all dates. Other languages did this behavior ââlike python. Why PHP can't? I know that I can subclass any (core) class... it's not the problem here. [2012-08-27 15:24:45] willfi...@php.net Would it be worth investing time in adding a setter/constructor option for a default format type? Setting no default could fallback to one of the constants (which still doesn't resolve the non-consensus issue). [2012-08-27 15:17:38] der...@php.net We have had this a few times now, and we should not do this. The main reason is that we will never be able to come to a consensus on which format to show. It certainly shouldn't have anything that destroys the encoded timezone identifiers. It's perfectly possible to subclass DateTime yourself and add a __toString() that returns the datetime in your preferred format though. 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=62911 -- Edit this bug report at https://bugs.php.net/bug.php?id=62911&edit=1
Bug #63642 [Opn->Asn]: No "out of memory" error during ->fetchAll() from PostgreSQL
Edit report at https://bugs.php.net/bug.php?id=63642&edit=1
ID: 63642
Updated by: willfi...@php.net
Reported by:amex at bucksvsbytes dot com
Summary:No "out of memory" error during ->fetchAll() from
PostgreSQL
-Status: Open
+Status: Assigned
Type: Bug
Package:PDO related
Operating System: Ubuntu
PHP Version:5.3.19
-Assigned To:
+Assigned To:willfitch
Block user comment: N
Private report: N
Previous Comments:
[2012-12-18 21:17:38] willfi...@php.net
Without looking into this too far, have you verified that
error_reporting/display_errors are set to levels that are sufficient to display
or
record this error?
[2012-11-29 00:25:41] amex at bucksvsbytes dot com
Description:
In PHP 5.3.10 and PostgreSQL 9.1, when executing PDOStatement::fetchAll(), if
the retrieved data busts the PHP memory limit, the script dies quietly, without
throwing an "out of memory" error.
Test script:
---
//ini_set('memory_limit','256M');
$dsn=;//appropriate Data Source Name string
$sql=;//any query that returns slightly more data than the PHP memory limit
allows (default limit is 128 MB on my server)
$db=new PDO($dsn);
$result=$db->query($sql);
$datarray=$result->fetchAll();//fetch all rows into an array
Expected result:
When fetchAll() retrieves too much data, the script dies quietly, instead of
throwing an "out of memory" error.
When I uncomment the first line, the script runs to completion, thus proving
that the quiet death was due to lack of memory.
The problem seems to relate to the postgresql driver, as the same thing happens
when I use pg_connect/pg_query/pg_fetch_all instead of PDO to get data from the
same query.
This is the only PHP "out of memory" condition I've ever seen where no error is
thrown.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63642&edit=1
Bug #63642 [Com]: No "out of memory" error during ->fetchAll() from PostgreSQL
Edit report at https://bugs.php.net/bug.php?id=63642&edit=1
ID: 63642
Comment by: willfi...@php.net
Reported by:amex at bucksvsbytes dot com
Summary:No "out of memory" error during ->fetchAll() from
PostgreSQL
Status: Open
Type: Bug
Package:PDO related
Operating System: Ubuntu
PHP Version:5.3.19
Block user comment: N
Private report: N
New Comment:
Without looking into this too far, have you verified that
error_reporting/display_errors are set to levels that are sufficient to display
or
record this error?
Previous Comments:
[2012-11-29 00:25:41] amex at bucksvsbytes dot com
Description:
In PHP 5.3.10 and PostgreSQL 9.1, when executing PDOStatement::fetchAll(), if
the retrieved data busts the PHP memory limit, the script dies quietly, without
throwing an "out of memory" error.
Test script:
---
//ini_set('memory_limit','256M');
$dsn=;//appropriate Data Source Name string
$sql=;//any query that returns slightly more data than the PHP memory limit
allows (default limit is 128 MB on my server)
$db=new PDO($dsn);
$result=$db->query($sql);
$datarray=$result->fetchAll();//fetch all rows into an array
Expected result:
When fetchAll() retrieves too much data, the script dies quietly, instead of
throwing an "out of memory" error.
When I uncomment the first line, the script runs to completion, thus proving
that the quiet death was due to lack of memory.
The problem seems to relate to the postgresql driver, as the same thing happens
when I use pg_connect/pg_query/pg_fetch_all instead of PDO to get data from the
same query.
This is the only PHP "out of memory" condition I've ever seen where no error is
thrown.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63642&edit=1
Bug #63463 [Opn->Nab]: ReflectionProperty::setValue and ::getValue trigger magic methods
Edit report at https://bugs.php.net/bug.php?id=63463&edit=1 ID: 63463 Updated by: s...@php.net Reported by:ocramius at gmail dot com Summary:ReflectionProperty::setValue and ::getValue trigger magic methods -Status: Open +Status: Not a bug Type: Bug Package:Reflection related Operating System: Irrelevant PHP Version:5.4.8 Block user comment: N Private report: N New Comment: I am sorry, but I think your opinion is incorrect. Reflection works the same way and uses the same engine methods as other ways of accessing properties. Making Reflection work differently from the rest of the object model would require special exceptions in all object engine for Reflection and seems to make little sense to me in general. Reflection is just another way of doing the same thing as regular property access. I am sorry that your code does not work as you wanted it to, and you are welcome to propose ways to improve it, including participating in getters/setters discussion ongoing, but I do not think in this particular case reflection is doing something wrong. In any case, it is not a bug as the code is doing exactly as the intent of the code was for it to do. Previous Comments: [2012-12-10 02:04:46] ocramius at gmail dot com @stas let me put it into a more "practical" use case I currently have: I use reflection to populate instances of proxy objects that have "lazy" marked properties unset at instantiation time. This is good to achieve lazy loading of public properties, but any r/w access to the property itself via reflection triggers `__get` or `__set`. This makes it impossible to use reflection to populate the property. I worked around it by disabling `__get` in particular situations (see https://github.com/Ocramius/common/blob/DCOM-96/lib/Doctrine/Common/Reflection/RuntimePublicReflectionProperty.php), but at a terrible cost in performance terms and broken behaviour in rare cases. Back to the issue itself: I consider Reflection as my last resource to access and modify status of objects without affecting anything else within my environment. Having reflection trigger any logic during an assignment is an unwanted and dangerous behaviour in my opinion. [2012-12-10 01:51:32] s...@php.net I'm not sure why you think this is what should be happening. When you unset properties, they are no longer set. And when you access unset properties, magic methods kick in. So where's the problem here? [2012-11-08 06:22:43] ocramius at gmail dot com I've added the failing test case as a PR at https://github.com/php/php-src/pull/230 [2012-11-08 06:15:03] ocramius at gmail dot com Description: When unset properties are requested, ReflectionProperty::setValue and ReflectionProperty::getValue trigger __get and __set magic methods. Test script: --- https://gist.github.com/4037155 Expected result: The test script should report NULL for each of the requested values, and never call __set nor __get Actual result: -- __set and __get are called when ReflectionProperty tries to read or write to the requested properties. -- Edit this bug report at https://bugs.php.net/bug.php?id=63463&edit=1
[PHP-BUG] Req #63798 [NEW]: Add dbname to mysqli_prop
From: thbley at gmail dot com
Operating system: win7 x64
PHP version: 5.5.0alpha1
Package: MySQLi related
Bug Type: Feature/Change Request
Bug description:Add dbname to mysqli_prop
Description:
The properties of the Mysqli object already contain server-info,
server-version, errors, etc., but not the current (selected) database.
It would be great if dbname could be added to mysqli properties.
With the property it gets easier to check if the right database was
selected or if none was selected.
Test script:
---
PHP code looks like this:
class mysqli_db extends mysqli {
public function __construct($host=null, $user=null, $pw=null, $db=null)
{
call_user_func_array("parent::__construct", func_get_args());
$this->db = $db;
}
// same for real_connect() ...
public function select_db($db) {
parent::select_db($db);
$this->db = $db;
}
}
$db = new mysqli_db('127.0.0.1', 'root', '', 'test');
echo $db->db; // test
$db->select_db('test2');
echo $db->db; // test2
--
Edit bug report at https://bugs.php.net/bug.php?id=63798&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63798&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63798&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63798&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63798&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63798&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63798&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63798&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63798&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63798&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63798&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63798&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63798&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63798&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63798&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63798&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63798&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63798&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63798&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63798&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63798&r=mysqlcfg
Bug #55438 [Com]: race condition: curlwapper is not sending http header randomly
Edit report at https://bugs.php.net/bug.php?id=55438&edit=1
ID: 55438
Comment by: phpnet at lostreality dot org
Reported by:xuefer at gmail dot com
Summary:race condition: curlwapper is not sending http
header randomly
Status: Open
Type: Bug
Package:cURL related
Operating System: gentoo
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
I think I am seeing this same problem too (On 5.3.10, but nothing has changed
in the source in 5.4.9 either).
Can you explain how this is happening, or suggest a work-around? I was digging
into the PHP source, expecting that the --with-curlwrappers option was
basically broken and incomplete. I was surprised to find the line:
curl_easy_setopt(curlstream->curl, CURLOPT_HTTPHEADER, slist);
Because that code all seems to indicate that the headers should be sent, but no
matter what I try, nothing I put in headers ever appears in the actual request.
I keep running tcpdump but I never see the headers I put in http->header.
Previous Comments:
[2011-08-17 11:45:54] xuefer at gmail dot com
sorry for the mismatch http url string. i was trying to remove some string for
privacy
[2011-08-17 11:38:50] xuefer at gmail dot com
Description:
background: php is configured with curl wrapper, which make file_get_contents
use curl. i haven't tested with calling curl functions directly
php unset curl header too soon before curl make the request
expected order: set header, build and send request. unset header
actual order 1: set header, build and send request. unset header (good)
actual order 2: set header, unset header, build and send request (bad)
"send request" comes after php "unset header"
curl behavior randomly, by sending request before or after php unset the header
Test script:
---
#!/usr/lib/php5.3/bin/php
http://localhost/";;
$context = stream_context_create(array(
'http' => array(
'header' => "Authorization: Basic " .
base64_encode("$username:$password")
)
));
$http_response_header = array();
$data = file_get_contents($authUrl, false, $context);
sleep(1);
}
?>
tcpdump -nilo dst port 80 -w- -s0
Expected result:
GET / HTTP/1.1
User-Agent: PHP/5.3.6-pl0-gentoo
Host: localhost
Accept: */*
Authorization: Basic
dGVzdDE6MTQzNjEuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4=
GET / HTTP/1.1
User-Agent: PHP/5.3.6-pl0-gentoo
Host: localhost
Accept: */*
Authorization: Basic
dGVzdDE6NTY3MDQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4=
GET / HTTP/1.1
User-Agent: PHP/5.3.6-pl0-gentoo
Host: localhost
Accept: */*
Authorization: Basic
dGVzdDE6MTQzNjEuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4=
GET / HTTP/1.1
User-Agent: PHP/5.3.6-pl0-gentoo
Host: localhost
Accept: */*
Authorization: Basic
dGVzdDE6NTY3MDQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4=
Actual result:
--
GET / HTTP/1.1
User-Agent: PHP/5.3.6-pl0-gentoo
Host: localhost
Accept: */*
Authorization: Basic
dGVzdDE6MTQzNjEuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4=
GET / HTTP/1.1
User-Agent: PHP/5.3.6-pl0-gentoo
Host: localhost
Accept: */*
Authorization: Basic
dGVzdDE6NTY3MDQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4=
GET / HTTP/1.1
User-Agent: PHP/5.3.6-pl0-gentoo
Host: localhost
Accept: */*
GET / HTTP/1.1
User-Agent: PHP/5.3.6-pl0-gentoo
Host: localhost
Accept: */*
gdb --args /usr/lib/php5.3/bin/php.debug test.php
(gdb) l /usr/src/debug/dev-lang/php-5.3.6/sapis-build/cli/ext/curl/streams.c:367
360 slist =
curl_slist_append(slist,
trimmed);
361 efree(trimmed);
362 p = php_strtok_r(NULL, "\r\n",
&token);
363 }
364 efree(copy_ctx_opt);
365 }
366 if (slist) {
367 curl_easy_setopt(curlstream->curl,
CURLOPT_HTTPHEADER, slist);
368 }
369 }
370 if (SUCCESS == php_stream_context_get_option(context,
"http", "method", &ctx_opt) &&
Bug #63766 [Nab]: sftp upload CURLOPT_URL errors with code 79 with directory path
Edit report at https://bugs.php.net/bug.php?id=63766&edit=1
ID: 63766
User updated by:mattsch at gmail dot com
Reported by:mattsch at gmail dot com
Summary:sftp upload CURLOPT_URL errors with code 79 with
directory path
Status: Not a bug
Type: Bug
Package:cURL related
Operating System: Gentoo
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
Also the same thing happens when using scp://. What I don't understand is if I
were to upload the file on the command line with scp without specifying a
filename but rather just a destination directory, the file would upload. So
why can't I expect curl to do the same when using the same protocol?
Previous Comments:
[2012-12-18 15:55:52] mattsch at gmail dot com
In addition, if I modify the test script and it with a slash at the end, it
also fails in the same way:
upload('sftp://domain.tld:/tmp/');
[2012-12-18 15:49:54] mattsch at gmail dot com
That does not explain why it fails when you try to upload to a directory. So
what you're saying is this is not a bug because it's not possible to do this
with curl and you must always specify a url with a filename to upload a file?
And if that's the case, why is it not possible to upload a file to a directory?
[2012-12-18 07:20:48] paj...@php.net
See previous comments
[2012-12-18 07:11:27] bag...@php.net
The CURLOPT_URL option is of course to generically set a URL to work with.
libcurl accepts whatever URL you set and will try to work on it once you ask
curl to perform on it.
A URL that ends with a slash is treated as a directory by libcurl when you're
downloading something from it. It will then (depending on protocol) ask for a
directory listing instead of trying to fetch a file with that name.
libcurl assumes the users knows what (s)he is doing and will try to perform the
requested operation on the given URL. Uploading to a directory name is probably
going to fail on most systems.
[2012-12-17 14:48:16] mattsch at gmail dot com
Could you elaborate as to why this would be a bad url? The documentation on
the curl website seems to indicate that you can specify a url without a
filename at the end but then the examples are not specific to upload:
http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTURL
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=63766
--
Edit this bug report at https://bugs.php.net/bug.php?id=63766&edit=1
Bug #63766 [Nab]: sftp upload CURLOPT_URL errors with code 79 with directory path
Edit report at https://bugs.php.net/bug.php?id=63766&edit=1
ID: 63766
User updated by:mattsch at gmail dot com
Reported by:mattsch at gmail dot com
Summary:sftp upload CURLOPT_URL errors with code 79 with
directory path
Status: Not a bug
Type: Bug
Package:cURL related
Operating System: Gentoo
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
In addition, if I modify the test script and it with a slash at the end, it
also fails in the same way:
upload('sftp://domain.tld:/tmp/');
Previous Comments:
[2012-12-18 15:49:54] mattsch at gmail dot com
That does not explain why it fails when you try to upload to a directory. So
what you're saying is this is not a bug because it's not possible to do this
with curl and you must always specify a url with a filename to upload a file?
And if that's the case, why is it not possible to upload a file to a directory?
[2012-12-18 07:20:48] paj...@php.net
See previous comments
[2012-12-18 07:11:27] bag...@php.net
The CURLOPT_URL option is of course to generically set a URL to work with.
libcurl accepts whatever URL you set and will try to work on it once you ask
curl to perform on it.
A URL that ends with a slash is treated as a directory by libcurl when you're
downloading something from it. It will then (depending on protocol) ask for a
directory listing instead of trying to fetch a file with that name.
libcurl assumes the users knows what (s)he is doing and will try to perform the
requested operation on the given URL. Uploading to a directory name is probably
going to fail on most systems.
[2012-12-17 14:48:16] mattsch at gmail dot com
Could you elaborate as to why this would be a bad url? The documentation on
the curl website seems to indicate that you can specify a url without a
filename at the end but then the examples are not specific to upload:
http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTURL
[2012-12-17 12:17:00] bag...@php.net
This is not a libcurl bug. If you think about it for a while, libcurl doesn't
know the 'foo' name, it is only given the (bad) URL and it cannot but to fail
in
this case.
I'm also convinced you can see the same problem with other protocols than SFTP
for the same reason.
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=63766
--
Edit this bug report at https://bugs.php.net/bug.php?id=63766&edit=1
Bug #63766 [Nab]: sftp upload CURLOPT_URL errors with code 79 with directory path
Edit report at https://bugs.php.net/bug.php?id=63766&edit=1 ID: 63766 User updated by:mattsch at gmail dot com Reported by:mattsch at gmail dot com Summary:sftp upload CURLOPT_URL errors with code 79 with directory path Status: Not a bug Type: Bug Package:cURL related Operating System: Gentoo PHP Version:5.4.9 Block user comment: N Private report: N New Comment: That does not explain why it fails when you try to upload to a directory. So what you're saying is this is not a bug because it's not possible to do this with curl and you must always specify a url with a filename to upload a file? And if that's the case, why is it not possible to upload a file to a directory? Previous Comments: [2012-12-18 07:20:48] paj...@php.net See previous comments [2012-12-18 07:11:27] bag...@php.net The CURLOPT_URL option is of course to generically set a URL to work with. libcurl accepts whatever URL you set and will try to work on it once you ask curl to perform on it. A URL that ends with a slash is treated as a directory by libcurl when you're downloading something from it. It will then (depending on protocol) ask for a directory listing instead of trying to fetch a file with that name. libcurl assumes the users knows what (s)he is doing and will try to perform the requested operation on the given URL. Uploading to a directory name is probably going to fail on most systems. [2012-12-17 14:48:16] mattsch at gmail dot com Could you elaborate as to why this would be a bad url? The documentation on the curl website seems to indicate that you can specify a url without a filename at the end but then the examples are not specific to upload: http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTURL [2012-12-17 12:17:00] bag...@php.net This is not a libcurl bug. If you think about it for a while, libcurl doesn't know the 'foo' name, it is only given the (bad) URL and it cannot but to fail in this case. I'm also convinced you can see the same problem with other protocols than SFTP for the same reason. [2012-12-17 01:23:46] ahar...@php.net Reopened per previous comments, although I wonder if this might be a libcurl issue rather than a PHP one. 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=63766 -- Edit this bug report at https://bugs.php.net/bug.php?id=63766&edit=1
Bug #55525 [Com]: --enable-zend-multibyte cause Apache exit on signal 10
Edit report at https://bugs.php.net/bug.php?id=55525&edit=1 ID: 55525 Comment by: m dot krasilnikov at yandex dot ru Reported by:info at ihead dot ru Summary:--enable-zend-multibyte cause Apache exit on signal 10 Status: Open Type: Bug Package:Apache related Operating System: FreeBSD 7.4 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: It seems that this issue not reproducible on i386 but only on amd64. Previous Comments: [2012-11-29 10:56:04] m dot krasilnikov at yandex dot ru We have the same issue with PHP 5.3.19 on FreeBSD 7.4 Reproducable with test script from original report. (gdb) bt #0 0x0008018acd50 in _zend_mm_free_int () from /usr/local/libexec/apache22/libphp5.so #1 0x00080189cf5e in zend_multibyte_read_script () from /usr/local/libexec/apache22/libphp5.so #2 0x00080189d37f in open_file_for_scanning () from /usr/local/libexec/apache22/libphp5.so #3 0x00080189db9c in compile_file () from /usr/local/libexec/apache22/libphp5.so #4 0x000809022844 in phar_compile_file () from /usr/local/lib/php/20090626/phar.so #5 0x000804e0bdda in xdebug_compile_file () from /usr/local/lib/php/20090626/xdebug.so #6 0x0008018cb00a in zend_execute_scripts () from /usr/local/libexec/apache22/libphp5.so #7 0x0008018759a7 in php_execute_script () from /usr/local/libexec/apache22/libphp5.so #8 0x00080195577e in php_handler () from /usr/local/libexec/apache22/libphp5.so [2012-02-03 01:30:13] anoni at mo dot us To reproduce try php from ports, make config with multibyte, then install magento shop 1.6 and keep refreshing... :) [2012-02-03 01:23:42] anoni at mo dot us Confirm bug happening on php5.3.9 apache 2.2.21 Freebsd8. PHP compiled with zend_multibyte support. pid (httpd), uid 80: exited on signal 11 another simptom in vhost error.log : PHP Fatal error: require_once() Failed opening required '1' (intermittent, file exists and works 90% of the time). Browser gets white screen of death. Refreshing the page will work ok usually. [2011-09-06 03:12:49] info at ihead dot ru It was tested on Apache 1.3.41 and 2.2.19. I will try on another server later. [2011-09-06 02:50:34] larue...@php.net I can not reproduce this in my environ, and your apache seems to be ancient version, could you test with a newer version of it? thanks 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=55525 -- Edit this bug report at https://bugs.php.net/bug.php?id=55525&edit=1
