Bug #64324 [Nab]: Why 0 == 'BOOK' ?
Edit report at https://bugs.php.net/bug.php?id=64324&edit=1
ID: 64324
User updated by:dosergio at ig dot com dot br
Reported by:dosergio at ig dot com dot br
Summary:Why 0 == 'BOOK' ?
Status: Not a bug
Type: Bug
Package:*General Issues
Operating System: all
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
There is a solution.
See that all examples I gave were made using NON-NUMERIC texts. ('BOOK',
'TEXT', ETC) You are right thinking about numeric strings like '234'.
If text is numeric, php could continue treating them as numbers - that would be
an exception to the rule.
BUT... if the text is NOT numeric (\D+) then it could be casted to boolean.
'12' '13' '1987' would NOT be casted to boolean.
'car' 'soap' '#ffcc00' would.
"If comparing a NON-NUMERIC text ex: "book" to a number, both will be casted to
boolean before comparing".
That would solve the problem, I think.
Remember that
if(0) results false
if('BOOK') results true
so... 0 == 'BOOK' breaks the logic. Think about with calm. I will stop now.
Previous Comments:
[2013-03-02 01:49:56] ras...@php.net
So by your logic 12=='13'
Do you have any idea how much code that would break?
The web is not typed. Everything comes across as strings. And everyone does
stuff
like if($_GET['age']==19) { ... }
which you are proposing to break.
Same goes for data retrieved from databases. Everything comes back as strings.
So no, this is simply not going to happen. Please stop.
[2013-03-02 01:46:02] dosergio at ig dot com dot br
12 == 'TEXT' in the "boolean" point of view is correct.
Javascript agrees with it.
[2013-03-02 01:40:32] ras...@php.net
No it doesn't make more sense. This would make 12=='TEST'
You cast to a type in the comparison, not to some third type. Besides changing
this would break millions of lines of code. Not going to happen.
[2013-03-02 01:19:42] dosergio at ig dot com dot br
A good rule to be implemented by PHP is:
If a comparison of simple equality ( == ) or simple inequality ( != ) is done
between two different data types, PHP should cast both to boolean before
comparing.
Because 'TEXT' casts to true, 0 casts to false so 0 != 'TEXT' makes more sense
than 0 == 'TEXT'.
[2013-02-28 19:12:25] dosergio at ig dot com dot br
OK, you are right. That was the explanation I wanted: it depends on the type
you compare.
if( false == 'TEST') works correctly.
Now it makes a little more sense to me.
But javascript is still superior because inside a if() I suspect that any
language should try to cast both to boolean.
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=64324
--
Edit this bug report at https://bugs.php.net/bug.php?id=64324&edit=1
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: vestigalorgan at gmail dot com
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:
I've run the test case that maisqi provided, and here are my results:
1. Using file_file_get_contents() on an non-existing resource on a existing
domain:
The result: boolean
$http_response_header: array
2. Using file_file_get_contents() on a non-existing domain, with
follow_location => 0 on the context:
The result: boolean
$http_response_header: NULL
3. Using file_file_get_contents() on a non-existing domain, __without__
follow_location => 0 on the context:
The result: boolean
$http_response_header: NULL
This is on Ubuntu 12.04 LTS 64-bit with Apache 2.2.22 and PHP 5.3.10-1ubuntu3.5
with the Suhosin-Patch. Everything appears to be working fine there.
Shouldn't the output of the results be a boolean false, not NULL, maisqi?
Previous Comments:
[2013-03-01 09:54:17] php at maisqi dot com
I think I have new info on this issue. If you check the URI at the bottom
you'll find three tests:
1. Using file_file_get_contents() on an non-existing resource on a existing
domain:
Result: empty string
$http_response_header : an array
2. Using file_file_get_contents() on a non-existing domain, with
follow_location => 0 on the context:
Result: empty string
$http_response_header : NULL
3. Using file_file_get_contents() on a non-existing domain, __without__
follow_location => 0 on the context:
Result: non empty string
$http_response_header : an array
I'd expect that all the results should be NULL.
I think the problem has to to with idiosyncratic behavior on some internal
library. In the third test we can see that there's something asking OpenDNS
when trying to deal with the non-existing behavior; and then it sends a
Location header. This behavior is not documented.
- The same script on a Windows 7/Apache Server [PHP 5.4.12] works as expected;
- On a Debian 3.2.35-2 running PHP 5.2.5 it works as expected;
- On a Turnkey Linux (Ubuntu based Linux) running PHP 5.3.3-7+squeeze14 it
works as expected;
- On a Ubuntu running PHP 5.3.3-7+squeeze14 it works as expected.
So I'd say it has to do with the underlying system libraries and configuration;
it would be nice if others test the script on other kind of servers...
Test script: http://maisqi/outros/bugs/php/61336
[CentOS / PHP 5.4.11]
[2013-01-14 23:52:39] vestigalorgan at gmail dot com
I'm experiencing a similar issue in the PHP version 5.4.7 that ships with
XAMPP. When I open a web URL that throws a warning such as "Warning:
file_get_contents(http://[ip_address_here]:[port_here]): failed to open stream:
No connection could be made because the target machine actively refused it.",
file_get_contents() returns an empty string, instead of false.
I'm not sure if this is related to this bug or I should file a new one. I'm
experiencing this on Windows 7 Professional, SP1 32-bit. I'm only using the
first parameter of file_get_contents().
[2012-10-18 15:51:46] stasismedia at gmail dot com
I should add...
Both PHP versions in Ubuntu 12.04 x64 running as a guest in Virtualbox.
[2012-10-18 15:43:27] stasismedia at gmail dot com
I actually get the same issue on both 5.3.11 and 5.4.4:
5.3.11:
---
array(11) {
[0]=>
string(22) "HTTP/1.1 404 Not Found"
[1]=>
string(35) "Date: Thu, 18 Oct 2012 15:35:04 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=Fri, 18-Oct-2013 15:35:04 GMT;
path=/; domain=.php.net"
[6]=>
string(101) "Set-Cookie: COUNTRY=GBR%2C94.195.8.27; expires=Thu, 25-Oct-2012
15:35:04 GMT; path=/; domain=.php.net"
[7]=>
string(21) "Status: 404 Not Found"
[8]=>
string(20) "Content-Length: 4182"
[9]=>
string(17) "Connection: close"
[10]=>
string(37) "Content-Type: text/html;charset=utf-8"
}
string(4182) "
string(22) "HTTP/1.1 404 Not Found"
[1] =>
string(35) "Date: Thu, 18 Oct 2012 15:35:19 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: L
Bug #64324 [Nab]: Why 0 == 'BOOK' ?
Edit report at https://bugs.php.net/bug.php?id=64324&edit=1
ID: 64324
Updated by: ras...@php.net
Reported by:dosergio at ig dot com dot br
Summary:Why 0 == 'BOOK' ?
Status: Not a bug
Type: Bug
Package:*General Issues
Operating System: all
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
So by your logic 12=='13'
Do you have any idea how much code that would break?
The web is not typed. Everything comes across as strings. And everyone does
stuff
like if($_GET['age']==19) { ... }
which you are proposing to break.
Same goes for data retrieved from databases. Everything comes back as strings.
So no, this is simply not going to happen. Please stop.
Previous Comments:
[2013-03-02 01:46:02] dosergio at ig dot com dot br
12 == 'TEXT' in the "boolean" point of view is correct.
Javascript agrees with it.
[2013-03-02 01:40:32] ras...@php.net
No it doesn't make more sense. This would make 12=='TEST'
You cast to a type in the comparison, not to some third type. Besides changing
this would break millions of lines of code. Not going to happen.
[2013-03-02 01:19:42] dosergio at ig dot com dot br
A good rule to be implemented by PHP is:
If a comparison of simple equality ( == ) or simple inequality ( != ) is done
between two different data types, PHP should cast both to boolean before
comparing.
Because 'TEXT' casts to true, 0 casts to false so 0 != 'TEXT' makes more sense
than 0 == 'TEXT'.
[2013-02-28 19:12:25] dosergio at ig dot com dot br
OK, you are right. That was the explanation I wanted: it depends on the type
you compare.
if( false == 'TEST') works correctly.
Now it makes a little more sense to me.
But javascript is still superior because inside a if() I suspect that any
language should try to cast both to boolean.
[2013-02-28 19:04:24] ras...@php.net
We don't want a special case for 0. By your logic 12 == 'TEST' should be true.
You are assuming a cast to boolean even though neither side of the comparison
is
a boolean. Note that true == 'TEST' will match because here we cast to boolean.
But 'TEST' cast to an integer is going to give you 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=64324
--
Edit this bug report at https://bugs.php.net/bug.php?id=64324&edit=1
Bug #64324 [Nab]: Why 0 == 'BOOK' ?
Edit report at https://bugs.php.net/bug.php?id=64324&edit=1 ID: 64324 User updated by:dosergio at ig dot com dot br Reported by:dosergio at ig dot com dot br Summary:Why 0 == 'BOOK' ? Status: Not a bug Type: Bug Package:*General Issues Operating System: all PHP Version:Irrelevant Block user comment: N Private report: N New Comment: 12 == 'TEXT' in the "boolean" point of view is correct. Javascript agrees with it. Previous Comments: [2013-03-02 01:40:32] ras...@php.net No it doesn't make more sense. This would make 12=='TEST' You cast to a type in the comparison, not to some third type. Besides changing this would break millions of lines of code. Not going to happen. [2013-03-02 01:19:42] dosergio at ig dot com dot br A good rule to be implemented by PHP is: If a comparison of simple equality ( == ) or simple inequality ( != ) is done between two different data types, PHP should cast both to boolean before comparing. Because 'TEXT' casts to true, 0 casts to false so 0 != 'TEXT' makes more sense than 0 == 'TEXT'. [2013-02-28 19:12:25] dosergio at ig dot com dot br OK, you are right. That was the explanation I wanted: it depends on the type you compare. if( false == 'TEST') works correctly. Now it makes a little more sense to me. But javascript is still superior because inside a if() I suspect that any language should try to cast both to boolean. [2013-02-28 19:04:24] ras...@php.net We don't want a special case for 0. By your logic 12 == 'TEST' should be true. You are assuming a cast to boolean even though neither side of the comparison is a boolean. Note that true == 'TEST' will match because here we cast to boolean. But 'TEST' cast to an integer is going to give you 0. [2013-02-28 18:58:51] dosergio at ig dot com dot br Conclusion: The exact analysis above done in javascript says I am right. I have no doubt that javascript makes more use of logic that php. 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=64324 -- Edit this bug report at https://bugs.php.net/bug.php?id=64324&edit=1
Bug #64229 [Com]: Streams do not recognize SSL contexts
Edit report at https://bugs.php.net/bug.php?id=64229&edit=1 ID: 64229 Comment by: payden at paydensutherland dot com Reported by:andrew dot heebner at gmail dot com Summary:Streams do not recognize SSL contexts Status: Open Type: Bug Package:Streams related Operating System: Win7, Linux PHP Version:5.4.11 Block user comment: N Private report: N New Comment: This seems to work fine for me on Ubuntu 12.10 32-bit with php-5.4.11 and php- 5.4.12. payden@arwen:~$ php test.php Running on 5.4.11 Linux arwen 3.5.0-23-generic #35-Ubuntu SMP Thu Jan 24 13:05:29 UTC 2013 i686 payden@arwen:~$ Something wrong with your cert? Previous Comments: [2013-02-17 14:49:03] andrew dot heebner at gmail dot com Description: stream_socket_server does not accept nor use SSL contexts properly. The same bug and reproduction has existed since 2008 without any valid workaround or fix Test script: --- Please see this old bug post, as it is relevant and still throws the same warnings and errors. https://bugs.php.net/bug.php?id=46127 Expected result: An actual functioning SSL stream server Actual result: -- See https://bugs.php.net/bug.php?id=46127 for errors thrown -- Edit this bug report at https://bugs.php.net/bug.php?id=64229&edit=1
Bug #64324 [Nab]: Why 0 == 'BOOK' ?
Edit report at https://bugs.php.net/bug.php?id=64324&edit=1 ID: 64324 Updated by: ras...@php.net Reported by:dosergio at ig dot com dot br Summary:Why 0 == 'BOOK' ? Status: Not a bug Type: Bug Package:*General Issues Operating System: all PHP Version:Irrelevant Block user comment: N Private report: N New Comment: No it doesn't make more sense. This would make 12=='TEST' You cast to a type in the comparison, not to some third type. Besides changing this would break millions of lines of code. Not going to happen. Previous Comments: [2013-03-02 01:19:42] dosergio at ig dot com dot br A good rule to be implemented by PHP is: If a comparison of simple equality ( == ) or simple inequality ( != ) is done between two different data types, PHP should cast both to boolean before comparing. Because 'TEXT' casts to true, 0 casts to false so 0 != 'TEXT' makes more sense than 0 == 'TEXT'. [2013-02-28 19:12:25] dosergio at ig dot com dot br OK, you are right. That was the explanation I wanted: it depends on the type you compare. if( false == 'TEST') works correctly. Now it makes a little more sense to me. But javascript is still superior because inside a if() I suspect that any language should try to cast both to boolean. [2013-02-28 19:04:24] ras...@php.net We don't want a special case for 0. By your logic 12 == 'TEST' should be true. You are assuming a cast to boolean even though neither side of the comparison is a boolean. Note that true == 'TEST' will match because here we cast to boolean. But 'TEST' cast to an integer is going to give you 0. [2013-02-28 18:58:51] dosergio at ig dot com dot br Conclusion: The exact analysis above done in javascript says I am right. I have no doubt that javascript makes more use of logic that php. [2013-02-28 18:51:56] dosergio at ig dot com dot br I know the use of ===. The supposed 'bug' that I think exists, is comparing 0 to a non-empty String with double == My concern is because: Observation 1: null, 0, "0", and "" all result as FALSE. Observation 2: BUT... "A STRING" evaluates as TRUE. SO... 0 == "" makes sense BUT... 0 == "A NON-EMPTY STRING" makes no sense. IMHO False would be the right answer. Take a little time to examine this: if( 0 ) echo "0 works as TRUE"; else echo "0 works as false "; if( "TEST") echo "'TEST' works as TRUE"; else echo "'TEST' works as false "; if( 0 == 'TEST') echo "But 0 == 'TEST' belies the statements above!"; 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=64324 -- Edit this bug report at https://bugs.php.net/bug.php?id=64324&edit=1
Bug #64324 [Nab]: Why 0 == 'BOOK' ?
Edit report at https://bugs.php.net/bug.php?id=64324&edit=1 ID: 64324 User updated by:dosergio at ig dot com dot br Reported by:dosergio at ig dot com dot br Summary:Why 0 == 'BOOK' ? Status: Not a bug Type: Bug Package:*General Issues Operating System: all PHP Version:Irrelevant Block user comment: N Private report: N New Comment: A good rule to be implemented by PHP is: If a comparison of simple equality ( == ) or simple inequality ( != ) is done between two different data types, PHP should cast both to boolean before comparing. Because 'TEXT' casts to true, 0 casts to false so 0 != 'TEXT' makes more sense than 0 == 'TEXT'. Previous Comments: [2013-02-28 19:12:25] dosergio at ig dot com dot br OK, you are right. That was the explanation I wanted: it depends on the type you compare. if( false == 'TEST') works correctly. Now it makes a little more sense to me. But javascript is still superior because inside a if() I suspect that any language should try to cast both to boolean. [2013-02-28 19:04:24] ras...@php.net We don't want a special case for 0. By your logic 12 == 'TEST' should be true. You are assuming a cast to boolean even though neither side of the comparison is a boolean. Note that true == 'TEST' will match because here we cast to boolean. But 'TEST' cast to an integer is going to give you 0. [2013-02-28 18:58:51] dosergio at ig dot com dot br Conclusion: The exact analysis above done in javascript says I am right. I have no doubt that javascript makes more use of logic that php. [2013-02-28 18:51:56] dosergio at ig dot com dot br I know the use of ===. The supposed 'bug' that I think exists, is comparing 0 to a non-empty String with double == My concern is because: Observation 1: null, 0, "0", and "" all result as FALSE. Observation 2: BUT... "A STRING" evaluates as TRUE. SO... 0 == "" makes sense BUT... 0 == "A NON-EMPTY STRING" makes no sense. IMHO False would be the right answer. Take a little time to examine this: if( 0 ) echo "0 works as TRUE"; else echo "0 works as false "; if( "TEST") echo "'TEST' works as TRUE"; else echo "'TEST' works as false "; if( 0 == 'TEST') echo "But 0 == 'TEST' belies the statements above!"; [2013-02-28 15:22:59] ras...@php.net You are doing a loose comparison between two different types. PHP has to pick a type for it. In this case it does 0 == (int)'TEST' and casting 'TEST' to an int is obviously going to give you 0. This is what you are going to want in most cases. eg. 12 == "12 " (with an extra space there). Chances are the "12 " came from user input since everything that comes from either the browser or your backend database comes to you as strings, you are going to want that comparison to work. If you cast both to strings instead they wouldn't. If you don't want PHP to guess, use === 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=64324 -- Edit this bug report at https://bugs.php.net/bug.php?id=64324&edit=1
[PHP-BUG] Bug #64334 [NEW]: bindParam() does not requre colon for parameter
From: shri dot amin at gmail dot com
Operating system: all
PHP version: 5.3.22
Package: PDO related
Bug Type: Bug
Bug description:bindParam() does not requre colon for parameter
Description:
the bindParam($param, $var) PDO function does not require the colon(:) for
the param.
Test script:
---
$stmt = $dbh->prepare("INSERT INTO foo VALUES (:email, :password)");
$stmt->bindParam('email', $_POST['email']); //this works, but shouldn't
$stmt->bindParam('password', $_POST['password']); //this works, but
shouldn't
Expected result:
obviously the first param of bindParam() should require the colon(:)
Actual result:
--
the first param of bindParam() does not require the colon(:)
--
Edit bug report at https://bugs.php.net/bug.php?id=64334&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64334&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64334&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64334&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64334&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64334&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64334&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64334&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64334&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64334&r=support
Expected behavior: https://bugs.php.net/fix.php?id=64334&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64334&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64334&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64334&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64334&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64334&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64334&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64334&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64334&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64334&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64334&r=mysqlcfg
Req #54699 [Com]: Abbreviated month comes out wrong.
Edit report at https://bugs.php.net/bug.php?id=54699&edit=1 ID: 54699 Comment by: jellofishi at gmail dot com Reported by:info at swedishboy dot se Summary:Abbreviated month comes out wrong. Status: Open Type: Feature/Change Request Package:Date/time related Operating System: Irrelevant PHP Version:Irrelevant Block user comment: N Private report: N New Comment: PHP uses the system's libc implementation of srtftime. This is not a PHP specific issue. Previous Comments: [2011-05-10 01:11:13] info at swedishboy dot se Seems like there are more languages that should use different abbreviations depending on the full name. http://library.princeton.edu/departments/tsd/katmandu/reference/months.html [2011-05-10 01:09:02] info at swedishboy dot se Actually my point is that even in English May, June and July shouldn't be shortened. I believe this is actually the typograhic rule. Am I wrong? Maybe use one of the abbreviations for month to follow typographic rules? [2011-05-10 01:01:51] info at swedishboy dot se Description: Abbreviated month always displays month names with three letters. However ... in Swedish we never write July and June with three letters. This is seen as wrong and not the standard way of shortening the month names. The reason is simple. July (juli in swedish) when shortening to three letter becomes 'Jul' which is the swedish word for christmas. I realized how stupid and funny it looks when I programmed a calendar plugin for wordpress and I echoed some dates in July. So both July and June should spell out juli and juni when set_locale is set to Swedish language. One more detail; Month names should are written in lowercase in Swedish when used in sentences. This can of course simply be controlled by the programmer using strtolower() and should be the prefered solution I'd say. Test script: --- Expected result: 2 Juli 2011 Actual result: -- 2 Jul 2011 (Jul = Christmas in swedish) -- Edit this bug report at https://bugs.php.net/bug.php?id=54699&edit=1
Bug #64333 [Opn->Dup]: Can´t configure with LDAP
Edit report at https://bugs.php.net/bug.php?id=64333&edit=1 ID: 64333 Updated by: s...@php.net Reported by:hudson dot melo at fazenda dot mg dot gov dot br Summary:Can´t configure with LDAP -Status: Open +Status: Duplicate Type: Bug -Package:PHP options/info functions +Package:LDAP related Operating System: Solaris 10 PHP Version:5.3.22 Block user comment: N Private report: N New Comment: See https://bugs.php.net/bug.php?id=61450 Previous Comments: [2013-03-01 19:32:33] s...@php.net See https://github.com/php/php-src/pull/19 [2013-03-01 18:21:11] hudson dot melo at fazenda dot mg dot gov dot br Description: Hi, in any version 5.3.x of php with solaris 10 sparc/x86 appear the same ERROR. I need help. checking for ldap_parse_result... no checking for ldap_parse_reference... no checking for ldap_start_tls_s... no checking for ldap_bind_s... no configure: error: LDAP build check failed. Please check config.log for more information. My environment: SunOS geia 5.10 Generic_118833-36 sun4v sparc SUNW,Sun-Fire-T200 or SunOS amicoz2 5.10 Generic_147441-01 i86pc i386 i86pc LD_LIBRARY_PATH=/oracle/app/oracle/product/instantclient_10.2.0.3:/usr/local/lib:/usr/sfw/lib:/usr/local/ssl/lib PATH=/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin:/usr/sbin:/usr/bin:/bin:/usr/local/BerkeleyDB.4.2:/usr/local/ssl/bin:/usr/sfw/bin:/usr/ccs/bin command line PHP: ./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-config-file-path=/usr/local/apache2/conf --with-oci8=instantclient,/oracle/app/oracle/product/instantclient_10.2.0.3 --enable-sigchild --enable-mbstring --with-gd --with-openssl=/usr/local/ssl --with-curl=/usr/local/bin/curl --with-ldap=/usr --with-xmlrpc Thanks. Hudson Actual result: -- checking for ldap_parse_result... no checking for ldap_parse_reference... no checking for ldap_start_tls_s... no checking for ldap_bind_s... no configure: error: LDAP build check failed. Please check config.log for more information. -- Edit this bug report at https://bugs.php.net/bug.php?id=64333&edit=1
Bug #64333 [Opn]: Can´t configure with LDAP
Edit report at https://bugs.php.net/bug.php?id=64333&edit=1 ID: 64333 Updated by: s...@php.net Reported by:hudson dot melo at fazenda dot mg dot gov dot br Summary:Can´t configure with LDAP Status: Open Type: Bug Package:PHP options/info functions Operating System: Solaris 10 PHP Version:5.3.22 Block user comment: N Private report: N New Comment: See https://github.com/php/php-src/pull/19 Previous Comments: [2013-03-01 18:21:11] hudson dot melo at fazenda dot mg dot gov dot br Description: Hi, in any version 5.3.x of php with solaris 10 sparc/x86 appear the same ERROR. I need help. checking for ldap_parse_result... no checking for ldap_parse_reference... no checking for ldap_start_tls_s... no checking for ldap_bind_s... no configure: error: LDAP build check failed. Please check config.log for more information. My environment: SunOS geia 5.10 Generic_118833-36 sun4v sparc SUNW,Sun-Fire-T200 or SunOS amicoz2 5.10 Generic_147441-01 i86pc i386 i86pc LD_LIBRARY_PATH=/oracle/app/oracle/product/instantclient_10.2.0.3:/usr/local/lib:/usr/sfw/lib:/usr/local/ssl/lib PATH=/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin:/usr/sbin:/usr/bin:/bin:/usr/local/BerkeleyDB.4.2:/usr/local/ssl/bin:/usr/sfw/bin:/usr/ccs/bin command line PHP: ./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-config-file-path=/usr/local/apache2/conf --with-oci8=instantclient,/oracle/app/oracle/product/instantclient_10.2.0.3 --enable-sigchild --enable-mbstring --with-gd --with-openssl=/usr/local/ssl --with-curl=/usr/local/bin/curl --with-ldap=/usr --with-xmlrpc Thanks. Hudson Actual result: -- checking for ldap_parse_result... no checking for ldap_parse_reference... no checking for ldap_start_tls_s... no checking for ldap_bind_s... no configure: error: LDAP build check failed. Please check config.log for more information. -- Edit this bug report at https://bugs.php.net/bug.php?id=64333&edit=1
Bug #64329 [Nab]: CURLOPT_FTP_SKIP_PASV_IP does not exist
Edit report at https://bugs.php.net/bug.php?id=64329&edit=1 ID: 64329 Updated by: s...@php.net Reported by:daniel at c-books dot co dot uk Summary:CURLOPT_FTP_SKIP_PASV_IP does not exist Status: Not a bug Type: Bug Package:*General Issues Operating System: any PHP Version:5.4.12 Block user comment: N Private report: N New Comment: That boiler plate might have been confusing (I believe the drop down menu that adds it to a bug just says "try a newer version" and doesn't mention which component is old). The answer is probably that your cURL version is not the most recent. Looking at PHP 5.4.11's ext/curl/interface.c there is code for this constant if your libcurl version is recent enough. #if LIBCURL_VERSION_NUM >= 0x070f01 REGISTER_CURL_CONSTANT(CURLOPT_FTP_FILEMETHOD); REGISTER_CURL_CONSTANT(CURLOPT_FTP_SKIP_PASV_IP); #endif Previous Comments: [2013-03-01 04:59:29] daniel at c-books dot co dot uk I am confused how am I not using a current version of PHP? PHP Info: PHP Version 5.4.12 PHP Downloads: PHP 5.4.12 (Current stable) [2013-03-01 04:41:35] pierr...@php.net Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. This constant will be available in php5.5 [2013-03-01 04:28:33] daniel at c-books dot co dot uk Description: he CURLOPT_FTP_SKIP_PASV_IP option is part of libcurl (see http://curl.haxx.se/libcurl/c/curl_easy_setopt.html ) but no predefined constant exists for use with curl_setopt(). This was requested 2010-01-14. https://bugs.php.net/bug.php?id=50756 No resolution has been provided to date. -- Edit this bug report at https://bugs.php.net/bug.php?id=64329&edit=1
[PHP-BUG] Bug #64333 [NEW]: Can´t configure with LDAP
From: hudson dot melo at fazenda dot mg dot gov dot br Operating system: Solaris 10 PHP version: 5.3.22 Package: PHP options/info functions Bug Type: Bug Bug description:Can´t configure with LDAP Description: Hi, in any version 5.3.x of php with solaris 10 sparc/x86 appear the same ERROR. I need help. checking for ldap_parse_result... no checking for ldap_parse_reference... no checking for ldap_start_tls_s... no checking for ldap_bind_s... no configure: error: LDAP build check failed. Please check config.log for more information. My environment: SunOS geia 5.10 Generic_118833-36 sun4v sparc SUNW,Sun-Fire-T200 or SunOS amicoz2 5.10 Generic_147441-01 i86pc i386 i86pc LD_LIBRARY_PATH=/oracle/app/oracle/product/instantclient_10.2.0.3:/usr/local/lib:/usr/sfw/lib:/usr/local/ssl/lib PATH=/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin:/usr/sbin:/usr/bin:/bin:/usr/local/BerkeleyDB.4.2:/usr/local/ssl/bin:/usr/sfw/bin:/usr/ccs/bin command line PHP: ./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-config-file-path=/usr/local/apache2/conf --with-oci8=instantclient,/oracle/app/oracle/product/instantclient_10.2.0.3 --enable-sigchild --enable-mbstring --with-gd --with-openssl=/usr/local/ssl --with-curl=/usr/local/bin/curl --with-ldap=/usr --with-xmlrpc Thanks. Hudson Actual result: -- checking for ldap_parse_result... no checking for ldap_parse_reference... no checking for ldap_start_tls_s... no checking for ldap_bind_s... no configure: error: LDAP build check failed. Please check config.log for more information. -- Edit bug report at https://bugs.php.net/bug.php?id=64333&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64333&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64333&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64333&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64333&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64333&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64333&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64333&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64333&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64333&r=support Expected behavior: https://bugs.php.net/fix.php?id=64333&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64333&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64333&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64333&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64333&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64333&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64333&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64333&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64333&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64333&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64333&r=mysqlcfg
Req #40248 [Opn->Csd]: Undefined members with combined operators produce no warning
Edit report at https://bugs.php.net/bug.php?id=40248&edit=1 ID: 40248 Updated by: re...@php.net Reported by:jontsa at amigaone dot cc Summary:Undefined members with combined operators produce no warning -Status: Open +Status: Closed Type: Feature/Change Request Package:Scripting Engine problem Operating System: Solaris PHP Version:5.2.0 -Assigned To: +Assigned To:reeze Block user comment: N Private report: N New Comment: The fix for this bug has been committed. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. This was implemented in lastest version 5.5 master Previous Comments: [2012-03-20 21:00:46] php dot net at doppy dot nl Can still reproduce this. PHP 5.3.10-1ubuntu2 with Suhosin-Patch (cli) (built: Mar 5 2012 18:27:21) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies Recommend using this reproduce code: a+=5; $b=new stdClass; $b->a=$b->a + 5; Expected result: PHP Notice: Undefined variable: a in /test.php on line 3 PHP Notice: Undefined property: stdClass::$a in /test.php on line 6 PHP Notice: Undefined property: stdClass::$a in /test.php on line 9 Actual result: PHP Notice: Undefined variable: a in /test.php on line 3 PHP Notice: Undefined property: stdClass::$a in /test.php on line 9 [2007-01-26 10:12:51] jontsa at amigaone dot cc Description: When using a combined operator like += or ++ on an undefined class member, it does not produce "undefined property" notice as expected. Tested with all errors enabled. Reproduce code: --- $a+=5; $b=new stdClass; $b->a+=5; Expected result: Notice: Undefined variable: a Notice: Undefined property: stdClass::$a Actual result: -- Notice: Undefined variable: a -- Edit this bug report at https://bugs.php.net/bug.php?id=40248&edit=1
[PHP-BUG] Bug #64332 [NEW]: Problems with BR Save time (BRST)
From: bernardo at datamex dot com dot br
Operating system: Window,Linux,FreeBSD
PHP version: Irrelevant
Package: Date/time related
Bug Type: Bug
Bug description:Problems with BR Save time (BRST)
Description:
I changed my server application before Freebsd with php 5.3.3 now Ubuntu
with php
5.3.10.
I noticed that there are differences between treatment dates in different
timezones.
Note that when BRST "America/Sao_Paulo" advances one hour.
Test script:
---
NOWIn BRST ({$time})
{$timezone}{$agoraAqui}{$antesAqui}
America/Bahia{$agoraLa}{$antesLa}
time-brazil
";
?>
Expected result:
NOW | In BRST (1358258400)
America/Sao_Paulo | 01/03/2013 14:46:27 | 15/01/2013 12:00:00
America/Bahia | 01/03/2013 14:46:27 | 15/01/2013 11:00:00
Actual result:
--
Correct in:
- freebsd + php 5.3.3
- freebsd + php 5.3.6
- windows + php 5.3.8
NOW | In BRST (1358258400)
America/Sao_Paulo | 01/03/2013 14:46:27 | 15/01/2013 12:00:00
America/Bahia | 01/03/2013 14:46:27 | 15/01/2013 11:00:00
Error in:
- freebsd + php 5.3.10
- ubuntu + php 5.3.10
- windows + php 5.4.3
NOW | In BRST (1358258400)
America/Sao_Paulo | 01/03/2013 14:46:27 | 15/01/2013 12:00:00
America/Bahia | 01/03/2013 14:46:27 | 15/01/2013 12:00:00
--
Edit bug report at https://bugs.php.net/bug.php?id=64332&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64332&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64332&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64332&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64332&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64332&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64332&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64332&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64332&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64332&r=support
Expected behavior: https://bugs.php.net/fix.php?id=64332&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64332&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64332&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64332&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64332&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64332&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64332&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64332&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64332&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64332&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64332&r=mysqlcfg
Req #54152 [Com]: Make FPM compatible with Apache HTTP Server 2.3 mod_proxy_fcgi
Edit report at https://bugs.php.net/bug.php?id=54152&edit=1 ID: 54152 Comment by: phpfpm1 at gmail dot com Reported by:mark at catseye dot org Summary:Make FPM compatible with Apache HTTP Server 2.3 mod_proxy_fcgi Status: Closed Type: Feature/Change Request Package:FPM related Operating System: Linux PHP Version:5.3SVN-2011-03-03 (snap) Assigned To:jimjag Block user comment: N Private report: N New Comment: Any news on the subject? Previous Comments: [2011-09-15 19:09:40] f...@php.net reopen :) [2011-09-15 19:08:11] apache-lists at riggs dot me This fix does not take into account using mod_proxy_balancer. When I use this same setup using mod_proxy_fcgi as a BalancerMember, I get a SCRIPT_FILENAME of proxy:balancer:// Should this be reopened to handle that, or should we create a new bug? [2011-03-29 13:39:13] mark at catseye dot org v3 of the patch was applied to trunk in r309054 http://svn.php.net/viewvc?view=revision&revision=309054 [2011-03-09 19:53:24] jim...@php.net Automatic comment from SVN on behalf of jimjag Revision: http://svn.php.net/viewvc/?view=revision&revision=309054 Log: Close [PHP-BUG] Req #54152... Apache 2.3.12 (and later) will now work correctly with PHP's fcgi impl with this patch. [2011-03-09 19:27:31] jim...@php.net Automatic comment from SVN on behalf of jimjag Revision: http://svn.php.net/viewvc/?view=revision&revision=309053 Log: Close [PHP-BUG] Req #54152... Apache 2.3.12 (and later) will now work correctly with PHP's fcgi impl with this patch. 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=54152 -- Edit this bug report at https://bugs.php.net/bug.php?id=54152&edit=1
Bug #51159 [Com]: session_set_save_handler Memory Corruption
Edit report at https://bugs.php.net/bug.php?id=51159&edit=1
ID: 51159
Comment by: office at xtreme-vision dot net
Reported by:achristianson at yakabod dot com
Summary:session_set_save_handler Memory Corruption
Status: No Feedback
Type: Bug
Package:Scripting Engine problem
Operating System: CentOS 5.4
PHP Version:5.3.1
Block user comment: N
Private report: N
New Comment:
Hi,
We confirm the reproduce code crashes with a segault on CentOS 6 (Linux 2.6.32-
279.22.1.el6.x86_64 #1 SMP Wed Feb 6 03:10:46 UTC 2013 x86_64 x86_64 x86_64
GNU/Linux) and php 5.3.3 (php-5.3.3-14.el6_3.x86_64).
Also, we get this result in a core dump for Apache 2.2.15 (httpd-2.2.15-
15.el6.centos.1.x86_64):
Core was generated by `/usr/sbin/httpd'.
Program terminated with signal 11, Segmentation fault.
#0 0x7f4aef304e94 in _get_zval_ptr_cv (execute_data=0x7f4afb6d0658) at
/usr/src/debug/php-5.3.3/Zend/zend_execute.c:251
251 zval ***ptr = &CV_OF(node->u.var);
Can someone look at this problem, as it's causing major crashes of our
webserver.
Thanks,
Michael.
Previous Comments:
[2013-02-18 00:34:08] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2012-03-29 21:14:48] ar...@php.net
The reproduce code correctly gives a fatal error ("Fatal error: Cannot access
self:: when no class scope is active" and no crash) in the current 5.3 branch
and trunk. Changing it to a normal variable assignment works fine.
Please let us know if you can reproduce this bug with another script without
this error, or a current PHP version.
[2011-01-27 22:23:21] sa at yakabod dot com
Any chance someone can take a look at this issue that is now approaching 1 year
in the queue. We have recently reproduced it on PHP 5.3.4 on CentOS 5.5. We
are
willing to help out with debugging. Thanks.
[2010-05-26 19:37:14] info at das-peter dot ch
Hi there,
can confirm this behavior with gc enabled/disabled.
My current installation:
php 5.3.2 for win x86 [API220090626,TS,VC6 ]
Compiler VC6, thread safe
Run under Apache 2.2
Cheers,
Peter
[2010-03-01 12:46:00] achristianson at yakabod dot com
We tried with GC off and we get the same result.
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=51159
--
Edit this bug report at https://bugs.php.net/bug.php?id=51159&edit=1
Req #49543 [Com]: closures cannot import/inherit $this
Edit report at https://bugs.php.net/bug.php?id=49543&edit=1
ID: 49543
Comment by: netmosfera at email dot it
Reported by:mjs at beebo dot org
Summary:closures cannot import/inherit $this
Status: Closed
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: Ubuntu
PHP Version:5.3.0
Assigned To:jani
Block user comment: N
Private report: N
New Comment:
would be nice also to have a way to alias variables when importing into the
closure's scope
which becomes very useful for
function() use ($this as $x) { };
Previous Comments:
[2011-06-13 06:15:05] ras...@php.net
It is in 5.4
[2011-06-13 04:28:01] php at hotblocks dot nl
When can we expect this? Go PHP mixins!
[2010-12-17 12:18:12] j...@php.net
This was added in trunk (will not be in 5.3.x) but whatever trunk becomes.
[2010-06-11 19:17:36] martin dot partel at gmail dot com
The '$tmp' workaround is not good enough, since private/protected members
cannot be accessed that way. This renders closures frustratingly useless in OO
code in quite a few situations.
All other OO languages with closures that I know of allow such access one way
or the other. Come on guys, find your consensus and get it done!
[2009-09-13 14:55:50] mjs at beebo dot org
Description:
Attempting to import/inherit $this produces the compile-time error
"Cannot use $this as lexical variable."
Note that the workaround of assigning $this to the temporary variable
$tmp, and inheriting $tmp instead does work, so there appears to be no
limitation in the engine:
class Foo {
public function bar() {
$tmp = $this;
return function() use ($tmp) {
echo "in closure\n";
}
}
}
See also http://wiki.php.net/rfc/closures/removal-of-this. (It
appears that $this was once automatically imported into the closure's
scope, but that this turned out to be a bad idea. This bug report
concerns what happens when $this is explicitly imported, however.)
Reproduce code:
---
https://bugs.php.net/bug.php?id=49543&edit=1
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: php at maisqi dot com
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:
I think I have new info on this issue. If you check the URI at the bottom
you'll find three tests:
1. Using file_file_get_contents() on an non-existing resource on a existing
domain:
Result: empty string
$http_response_header : an array
2. Using file_file_get_contents() on a non-existing domain, with
follow_location => 0 on the context:
Result: empty string
$http_response_header : NULL
3. Using file_file_get_contents() on a non-existing domain, __without__
follow_location => 0 on the context:
Result: non empty string
$http_response_header : an array
I'd expect that all the results should be NULL.
I think the problem has to to with idiosyncratic behavior on some internal
library. In the third test we can see that there's something asking OpenDNS
when trying to deal with the non-existing behavior; and then it sends a
Location header. This behavior is not documented.
- The same script on a Windows 7/Apache Server [PHP 5.4.12] works as expected;
- On a Debian 3.2.35-2 running PHP 5.2.5 it works as expected;
- On a Turnkey Linux (Ubuntu based Linux) running PHP 5.3.3-7+squeeze14 it
works as expected;
- On a Ubuntu running PHP 5.3.3-7+squeeze14 it works as expected.
So I'd say it has to do with the underlying system libraries and configuration;
it would be nice if others test the script on other kind of servers...
Test script: http://maisqi/outros/bugs/php/61336
[CentOS / PHP 5.4.11]
Previous Comments:
[2013-01-14 23:52:39] vestigalorgan at gmail dot com
I'm experiencing a similar issue in the PHP version 5.4.7 that ships with
XAMPP. When I open a web URL that throws a warning such as "Warning:
file_get_contents(http://[ip_address_here]:[port_here]): failed to open stream:
No connection could be made because the target machine actively refused it.",
file_get_contents() returns an empty string, instead of false.
I'm not sure if this is related to this bug or I should file a new one. I'm
experiencing this on Windows 7 Professional, SP1 32-bit. I'm only using the
first parameter of file_get_contents().
[2012-10-18 15:51:46] stasismedia at gmail dot com
I should add...
Both PHP versions in Ubuntu 12.04 x64 running as a guest in Virtualbox.
[2012-10-18 15:43:27] stasismedia at gmail dot com
I actually get the same issue on both 5.3.11 and 5.4.4:
5.3.11:
---
array(11) {
[0]=>
string(22) "HTTP/1.1 404 Not Found"
[1]=>
string(35) "Date: Thu, 18 Oct 2012 15:35:04 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=Fri, 18-Oct-2013 15:35:04 GMT;
path=/; domain=.php.net"
[6]=>
string(101) "Set-Cookie: COUNTRY=GBR%2C94.195.8.27; expires=Thu, 25-Oct-2012
15:35:04 GMT; path=/; domain=.php.net"
[7]=>
string(21) "Status: 404 Not Found"
[8]=>
string(20) "Content-Length: 4182"
[9]=>
string(17) "Connection: close"
[10]=>
string(37) "Content-Type: text/html;charset=utf-8"
}
string(4182) "
string(22) "HTTP/1.1 404 Not Found"
[1] =>
string(35) "Date: Thu, 18 Oct 2012 15:35:19 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=Fri, 18-Oct-2013 15:35:19 GMT;
path=/; domain=.php.net"
[6] =>
string(101) "Set-Cookie: COUNTRY=GBR%2C94.195.8.27; expires=Thu, 25-Oct-2012
15:35:19 GMT; path=/; domain=.php.net"
[7] =>
string(21) "Status: 404 Not Found"
[8] =>
string(20) "Content-Length: 4182"
[9] =>
string(17) "Connection: close"
[10] =>
string(37) "Content-Type: text/html;charset=utf-8"
}
string(4182) "https://bugs.php.net/bug.php?id=61336
--
Edit this bug report at https://bugs.php.net/bug.php?id=61336&edit=1
Bug #64297 [Opn]: Segfault after allowed memory exhausted
Edit report at https://bugs.php.net/bug.php?id=64297&edit=1
ID: 64297
User updated by:jille at hexon dot cx
Reported by:jille at hexon dot cx
Summary:Segfault after allowed memory exhausted
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Linux
PHP Version:5.4.12
Block user comment: N
Private report: N
New Comment:
(gdb) f 3
#3 0x0079f861 in zend_shutdown () at /tmp/php-5.4.12/Zend/zend.c:822
822 zend_hash_destroy(GLOBAL_FUNCTION_TABLE);
(gdb) f 2
#2 0x007ad658 in zend_hash_destroy (ht=0xf9fe90)
at /tmp/php-5.4.12/Zend/zend_hash.c:560
560 ht->pDestructor(q->pData);
(gdb) print *q
$5 = {h = 13860750752776937334, nKeyLength = 14, pData = 0x11d99b0,
pDataPtr = 0x0, pListNext = 0x11d9ab0, pListLast = 0x11d6fe0, pNext = 0x0,
pLast = 0x0, arKey = 0x77ed6f18 "udp_getsocket"}
(gdb) f 1
#1 0x00795d62 in destroy_op_array (op_array=0x11d99b0)
at /tmp/php-5.4.12/Zend/zend_opcode.c:356
356 efree(op_array->run_time_cache);
(gdb) print *op_array
$6 = {type = 2 '\002', function_name = 0x77fd4638 "udp_getSocket",
scope = 0x0, fn_flags = 134217728, prototype = 0x0, num_args = 0,
required_num_args = 0, arg_info = 0x0, refcount = 0x77fd5e20,
opcodes = 0x77fd7838, last = 17, vars = 0x77fd3fc8, last_var = 1,
T = 6, brk_cont_array = 0x0, last_brk_cont = 0, try_catch_array = 0x0,
last_try_catch = 0, static_variables = 0x77fd4e80,
this_var = 4294967295, filename = 0x77fd0ba0 "", line_start = 3,
line_end = 9, doc_comment = 0x0, doc_comment_len = 0,
early_binding = 4294967295, literals = 0x77fd4fd0, last_literal = 8,
run_time_cache = 0x3a0f81a0, last_cache_slot = 2, reserved = {0x0, 0x0, 0x0,
0x0}}
(gdb) print *op_array->run_time_cache
Cannot access memory at address 0x3a0f81a0
Previous Comments:
[2013-03-01 09:43:41] jille at hexon dot cx
Yes. Exactly the same.
[2013-03-01 09:38:53] larue...@php.net
nothing serious,
so the segufalt backtrace is the same as before?
[2013-03-01 08:15:56] jille at hexon dot cx
==30922== Memcheck, a memory error detector
==30922== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==30922== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==30922== Command: ./sapi/cli/php -d auto_prepend_file=auto_prepend_prepend.lib
/data/www/htdocs/wheeler/daemons/daemon_wrapper 1023 live memcrash.php
==30922==
==30922== Invalid read of size 8
==30922==at 0x77954D: _zend_mm_free_int (zend_alloc.c:2071)
==30922==by 0x795D61: destroy_op_array (zend_opcode.c:356)
==30922==by 0x7AD657: zend_hash_destroy (zend_hash.c:560)
==30922==by 0x79F860: zend_shutdown (zend.c:822)
==30922==by 0x741019: php_module_shutdown (main.c:2365)
==30922==by 0x433BE6: main (php_cli.c:1379)
==30922== Address 0x4ca5d948 is not stack'd, malloc'd or (recently) free'd
==30922==
==30922==
==30922== Process terminating with default action of signal 11 (SIGSEGV)
==30922== Access not within mapped region at address 0x4CA5D948
==30922==at 0x77954D: _zend_mm_free_int (zend_alloc.c:2071)
==30922==by 0x795D61: destroy_op_array (zend_opcode.c:356)
==30922==by 0x7AD657: zend_hash_destroy (zend_hash.c:560)
==30922==by 0x79F860: zend_shutdown (zend.c:822)
==30922==by 0x741019: php_module_shutdown (main.c:2365)
==30922==by 0x433BE6: main (php_cli.c:1379)
==30922== If you believe this happened as a result of a stack
==30922== overflow in your program's main thread (unlikely but
==30922== possible), you can try to increase the size of the
==30922== main thread stack using the --main-stacksize= flag.
==30922== The main thread stack size used in this run was 8388608.
==30922==
==30922== HEAP SUMMARY:
==30922== in use at exit: 7,553,441 bytes in 20,136 blocks
==30922== total heap usage: 2,020,750 allocs, 2,000,614 frees, 1,564,536,722
bytes allocated
==30922==
==30922== LEAK SUMMARY:
==30922==definitely lost: 203,536 bytes in 3,635 blocks
==30922==indirectly lost: 4,029,186 bytes in 2,979 blocks
==30922== possibly lost: 70,648 bytes in 43 blocks
==30922==still reachable: 3,250,071 bytes in 13,479 blocks
==30922== suppressed: 0 bytes in 0 blocks
==30922== Rerun with --leak-check=full to see details of leaked memory
==30922==
==30922== For counts of detected and suppressed errors, rerun with: -v
==30922== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
Segmentation fault
[2013-03-01 03:12:22] larue...@php.net
do you get the new valgrind log?
thank
Bug #64297 [Opn]: Segfault after allowed memory exhausted
Edit report at https://bugs.php.net/bug.php?id=64297&edit=1 ID: 64297 User updated by:jille at hexon dot cx Reported by:jille at hexon dot cx Summary:Segfault after allowed memory exhausted Status: Open Type: Bug Package:Reproducible crash Operating System: Linux PHP Version:5.4.12 Block user comment: N Private report: N New Comment: Yes. Exactly the same. Previous Comments: [2013-03-01 09:38:53] larue...@php.net nothing serious, so the segufalt backtrace is the same as before? [2013-03-01 08:15:56] jille at hexon dot cx ==30922== Memcheck, a memory error detector ==30922== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==30922== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==30922== Command: ./sapi/cli/php -d auto_prepend_file=auto_prepend_prepend.lib /data/www/htdocs/wheeler/daemons/daemon_wrapper 1023 live memcrash.php ==30922== ==30922== Invalid read of size 8 ==30922==at 0x77954D: _zend_mm_free_int (zend_alloc.c:2071) ==30922==by 0x795D61: destroy_op_array (zend_opcode.c:356) ==30922==by 0x7AD657: zend_hash_destroy (zend_hash.c:560) ==30922==by 0x79F860: zend_shutdown (zend.c:822) ==30922==by 0x741019: php_module_shutdown (main.c:2365) ==30922==by 0x433BE6: main (php_cli.c:1379) ==30922== Address 0x4ca5d948 is not stack'd, malloc'd or (recently) free'd ==30922== ==30922== ==30922== Process terminating with default action of signal 11 (SIGSEGV) ==30922== Access not within mapped region at address 0x4CA5D948 ==30922==at 0x77954D: _zend_mm_free_int (zend_alloc.c:2071) ==30922==by 0x795D61: destroy_op_array (zend_opcode.c:356) ==30922==by 0x7AD657: zend_hash_destroy (zend_hash.c:560) ==30922==by 0x79F860: zend_shutdown (zend.c:822) ==30922==by 0x741019: php_module_shutdown (main.c:2365) ==30922==by 0x433BE6: main (php_cli.c:1379) ==30922== If you believe this happened as a result of a stack ==30922== overflow in your program's main thread (unlikely but ==30922== possible), you can try to increase the size of the ==30922== main thread stack using the --main-stacksize= flag. ==30922== The main thread stack size used in this run was 8388608. ==30922== ==30922== HEAP SUMMARY: ==30922== in use at exit: 7,553,441 bytes in 20,136 blocks ==30922== total heap usage: 2,020,750 allocs, 2,000,614 frees, 1,564,536,722 bytes allocated ==30922== ==30922== LEAK SUMMARY: ==30922==definitely lost: 203,536 bytes in 3,635 blocks ==30922==indirectly lost: 4,029,186 bytes in 2,979 blocks ==30922== possibly lost: 70,648 bytes in 43 blocks ==30922==still reachable: 3,250,071 bytes in 13,479 blocks ==30922== suppressed: 0 bytes in 0 blocks ==30922== Rerun with --leak-check=full to see details of leaked memory ==30922== ==30922== For counts of detected and suppressed errors, rerun with: -v ==30922== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) Segmentation fault [2013-03-01 03:12:22] larue...@php.net do you get the new valgrind log? thanks [2013-02-25 15:51:09] jille at hexon dot cx Removing the memcache extension doesn't help. (gdb output seems the same, do you want the new valgrind output? (Takes a while)) [2013-02-25 14:56:49] larue...@php.net please remove the memcache extension then test it again. 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=64297 -- Edit this bug report at https://bugs.php.net/bug.php?id=64297&edit=1
Bug #64297 [Opn]: Segfault after allowed memory exhausted
Edit report at https://bugs.php.net/bug.php?id=64297&edit=1
ID: 64297
Updated by: larue...@php.net
Reported by:jille at hexon dot cx
Summary:Segfault after allowed memory exhausted
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Linux
PHP Version:5.4.12
Block user comment: N
Private report: N
New Comment:
nothing serious,
so the segufalt backtrace is the same as before?
Previous Comments:
[2013-03-01 08:15:56] jille at hexon dot cx
==30922== Memcheck, a memory error detector
==30922== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==30922== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==30922== Command: ./sapi/cli/php -d auto_prepend_file=auto_prepend_prepend.lib
/data/www/htdocs/wheeler/daemons/daemon_wrapper 1023 live memcrash.php
==30922==
==30922== Invalid read of size 8
==30922==at 0x77954D: _zend_mm_free_int (zend_alloc.c:2071)
==30922==by 0x795D61: destroy_op_array (zend_opcode.c:356)
==30922==by 0x7AD657: zend_hash_destroy (zend_hash.c:560)
==30922==by 0x79F860: zend_shutdown (zend.c:822)
==30922==by 0x741019: php_module_shutdown (main.c:2365)
==30922==by 0x433BE6: main (php_cli.c:1379)
==30922== Address 0x4ca5d948 is not stack'd, malloc'd or (recently) free'd
==30922==
==30922==
==30922== Process terminating with default action of signal 11 (SIGSEGV)
==30922== Access not within mapped region at address 0x4CA5D948
==30922==at 0x77954D: _zend_mm_free_int (zend_alloc.c:2071)
==30922==by 0x795D61: destroy_op_array (zend_opcode.c:356)
==30922==by 0x7AD657: zend_hash_destroy (zend_hash.c:560)
==30922==by 0x79F860: zend_shutdown (zend.c:822)
==30922==by 0x741019: php_module_shutdown (main.c:2365)
==30922==by 0x433BE6: main (php_cli.c:1379)
==30922== If you believe this happened as a result of a stack
==30922== overflow in your program's main thread (unlikely but
==30922== possible), you can try to increase the size of the
==30922== main thread stack using the --main-stacksize= flag.
==30922== The main thread stack size used in this run was 8388608.
==30922==
==30922== HEAP SUMMARY:
==30922== in use at exit: 7,553,441 bytes in 20,136 blocks
==30922== total heap usage: 2,020,750 allocs, 2,000,614 frees, 1,564,536,722
bytes allocated
==30922==
==30922== LEAK SUMMARY:
==30922==definitely lost: 203,536 bytes in 3,635 blocks
==30922==indirectly lost: 4,029,186 bytes in 2,979 blocks
==30922== possibly lost: 70,648 bytes in 43 blocks
==30922==still reachable: 3,250,071 bytes in 13,479 blocks
==30922== suppressed: 0 bytes in 0 blocks
==30922== Rerun with --leak-check=full to see details of leaked memory
==30922==
==30922== For counts of detected and suppressed errors, rerun with: -v
==30922== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
Segmentation fault
[2013-03-01 03:12:22] larue...@php.net
do you get the new valgrind log?
thanks
[2013-02-25 15:51:09] jille at hexon dot cx
Removing the memcache extension doesn't help. (gdb output seems the same, do
you want the new valgrind output? (Takes a while))
[2013-02-25 14:56:49] larue...@php.net
please remove the memcache extension then test it again.
[2013-02-25 13:48:45] jille at hexon dot cx
Description:
PHP crashes with a segmentation fault when we allocate more memory than allowed.
This happens in 5.4.9 as well as 5.4.12. (No other versions tested.) The only
Different SAPI's yield different behaviours:
* cli prints the OOM-error and sends it to syslog and segfaults immediately.
* cli in gdb or valgrind doesn't print it but syslogs and segfaults the same.
* apache2handler immediately sends the OOM-error to syslog but gives an error
("Cannot redeclare class Bummer") and segfaults afterwards on the next request
to that child.
The class Bummer is included from our auto_prepend_file and I'm sure it isn't
accidentally included twice. Funny thing is sometimes the error is about a
different class (sometimes not even one that was loaded by the
auto_prepend_file but just with a require()) so my guess would be some kind of
memory corruption.
I can reproduce this reliably but failed to create a small reproduction script
and unfortunately can't publish the source of our libraries.
Actual result:
--
The OOM-error:
PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to
allocate 32 bytes) in /path/to/libs/bpm.lib on line 3190
GDB:
Program received signal SIGSEGV, Segmen
[PHP-BUG] Bug #64330 [NEW]: stream_socket_server() creates wrong Abstract Namespace UNIX sockets
From: a dot yamanoi at gmail dot com
Operating system: Linux
PHP version: 5.4.12
Package: Streams related
Bug Type: Bug
Bug description:stream_socket_server() creates wrong Abstract Namespace UNIX
sockets
Description:
stream_socket_server("unix://\x00/foo/bar") doesn't bind
a UNIX domain socket to the abstract namespace correctly.
The actual namespace string seems to be padded right with "\x00"s.
e.g.
"\x00/foo/bar\x00\x00...\x00"
So the stream_socket_client("unix://\x00/foo/bar") test below fails.
According to Bug #44127, stream_socket_client() works fine now.
The problem occurs in PHP 5.4.12 and the latest 5.4 snap(Built on: Mar 01,
2013
02:30 UTC).
Test script:
---
Expected result:
ok
Actual result:
--
PHP Warning: stream_socket_client(): unable to connect to
unix://\0/MyBindName
(Connection refused) in ...
--
Edit bug report at https://bugs.php.net/bug.php?id=64330&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64330&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64330&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64330&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64330&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64330&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64330&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64330&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64330&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64330&r=support
Expected behavior: https://bugs.php.net/fix.php?id=64330&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64330&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64330&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64330&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64330&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64330&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64330&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64330&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64330&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64330&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64330&r=mysqlcfg
Bug #64297 [Fbk->Opn]: Segfault after allowed memory exhausted
Edit report at https://bugs.php.net/bug.php?id=64297&edit=1
ID: 64297
User updated by:jille at hexon dot cx
Reported by:jille at hexon dot cx
Summary:Segfault after allowed memory exhausted
-Status: Feedback
+Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Linux
PHP Version:5.4.12
Block user comment: N
Private report: N
New Comment:
==30922== Memcheck, a memory error detector
==30922== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==30922== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==30922== Command: ./sapi/cli/php -d auto_prepend_file=auto_prepend_prepend.lib
/data/www/htdocs/wheeler/daemons/daemon_wrapper 1023 live memcrash.php
==30922==
==30922== Invalid read of size 8
==30922==at 0x77954D: _zend_mm_free_int (zend_alloc.c:2071)
==30922==by 0x795D61: destroy_op_array (zend_opcode.c:356)
==30922==by 0x7AD657: zend_hash_destroy (zend_hash.c:560)
==30922==by 0x79F860: zend_shutdown (zend.c:822)
==30922==by 0x741019: php_module_shutdown (main.c:2365)
==30922==by 0x433BE6: main (php_cli.c:1379)
==30922== Address 0x4ca5d948 is not stack'd, malloc'd or (recently) free'd
==30922==
==30922==
==30922== Process terminating with default action of signal 11 (SIGSEGV)
==30922== Access not within mapped region at address 0x4CA5D948
==30922==at 0x77954D: _zend_mm_free_int (zend_alloc.c:2071)
==30922==by 0x795D61: destroy_op_array (zend_opcode.c:356)
==30922==by 0x7AD657: zend_hash_destroy (zend_hash.c:560)
==30922==by 0x79F860: zend_shutdown (zend.c:822)
==30922==by 0x741019: php_module_shutdown (main.c:2365)
==30922==by 0x433BE6: main (php_cli.c:1379)
==30922== If you believe this happened as a result of a stack
==30922== overflow in your program's main thread (unlikely but
==30922== possible), you can try to increase the size of the
==30922== main thread stack using the --main-stacksize= flag.
==30922== The main thread stack size used in this run was 8388608.
==30922==
==30922== HEAP SUMMARY:
==30922== in use at exit: 7,553,441 bytes in 20,136 blocks
==30922== total heap usage: 2,020,750 allocs, 2,000,614 frees, 1,564,536,722
bytes allocated
==30922==
==30922== LEAK SUMMARY:
==30922==definitely lost: 203,536 bytes in 3,635 blocks
==30922==indirectly lost: 4,029,186 bytes in 2,979 blocks
==30922== possibly lost: 70,648 bytes in 43 blocks
==30922==still reachable: 3,250,071 bytes in 13,479 blocks
==30922== suppressed: 0 bytes in 0 blocks
==30922== Rerun with --leak-check=full to see details of leaked memory
==30922==
==30922== For counts of detected and suppressed errors, rerun with: -v
==30922== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
Segmentation fault
Previous Comments:
[2013-03-01 03:12:22] larue...@php.net
do you get the new valgrind log?
thanks
[2013-02-25 15:51:09] jille at hexon dot cx
Removing the memcache extension doesn't help. (gdb output seems the same, do
you want the new valgrind output? (Takes a while))
[2013-02-25 14:56:49] larue...@php.net
please remove the memcache extension then test it again.
[2013-02-25 13:48:45] jille at hexon dot cx
Description:
PHP crashes with a segmentation fault when we allocate more memory than allowed.
This happens in 5.4.9 as well as 5.4.12. (No other versions tested.) The only
Different SAPI's yield different behaviours:
* cli prints the OOM-error and sends it to syslog and segfaults immediately.
* cli in gdb or valgrind doesn't print it but syslogs and segfaults the same.
* apache2handler immediately sends the OOM-error to syslog but gives an error
("Cannot redeclare class Bummer") and segfaults afterwards on the next request
to that child.
The class Bummer is included from our auto_prepend_file and I'm sure it isn't
accidentally included twice. Funny thing is sometimes the error is about a
different class (sometimes not even one that was loaded by the
auto_prepend_file but just with a require()) so my guess would be some kind of
memory corruption.
I can reproduce this reliably but failed to create a small reproduction script
and unfortunately can't publish the source of our libraries.
Actual result:
--
The OOM-error:
PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to
allocate 32 bytes) in /path/to/libs/bpm.lib on line 3190
GDB:
Program received signal SIGSEGV, Segmentation fault.
_zend_mm_free_int (heap=0xfb0510, p=0x403aeda8)
at /tmp/php-5.4.12/Zend/zend_alloc.c:2071
2071size = ZEND_MM_BLOCK_SIZE(mm
