Bug #46103 [Opn]: ReflectionObject memory leak
Edit report at https://bugs.php.net/bug.php?id=46103edit=1
ID: 46103
Updated by: larue...@php.net
Reported by:jim dot keller at contextsolutions dot net
Summary:ReflectionObject memory leak
Status: Open
Type: Bug
Package:Performance problem
Operating System: Windows XP
PHP Version:5.2.6
Block user comment: N
Private report: N
New Comment:
it seems because the object pass to ReflectionObject::__construct is stored in
a
custom struct, which can not be reached by gc_collect_cycles.
Previous Comments:
[2011-09-27 05:43:17] larue...@php.net
hmm, seems not a ZE issue
[2011-09-27 05:11:45] larue...@php.net
I can reproduce.. dmitry plz look at this .
[2011-09-27 04:03:04] eric dot muyser at gmail dot com
Not bogus. Still an issue in 5.3.8. https://gist.github.com/1244305
[2008-09-20 12:38:35] fel...@php.net
Try using memory_get_usage(true).
http://docs.php.net/memory-get-usage
I don't found any memory leak.
[2008-09-17 04:26:42] jim dot keller at contextsolutions dot net
Description:
when a reflector is stored in a class property, the reflector appears to stay
in memory after the object is destroyed. This could be related to #33595
Reproduce code:
---
class testclass {
protected $_r;
public function __construct() {
$this-getr();
}
public function getr() {
if ( !$this-_r ) $this-_r = new ReflectionObject($this);
return $this-_r;
}
}
for ( $j = 0; $j 100; $j++ ) {
$t = new testclass();
echo memory_get_usage() . 'br /';
}
Expected result:
memory usage should stay constant
Actual result:
--
memory usage increases with every iteration
--
Edit this bug report at https://bugs.php.net/bug.php?id=46103edit=1
Req #52555 [Com]: Headers_List not returning HTTP Status Code
Edit report at https://bugs.php.net/bug.php?id=52555edit=1 ID: 52555 Comment by: jorrit at ncode dot nl Reported by:dragoo...@php.net Summary:Headers_List not returning HTTP Status Code Status: Closed Type: Feature/Change Request Package:*Web Server problem PHP Version:5.3.3 Assigned To:dragoonis Block user comment: N Private report: N New Comment: It would be nice if the status code could also be set using this function. As mentioned in another comment, the current method of using header() is kind of a hack and the developer needs to provide the irrelevant HTTP version in order to set the response code. Previous Comments: [2010-12-11 14:58:08] marc-bennewitz at arcor dot de Why it's not committed to a branch ? When it will be available ? [2010-12-11 14:47:55] paj...@php.net It is committed in trunk (svn trunk). [2010-12-11 13:37:05] marc-bennewitz at arcor dot de Hi, I can't find the function http_response_code within 5.3.4 and no documentation about it or a message on changelog of 5.3.4. What does it mean Committed to 5.3.99 ? How many years we have to wait :/ It would be very helpful to have some publish time/version. Greetings, Marc [2010-08-09 15:11:17] ka...@php.net Committed to 5.3.99 [2010-08-09 15:10:34] ka...@php.net Automatic comment from SVN on behalf of kalle Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=302033 Log: Implemented FR #52555 (Ability to get HTTP response code) - Patch by Paul Dragoonis 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=52555 -- Edit this bug report at https://bugs.php.net/bug.php?id=52555edit=1
Req #52555 [Com]: Headers_List not returning HTTP Status Code
Edit report at https://bugs.php.net/bug.php?id=52555edit=1
ID: 52555
Comment by: dragoonis at gmail dot com
Reported by:dragoo...@php.net
Summary:Headers_List not returning HTTP Status Code
Status: Closed
Type: Feature/Change Request
Package:*Web Server problem
PHP Version:5.3.3
Assigned To:dragoonis
Block user comment: N
Private report: N
New Comment:
Hey jorrit at ncode dot nl,
If you see the following link, the current implementation of the function
http_response_code is the following:
/* {{{ proto long http_response_code([int response_code])
284Sets a response code, or returns the current HTTP response code */
http://lxr.php.net/opengrok/xref/PHP_5_4/ext/standard/head.c#283
Hope this helps.
Regards,
Paul Dragoonis.
Previous Comments:
[2011-09-27 08:29:49] jorrit at ncode dot nl
It would be nice if the status code could also
be set using this function. As mentioned in
another comment, the current method of
using header() is kind of a hack and the
developer needs to provide the irrelevant
HTTP version in order to set the response
code.
[2010-12-11 14:58:08] marc-bennewitz at arcor dot de
Why it's not committed to a branch ?
When it will be available ?
[2010-12-11 14:47:55] paj...@php.net
It is committed in trunk (svn trunk).
[2010-12-11 13:37:05] marc-bennewitz at arcor dot de
Hi,
I can't find the function http_response_code within 5.3.4 and no
documentation about it or a message on changelog of 5.3.4.
What does it mean Committed to 5.3.99 ?
How many years we have to wait :/
It would be very helpful to have some publish time/version.
Greetings,
Marc
[2010-08-09 15:11:17] ka...@php.net
Committed to 5.3.99
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=52555
--
Edit this bug report at https://bugs.php.net/bug.php?id=52555edit=1
Bug #55768 [Opn-Csd]: PDO_OCI can't resume session when kill Oracle session's
Edit report at https://bugs.php.net/bug.php?id=55768edit=1 ID: 55768 Updated by: tony2...@php.net Reported by:mikhail dot v dot gavrilov at gmail dot com Summary:PDO_OCI can't resume session when kill Oracle session's -Status: Open +Status: Closed Type: Bug Package:Oracle related Operating System: All PHP Version:5.3.8 -Assigned To: +Assigned To:tony2001 Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2011-09-27 09:11:54] tony2...@php.net Automatic comment from SVN on behalf of tony2001 Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=317381 Log: fix bug #55768 (PDO_OCI can't resume Oracle session after it's been killed) [2011-09-23 13:04:06] mikhail dot v dot gavrilov at gmail dot com Description: I found problem in PDO_OCI, if Oracle session killed by ALTER SYSTEM KILL SESSION operator, PDO_OCI can't resume session. For example we can find all PHP active sessions on Oracle: SELECT 'ALTER SYSTEM KILL SESSION ''' || s.sid||','|| s.serial#||''' IMMEDIATE;' FROM gv$session s JOIN gv$process p ON p.addr = s.paddr AND p.inst_id = s.inst_id WHERE s.type != 'BACKGROUND'and s.program like 'php-fpm: pool%'; And run results strings for kill session: ALTER SYSTEM KILL SESSION ',xxx' IMMEDIATE; ALTER SYSTEM KILL SESSION ',xxx' IMMEDIATE; First error that catch PHP script look so: SQLSTATE[01002]: Disconnect error: 3113 OCIStmtExecute: Error while trying to retrieve text for error ORA-03113 separator not found in message(3144)separator not found in message(3142) (/root/rpmbuild/BUILD/php-5.3.8/ext/pdo_oci/oci_statement.c:148) Second and all next error look so: SQLSTATE[HY000]: General error: 3114 OCIStmtExecute: Error while trying to retrieve text for error ORA-03114 (/root/rpmbuild/BUILD/php-5.3.8/ext/pdo_oci/oci_statement.c:148) My connection parameters: PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION PDO::ATTR_PERSISTENT = true PDO::ATTR_AUTOCOMMIT = false -- Edit this bug report at https://bugs.php.net/bug.php?id=55768edit=1
Req #46894 [Com]: Syntax errors in php.ini go unnoticed
Edit report at https://bugs.php.net/bug.php?id=46894edit=1 ID: 46894 Comment by: youdontneedme at o2 dot pl Reported by:ilatypov at infradead dot org Summary:Syntax errors in php.ini go unnoticed Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: Windows XP Pro PHP Version:6CVS-2008-12-18 (snap) Block user comment: N Private report: N New Comment: I've also found syntax error in php.ini in php 5.4b1: In line 601 [both php.ini devel and production] is: : paid for the registration of these arrays and because ENV is not as commonly should be: ; paid for the registration of these arrays and because ENV is not as commonly Note that there is colon as starting char. Previous Comments: [2008-12-18 02:54:25] ilatypov at infradead dot org Description: I accidentally commented out a line in php.ini with a hash mark instead of a semi-colon. It appears that the php.ini parser does not raise an all-important alarm on this kind of error. I spent hours trying to understand why my changes to php.ini were not reflected in ini_get_all(). It would be nice if the php.ini parser threw a message about syntax errors to stderr. Pretty please! -- Edit this bug report at https://bugs.php.net/bug.php?id=46894edit=1
[PHP-BUG] Bug #55796 [NEW]: directive mysql.connect_charset missing
From: Operating system: gentoo linux PHP version: 5.3.8 Package: MySQL related Bug Type: Bug Bug description:directive mysql.connect_charset missing Description: After updating from PHP-5.3.6 to 5.3.8 directive mysql.connect_charset seems to be missing. Is this a bug or wanted? If it's wanted, how should I now handle the db communication? Please give me a reference for this new behaviour. -- Edit bug report at https://bugs.php.net/bug.php?id=55796edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55796r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55796r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55796r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55796r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55796r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55796r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55796r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55796r=needscript Try newer version: https://bugs.php.net/fix.php?id=55796r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55796r=support Expected behavior: https://bugs.php.net/fix.php?id=55796r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55796r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55796r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55796r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55796r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55796r=dst IIS Stability: https://bugs.php.net/fix.php?id=55796r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55796r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55796r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55796r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55796r=mysqlcfg
Bug #55785 [Opn-Bgs]: strtotime() bug
Edit report at https://bugs.php.net/bug.php?id=55785edit=1
ID: 55785
Updated by: cataphr...@php.net
Reported by:pushpender at gmail dot com
Summary:strtotime() bug
-Status: Open
+Status: Bogus
Type: Bug
Package:Unknown/Other Function
Operating System: WAMP
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Expected behavior, as documented at
http://php.net/manual/en/datetime.formats.time.php
Previous Comments:
[2011-09-26 14:43:13] pushpender at gmail dot com
Description:
Strtotime() function creates problem when we convert a date which is in
afternoon time.
Please see the example below. I have tried in 5.3.5 version of PHP on Wamp
Server 2.
//it returns just empty
echo strtotime('Sep 23 2011 16:55PM');
// it returns as intended
echo strtotime('Sep 23 2011 04:55PM');
Test script:
---
echo strtotime('Sep 23 2011 16:55PM');
--
Edit this bug report at https://bugs.php.net/bug.php?id=55785edit=1
[PHP-BUG] Bug #55797 [NEW]: Integer overflow leads to segfault in SdnToGregorian (in optimized builds)
From: cataphract Operating system: Linux/gcc PHP version: 5.3.8 Package: Date/time related Bug Type: Bug Bug description:Integer overflow leads to segfault in SdnToGregorian (in optimized builds) Description: SdnToGregorian has an integer overflow error. This has already been fixed; this report is for reference. See also bug #53574. Test script: --- (x86) php -r 'print_r(cal_from_jd(882858030, CAL_GREGORIAN)); (amd64) php -r 'print_r(cal_from_jd(9223372036854743639, CAL_GREGORIAN));' Expected result: No segfault Actual result: -- Segfault -- Edit bug report at https://bugs.php.net/bug.php?id=55797edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55797r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55797r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55797r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55797r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55797r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55797r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55797r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55797r=needscript Try newer version: https://bugs.php.net/fix.php?id=55797r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55797r=support Expected behavior: https://bugs.php.net/fix.php?id=55797r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55797r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55797r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55797r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55797r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55797r=dst IIS Stability: https://bugs.php.net/fix.php?id=55797r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55797r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55797r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55797r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55797r=mysqlcfg
Bug #55797 [Opn-Csd]: Integer overflow in SdnToGregorian leads to segfault (in optimized builds)
Edit report at https://bugs.php.net/bug.php?id=55797edit=1 ID: 55797 Updated by: cataphr...@php.net Reported by:cataphr...@php.net -Summary:Integer overflow leads to segfault in SdnToGregorian (in optimized builds) +Summary:Integer overflow in SdnToGregorian leads to segfault (in optimized builds) -Status: Open +Status: Closed Type: Bug Package:Date/time related Operating System: Linux/gcc PHP Version:5.3.8 -Assigned To: +Assigned To:cataphract Block user comment: N Private report: N Previous Comments: [2011-09-27 10:21:36] cataphr...@php.net Description: SdnToGregorian has an integer overflow error. This has already been fixed; this report is for reference. See also bug #53574. Test script: --- (x86) php -r 'print_r(cal_from_jd(882858030, CAL_GREGORIAN)); (amd64) php -r 'print_r(cal_from_jd(9223372036854743639, CAL_GREGORIAN));' Expected result: No segfault Actual result: -- Segfault -- Edit this bug report at https://bugs.php.net/bug.php?id=55797edit=1
Req #55166 [Com]: Implement a global limit to the overall number of php processes
Edit report at https://bugs.php.net/bug.php?id=55166edit=1 ID: 55166 Comment by: albertcasademont at gmail dot com Reported by:trollofdarkness at gmail dot com Summary:Implement a global limit to the overall number of php processes Status: Analyzed Type: Feature/Change Request Package:FPM related PHP Version:5.3SVN-2011-07-09 (SVN) Assigned To:fat Block user comment: N Private report: N New Comment: This is an amazing feature guys, thank you very much! Any news on backporting the patch to 5.3? Thanks! Previous Comments: [2011-07-17 17:22:33] trollofdarkness at gmail dot com Ok :) Thank you for your reactivity ;) [2011-07-17 07:43:22] f...@php.net Commited into 5.4. Thx you very much for your help. I'll wait 5.3.7 is out before backporting this to 5.3 branch. [2011-07-17 07:41:53] f...@php.net Automatic comment from SVN on behalf of fat Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=313323 Log: - Implemented FR #55166 (Added process.max to control the number of process FPM can fork) [2011-07-09 12:07:18] trollofdarkness at gmail dot com Description: Hi everyone, I post here a patch that adds the ability to php-fpm to globally limit the global number of php processes. I made it for personal purpose as I have an only 2GB RAM server and several website running on it. The problem is the following, when you have several pools : * Either you choose to have a max_children which is low, you won't go out of memory, but if there is a peak on a specific website while the other ones are quiet, this specific website will be slow, because there will be a queue for the FastCGI requests * Or you choose to have a max_children which is high and you thus allow peaks on your websites, but if ever there is a peak on several website at the same time, chances are that your server will go out of memory. With this patch, I introduce a new configuration directive : [global] max_total_processes = 40 40 will be the total number of php processes authorized to be launched in memory at the same time. When trying to fork a new process (only in the case on pm = dynamic (or pm = ondemand, by the way)) the FPM will look at the current total number of processes that are launched in memory. This is made easy to integrate because FPM already has a fpm_globals.running_children variable referencing the total number of children, all pools summed up. I just had to add a condition, a variable the ability to read a new config option. SO this is a really, really small patch ! But very useful I think. The current uploaded patch file has been made for the PHP 5.3 SVN Branch source. Feel free to adapt it to another version of the sources if you want, you will see that it is just a matter of 4-5 changes in the source code. Hope it will be useful. -- Troll -- Edit this bug report at https://bugs.php.net/bug.php?id=55166edit=1
[PHP-BUG] Bug #55798 [NEW]: Type casting problem
From:
Operating system: at least on Windows
PHP version: Irrelevant
Package: Unknown/Other Function
Bug Type: Bug
Bug description:Type casting problem
Description:
Hi there!
I am having a standard class using numeric keys as properties which works
fine in general. The numeric keys are currently Strings. After serializing
and unserializing the class, the properties will be converted to Integers
which makes them unaccessible. Have a look at the code example below.
Regards
Lukas
Test script:
---
?php
$a = new stdClass();
$a-{0} = 'X';
$a-{1} = 'Y';
var_dump($a);
echo \n0:, $a-{0}, \n1:, $a-{1}, \n\n;
$b = unserialize(serialize($a));
var_dump($b);
echo \n0:, $b-{0}, \n1:, $b-{1}, \n\n;
?
Expected result:
object(stdClass)#2 (2) {
[0]=
string(1) X
[1]=
string(1) Y
}
Actual result:
--
object(stdClass)#2 (2) {
[0]=
string(1) X
[1]=
string(1) Y
}
--
Edit bug report at https://bugs.php.net/bug.php?id=55798edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55798r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55798r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55798r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55798r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55798r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55798r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55798r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55798r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55798r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55798r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55798r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55798r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55798r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55798r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55798r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55798r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55798r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55798r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55798r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55798r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55798r=mysqlcfg
[PHP-BUG] Bug #55800 [NEW]: FILTER_VALIDATE_URL validates wrong
From: Operating system: Ubuntu 11.04 PHP version: Irrelevant Package: Filter related Bug Type: Bug Bug description:FILTER_VALIDATE_URL validates wrong Description: --- From manual page: http://www.php.net/function.filter-var --- FILTER_VALIDATE_URL validates wrong when you set two or more urls together, for example: $url = 'http://php.net/http://bugs.php.net/'; I'm using PHP version 5.3.5 Test script: --- ?php $url = 'http://php.net/http://bugs.php.net/'; var_dump(filter_var($url, FILTER_VALIDATE_URL)); ? Expected result: bool(false) Actual result: -- string(35) http://php.net/http://bugs.php.net/; -- Edit bug report at https://bugs.php.net/bug.php?id=55800edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55800r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55800r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55800r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55800r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55800r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55800r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55800r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55800r=needscript Try newer version: https://bugs.php.net/fix.php?id=55800r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55800r=support Expected behavior: https://bugs.php.net/fix.php?id=55800r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55800r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55800r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55800r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55800r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55800r=dst IIS Stability: https://bugs.php.net/fix.php?id=55800r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55800r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55800r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55800r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55800r=mysqlcfg
Bug #53045 [Com]: broken result of intval()
Edit report at https://bugs.php.net/bug.php?id=53045edit=1
ID: 53045
Comment by: 282130106 at qq dot com
Reported by:remy at wh dot nl
Summary:broken result of intval()
Status: Bogus
Type: Bug
Package:*Math Functions
Operating System: FreeBSD
PHP Version:5.2.14
Block user comment: N
Private report: N
New Comment:
echo intval(pack('a*',log(8,2)));
or
echo floor(pack('a*',log(8,2)));
It's gives 3,i don't now why.
Previous Comments:
[2010-10-18 01:26:52] cataphr...@php.net
Closing as, most likely, this is not related to PHP.
[2010-10-13 09:37:12] remy at wh dot nl
Ok, php 5.2.12 gives the same (broken) result...
[2010-10-13 09:30:55] remy at wh dot nl
[remy@xxx]~ cc -o a.test a.c -lm
[remy@xxx]~ ./a.test
2.9996
I'm not entirely sure, but I did not notice this problem in 5.2.12.
I'll try to recompile 5.2.12 to see if the problem occurred too...
[2010-10-13 09:00:14] ras...@php.net
Not sure there is a whole lot we can do about this. It is a typical IEEE-754
precision problem. Try this simple C program, for example:
[a.c]
#include stdio.h
#include math.h
int main(int argc, char *argv[]) {
printf(%.16f\n,log(8) / log(2));
}
LDFLAGS=-lm make a
./a
I get: 3.
I bet you get 2.9996
or something along those lines.
We might be able to do something clever with PHP's precision setting internally
and round to that precision before doing the truncation there, but in reality
you are dealing with floating point numbers here and whenever you deal with
floating point numbers when programming you have to treat them as
approximations, never as exact values. Unless you are using arbitrary
precision
functions such as the gmp or bcmath function (which are orders of magnitude
slower) you are going to have to account for these imprecisions in your code.
[2010-10-13 08:38:16] remy at wh dot nl
php -i output:
phpinfo()
PHP Version = 5.2.14
System = FreeBSD xxx.xxx.com 7.3-STABLE FreeBSD 7.3-STABLE #7: Thu Jul 15
20:09:49 CEST 2010 r...@xxx.xxx.com:/usr/obj/usr/src/sys/XXX i386
Build Date = Sep 22 2010 20:07:20
Configure Command = './configure' '--with-libxml-dir=/usr/local/lib'
'--with-config-file-path=/home/www/php' '--with-zlib' '--with-mysql'
'--with-pgsql' '--enable-calendar' '--enable-mbstring'
'--with-apxs2=/home/www/bin/apxs' '--enable-ftp' '--with-gd' '--enable-mbregex'
'--enable-gd-native-ttf' '--with-png-dir=/usr/local/lib'
'--with-jpeg-dir=/usr/local/lib' '--with-xpm-dir=/usr/X11R6/lib'
'--with-freetype-dir=/usr/local/lib' '--with-iconv' '--with-curl' '--with-bz2'
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=53045
--
Edit this bug report at https://bugs.php.net/bug.php?id=53045edit=1
Bug #55800 [Opn-Bgs]: FILTER_VALIDATE_URL validates wrong
Edit report at https://bugs.php.net/bug.php?id=55800edit=1 ID: 55800 Updated by: ahar...@php.net Reported by:giuseppem at gmail dot com Summary:FILTER_VALIDATE_URL validates wrong -Status: Open +Status: Bogus Type: Bug Package:Filter related Operating System: Ubuntu 11.04 PHP Version:Irrelevant Block user comment: N Private report: N New Comment: That's a valid URL: in this case, the path component is http://bugs.php.net/, and that's explicitly allowed by RFC 3986 -- path components can include colons. Previous Comments: [2011-09-27 13:28:32] giuseppem at gmail dot com Description: --- From manual page: http://www.php.net/function.filter-var --- FILTER_VALIDATE_URL validates wrong when you set two or more urls together, for example: $url = 'http://php.net/http://bugs.php.net/'; I'm using PHP version 5.3.5 Test script: --- ?php $url = 'http://php.net/http://bugs.php.net/'; var_dump(filter_var($url, FILTER_VALIDATE_URL)); ? Expected result: bool(false) Actual result: -- string(35) http://php.net/http://bugs.php.net/; -- Edit this bug report at https://bugs.php.net/bug.php?id=55800edit=1
Bug #55475 [Asn]: is_a() triggers autoloader
Edit report at https://bugs.php.net/bug.php?id=55475edit=1 ID: 55475 Updated by: paj...@php.net Reported by:mads at gartneriet dot dk Summary:is_a() triggers autoloader Status: Assigned Type: Bug Package:Scripting Engine problem PHP Version:5.3.7 Assigned To:dmitry Block user comment: N Private report: N -CVE-ID: +CVE-ID: 2011-3379 New Comment: Add CVE # Previous Comments: [2011-09-27 09:35:31] ala...@php.net Automatic comment from SVN on behalf of alan_k Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=317382 Log: document fix for #55475 in NEWS [2011-09-26 19:57:09] paj...@php.net that's what I meant. [2011-09-26 19:54:23] henri at nerv dot fi CVE already requested with A LOT of conversation: http://www.openwall.com/lists/oss-security/2011/09/24/2 [2011-09-26 19:45:05] paj...@php.net @cipri Please contact secur...@php.net prior to request a CVE, to avoid double requests or confusing information. or mark a bug as security issue so we will catch it (and the sec guys of the linux distro as well) :) [2011-09-26 19:38:53] togos00 at gmail dot com Even if the new behavior is not a bug, per se, it is definitely surprising. is_a( $string, $className ) returning true would imply that $string is an instance of $className, which obviously it is not, as it is a string and not even an object. Having a separate function such as is_subclass_of( $className1, $className2 ) has the dual benefits of being more intuitive and not breaking old code. 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=55475 -- Edit this bug report at https://bugs.php.net/bug.php?id=55475edit=1
[PHP-BUG] Bug #55801 [NEW]: Behavior of unserialize has changed
From: Operating system: Linux (Fedora 15) PHP version: 5.4.0beta1 Package: Variables related Bug Type: Bug Bug description:Behavior of unserialize has changed Description: There is a regression or change in how object structures are serialized or unserialized in PHP's 5.4.x branch. I am sorry that I cannot give a more detailed explanation and say what has changed and causes this issue, but an object cache for one of my applications fails with all PHP 5.4.x version, while it works with all PHP 5.2.x and PHP 5.3.x versions. I would expect that this behavior change would also affect other applications or libraries that utilize PHP's (un)serialize functions. Test script: --- #!/bin/sh PHP_BIN=/usr/local/bin/php540 cd /tmp git clone https://github.com/pdepend/pdepend.git cd pdepend $PHP_BIN ./src/bin/pdepend.php --summary-xml=sum.xml src/main/ $PHP_BIN ./src/bin/pdepend.php --summary-xml=sum.xml src/main/ Expected result: PHP_Depend @package_version@ by Manuel Pichler Parsing source files: 60 120 180 196 Executing CyclomaticComplexity-Analyzer: 1200 ..1818 Executing ClassLevel-Analyzer: 1200 ..1647 Executing CodeRank-Analyzer: .. 217 Executing Coupling-Analyzer: 1200 ..2048 Executing Hierarchy-Analyzer: 1200 1852 Executing Inheritance-Analyzer: ...549 Executing NPathComplexity-Analyzer: 1200 ... 1830 Executing NodeCount-Analyzer: 1200 ..1564 Executing NodeLoc-Analyzer: 1200 1766 Generating pdepend log files, this may take a moment. 00:16; Memory: 124.00Mb Actual result: -- PHP_Depend @package_version@ by Manuel Pichler Parsing source files: 60 120 .PHP Warning: Creating default object from empty value in /tmp/pdepend/src/main/php/PHP/Depend/Code/ASTNode.php on line 569 Warning: Creating default object from empty value in /tmp/pdepend/src/main/php/PHP/Depend/Code/ASTNode.php on line 569 .PHP Warning: Creating default object from empty value in /tmp/pdepend/src/main/php/PHP/Depend/Code/ASTNode.php on line 569 Warning: Creating default object from empty value in /tmp/pdepend/src/main/php/PHP/Depend/Code/ASTNode.php on line 569 .PHP Warning: Creating default object from empty value in /tmp/pdepend/src/main/php/PHP/Depend/Code/ASTNode.php on line 569 Warning: Creating default object from empty value in /tmp/pdepend/src/main/php/PHP/Depend/Code/ASTNode.php on line 569 PHP Warning: Creating default object from empty value in /tmp/pdepend/src/main/php/PHP/Depend/Code/ASTNode.php on line 569 Warning: Creating default object from empty value in /tmp/pdepend/src/main/php/PHP/Depend/Code/ASTNode.php on line 569 PHP Warning: Creating default object from empty value in /tmp/pdepend/src/main/php/PHP/Depend/Code/ASTNode.php on line 569 Warning: Creating default object from empty value in /tmp/pdepend/src/main/php/PHP/Depend/Code/ASTNode.php on line 569 . 180 ...PHP Warning: Creating default object from empty value in /tmp/pdepend/src/main/php/PHP/Depend/Code/ASTNode.php on line 569 Warning: Creating default object from empty value in /tmp/pdepend/src/main/php/PHP/Depend/Code/ASTNode.php on line 569 . 196 Executing CyclomaticComplexity-Analyzer: PHP Fatal error: Call to a member function findChildrenOfType() on a non-object in /tmp/pdepend/src/main/php/PHP/Depend/Code/AbstractClassOrInterface.php on line 268 Fatal error: Call to a member function findChildrenOfType() on a non-object in
Bug #55801 [Opn-Fbk]: Behavior of unserialize has changed
Edit report at https://bugs.php.net/bug.php?id=55801edit=1 ID: 55801 Updated by: paj...@php.net Reported by:mapi at pdepend dot org Summary:Behavior of unserialize has changed -Status: Open +Status: Feedback Type: Bug Package:Variables related Operating System: Linux (Fedora 15) PHP Version:5.4.0beta1 Block user comment: N Private report: N New Comment: Is it about objects being serialized and stored using 5.3 and unserialized using 5.4? And it fails to unserialize them? Or are you doing this proecess manually? Previous Comments: [2011-09-27 20:06:13] mapi at pdepend dot org Description: There is a regression or change in how object structures are serialized or unserialized in PHP's 5.4.x branch. I am sorry that I cannot give a more detailed explanation and say what has changed and causes this issue, but an object cache for one of my applications fails with all PHP 5.4.x version, while it works with all PHP 5.2.x and PHP 5.3.x versions. I would expect that this behavior change would also affect other applications or libraries that utilize PHP's (un)serialize functions. Test script: --- #!/bin/sh PHP_BIN=/usr/local/bin/php540 cd /tmp git clone https://github.com/pdepend/pdepend.git cd pdepend $PHP_BIN ./src/bin/pdepend.php --summary-xml=sum.xml src/main/ $PHP_BIN ./src/bin/pdepend.php --summary-xml=sum.xml src/main/ Expected result: PHP_Depend @package_version@ by Manuel Pichler Parsing source files: 60 120 180 196 Executing CyclomaticComplexity-Analyzer: 1200 ..1818 Executing ClassLevel-Analyzer: 1200 ..1647 Executing CodeRank-Analyzer: .. 217 Executing Coupling-Analyzer: 1200 ..2048 Executing Hierarchy-Analyzer: 1200 1852 Executing Inheritance-Analyzer: ...549 Executing NPathComplexity-Analyzer: 1200 ... 1830 Executing NodeCount-Analyzer: 1200 ..1564 Executing NodeLoc-Analyzer: 1200 1766 Generating pdepend log files, this may take a moment. 00:16; Memory: 124.00Mb Actual result: -- PHP_Depend @package_version@ by Manuel Pichler Parsing source files: 60 120 .PHP Warning: Creating default object from empty value in /tmp/pdepend/src/main/php/PHP/Depend/Code/ASTNode.php on line 569 Warning: Creating default object from empty value in /tmp/pdepend/src/main/php/PHP/Depend/Code/ASTNode.php on line 569 .PHP Warning: Creating default object from empty value in /tmp/pdepend/src/main/php/PHP/Depend/Code/ASTNode.php on line 569 Warning: Creating default object from empty value in /tmp/pdepend/src/main/php/PHP/Depend/Code/ASTNode.php on line 569 .PHP Warning: Creating default object from empty value in /tmp/pdepend/src/main/php/PHP/Depend/Code/ASTNode.php on line 569 Warning: Creating default object from empty value in /tmp/pdepend/src/main/php/PHP/Depend/Code/ASTNode.php on line 569 PHP Warning: Creating default object from empty value in /tmp/pdepend/src/main/php/PHP/Depend/Code/ASTNode.php on line 569 Warning: Creating default object from empty value in /tmp/pdepend/src/main/php/PHP/Depend/Code/ASTNode.php on line 569 PHP Warning: Creating default object from empty value in /tmp/pdepend/src/main/php/PHP/Depend/Code/ASTNode.php on line 569 Warning: Creating default object from empty value in /tmp/pdepend/src/main/php/PHP/Depend/Code/ASTNode.php on line 569 . 180 ...PHP Warning: Creating default object from empty value in
Req #55654 [Com]: ereg() behavior for preg_match
Edit report at https://bugs.php.net/bug.php?id=55654edit=1 ID: 55654 Comment by: imaggens at gmail dot com Reported by:imaggens at gmail dot com Summary:ereg() behavior for preg_match Status: Open Type: Feature/Change Request Package:Regexps related Operating System: Windows 7 PHP Version:5.3SVN-2011-09-09 (snap) Block user comment: N Private report: N New Comment: Hi, Sorry for the long time to reply. I was unable to keep this task for a while. Where exactly you think should I add this lookahead assertion? As far as I know, it should be added one line after the last comment (the one which make all the floating part optional). But I have no success. As you said I can't match against start / end anchors because the float number may appear in several parts of input string. Previous Comments: [2011-09-15 15:37:25] ni...@php.net I don't know what your exact use case is, but ... if you want to check that a string is a float, you should surround the regex with ^ and $ anchors. I.e. it will match the complete string, not just parts of it. ... if you are searching for floats in a longer text, you could simply use a negative lookahead assertion (?![0-9]) to ensure it isn't followed by a number. If neither are what you need, could you maybe explain your problem further? [2011-09-09 12:30:43] imaggens at gmail dot com Description: Consideration. I choosen September Snapshot, because I could not find mine in the list. My installation report to PHP 5.3.3. Build Date: Jul 21 2010 20:25:38. Alright. I would like to ask, if is there any possibility to add, maybe through another non-Perl compatible modifier, the behavior we had with ereg(). The behavior I'm talking about refers to match as much as possible instead of stop at very first valid match. This is useful sometimes. In my case, specially to validate input data against a RFC specification. Look at this snippet: https://ideone.com/sC6mA I tried to make it as much specific as I could. The intention was to validate float point numbers, between zero and 1, with none and up to three decimals, denying invalid floats, such as 0.00 (same as zero) or 1.0 (same as 1). But, the lazy behavior of preg_match() is accepting the code above, where 0.3444 should be denied, because of its 4 decimals. But since 0.344 is valid in the last length verification (one and up to three), the function accepts the input data, and the last digit is simply ignored, because preg_match() already caracterized 0.344 as valid. I hope you understand Expected result: An empty array Actual result: -- A match -- Edit this bug report at https://bugs.php.net/bug.php?id=55654edit=1
Bug #55800 [Bgs]: FILTER_VALIDATE_URL validates wrong
Edit report at https://bugs.php.net/bug.php?id=55800edit=1 ID: 55800 User updated by:giuseppem at gmail dot com Reported by:giuseppem at gmail dot com Summary:FILTER_VALIDATE_URL validates wrong Status: Bogus Type: Bug Package:Filter related Operating System: Ubuntu 11.04 PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Oh. I was thinking that was scheme://authority/scheme://authority and not the path. Now it's clear, thank you. Previous Comments: [2011-09-27 17:44:11] ahar...@php.net That's a valid URL: in this case, the path component is http://bugs.php.net/, and that's explicitly allowed by RFC 3986 -- path components can include colons. [2011-09-27 13:28:32] giuseppem at gmail dot com Description: --- From manual page: http://www.php.net/function.filter-var --- FILTER_VALIDATE_URL validates wrong when you set two or more urls together, for example: $url = 'http://php.net/http://bugs.php.net/'; I'm using PHP version 5.3.5 Test script: --- ?php $url = 'http://php.net/http://bugs.php.net/'; var_dump(filter_var($url, FILTER_VALIDATE_URL)); ? Expected result: bool(false) Actual result: -- string(35) http://php.net/http://bugs.php.net/; -- Edit this bug report at https://bugs.php.net/bug.php?id=55800edit=1
Bug #47494 [Com]: htmlspecialchars does not throw E_WARNING on multibyte problems
Edit report at https://bugs.php.net/bug.php?id=47494edit=1
ID: 47494
Comment by: rudd-o at rudd-o dot com
Reported by:philipp dot feigl at gmail dot com
Summary:htmlspecialchars does not throw E_WARNING on
multibyte problems
Status: Bogus
Type: Bug
Package:Strings related
Operating System: CentOS5
PHP Version:5.2.8
Block user comment: N
Private report: N
New Comment:
Reported to /r/lolphp here:
http://www.reddit.com/r/lolphp/comments/kso6p/if_error_reporting_is_on_htmlspecia
lchars_will/
Do you guys realize there is an ENTIRE COMMUNITY of people devoted to the
collective practice of FACEPALMING at PHP's fails?
Hahaha.
Previous Comments:
[2011-06-01 18:36:28] larry at garfieldtech dot com
This bug should be reopened, not just documented. Haven't we learned our
lesson with magic_quotes and its ilk? Designing PHP to try and save the user
when the user does something stupid always backfires. Always. MySQL has the
same problem, and it backfires there, too.
The current logic is simply backward. When display_errors is on, you get all
errors except from this function. When display_errors is off, you get no
errors except from this one function. There is no logical reason for that.
I'm working on a project that has been stalled for over a week while we try to
figure out what's wrong with the character encoding configuration on our
production server, only to realize that the data is (probably) bad but we
didn't know it because of this bug.
This is a bug and should be fixed, not simply documented as dumb.
If a production server is misconfigured, that's not the job of the language to
fix. All that does is, as another commenter noted, punish those who configure
their servers properly. If anything, it is a security hole for people who DO
configure their server properly by turning off display_errors, as then these
strings would get echoed in production. How is that helpful to anyone?
[2011-05-03 17:48:02] pinkgothic at gmail dot com
Could this bug please get REOPENED as a documentation bug
then? As already stated, the absence of the information in
the documentation can be crippling for people who do things
-right-. (Admittedly right now htmlspecialchars has my
comment on the subject, but that's hardly official...)
(Sidenote: You might also want to close Bug #54109 as bogus
for consistency.)
[2011-05-03 17:33:35] ras...@php.net
This isn't a logic error. The idea is to prevent a user-triggered information
leak by not showing this error to the user in case a production server is
misconfigured and running with display_errors turned on.
[2011-05-02 14:48:50] example at example dot com
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too! Me too!
Me too! Me too! Me too! Me too!
[2011-03-10 18:05:11] dtajchre...@php.net
I say this is a logic error. Bugs #54109 and #52397 also mention the same
behavior in two other spots of code.
php_error_docref already handles display_errors configurations... I don't how
this would be considered correct/intended
behavior..
Questionable logic: http://svn.php.net/viewvc/php/php-
src/branches/PHP_5_3/ext/standard/html.c?view=markup#l1145
if(!PG(display_errors)) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, Invalid multibyte sequence
in argument);
}
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=47494
--
Edit this bug report at https://bugs.php.net/bug.php?id=47494edit=1
[PHP-BUG] Bug #55802 [NEW]: PDO_ATTR_EMULATE_PREPARES not supported for getAttribute() in pdo_mysql
From: Operating system: Linux PHP version: 5.3.8 Package: PDO related Bug Type: Bug Bug description:PDO_ATTR_EMULATE_PREPARES not supported for getAttribute() in pdo_mysql Description: I was trying to diagnose another issue and testing with PDO_ATTR_EMULATE_PREPARES enabled and disabled and discovered that PDO::getAttribute() for mysql doesn't support it. Checking the source I see that it is a synonym for PDO_MYSQL_ATTR_DIRECT_QUERY. However both are supported in PDO::setAttribute() but only PDO_MYSQL_ATTR_DIRECT_QUERY is supported in getAttribute(). It always returns false. I attach a patch. -- Edit bug report at https://bugs.php.net/bug.php?id=55802edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55802r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55802r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55802r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55802r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55802r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55802r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55802r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55802r=needscript Try newer version: https://bugs.php.net/fix.php?id=55802r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55802r=support Expected behavior: https://bugs.php.net/fix.php?id=55802r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55802r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55802r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55802r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55802r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55802r=dst IIS Stability: https://bugs.php.net/fix.php?id=55802r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55802r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55802r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55802r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55802r=mysqlcfg
Bug #47675 [NoF-ReO]: File descriptor leaked due to HAVE_BROKEN_GETCWD
Edit report at https://bugs.php.net/bug.php?id=47675edit=1 ID: 47675 Updated by: jsjoh...@php.net Reported by:cs at ecn dot purdue dot edu Summary:File descriptor leaked due to HAVE_BROKEN_GETCWD -Status: No Feedback +Status: Re-Opened Type: Bug Package:Apache2 related Operating System: Solaris 10 PHP Version:5.2.9 Block user comment: N Private report: N Previous Comments: [2011-09-28 00:58:18] jsjoh...@php.net I've heard that this was fixed in PHP 5.3.5. It's not listed in the release notes from what I can see, so can someone confirm if 5.3.5 addresses this issue? [2011-05-18 18:23:29] pyorke at joyent dot com This still broken in PHP 5.3.3 When is it going to be fixed [2010-08-08 10:20:55] php at marino dot st I've been trying to track down this file descriptor leakage problem for months. I was stuck on 5.2.8 because of it. I confirm that the issue is specifically with Solaris 10. I have opensolaris sxce nevada 130 locally and I've not seen FD leakage on it. I confirm that patch suggested by bryan at stansell dot org seemed to correct the problem. FYI, PHP was spawned and remains persistent for use with the Litespeed web server (uses the LSAPI interface), so it would run out of file descriptors between 1 and 12 hours on my site. It's a bit disappointing that this error has been present for 5 releases and was never fixed. [2010-01-12 15:40:45] bryan at stansell dot org I finally got a chance to test a theory. Looks like the volatile attribute fixed things for me. #if HAVE_BROKEN_GETCWD volatile int old_cwd_fd = -1; #else Once I added that, the setjmp/longjmp worked as expected. I got the idea from the manpage on Solaris: The values of register and automatic variables are unde- fined. Register or automatic variables whose value must be relied upon must be declared as volatile. Perhaps it's a gcc/gas/Solaris/x86 optimization somewhere that overlooked the case, but this is a workaround. Of course, undefining HAVE_BROKEN_GETCWD for Solaris also works, if you have a web tree that isn't restricted in some way. [2010-01-09 06:59:22] bryan at stansell dot org I've encountered this problem using OpenSolaris (snv_115), apache 1.3.41 and php-5.2.12 (via mod_php5). It was also a problem with php 5.2.9. My apache processes continue to accumulate open files pointing to the directory which contains the php script. I am using gcc 4.3.3, gnu as, and solaris ld. It makes me wonder if it's a compiler-related thing. I was also talking to a friend and we checked his httpd processes and saw the same file descriptor leak. His setup is Solaris 9 (sparc), apache 1.3.41, php 4.4.8, and gcc 4.0.2. I worked around my problem by unsetting HAVE_BROKEN_GETCWD. I have a couple other ideas on possibly narrowing down the problem, but I haven't had a chance to try them. 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=47675 -- Edit this bug report at https://bugs.php.net/bug.php?id=47675edit=1
Bug #47675 [Com]: File descriptor leaked due to HAVE_BROKEN_GETCWD
Edit report at https://bugs.php.net/bug.php?id=47675edit=1 ID: 47675 Comment by: jsjoh...@php.net Reported by:cs at ecn dot purdue dot edu Summary:File descriptor leaked due to HAVE_BROKEN_GETCWD Status: No Feedback Type: Bug Package:Apache2 related Operating System: Solaris 10 PHP Version:5.2.9 Block user comment: N Private report: N New Comment: I've heard that this was fixed in PHP 5.3.5. It's not listed in the release notes from what I can see, so can someone confirm if 5.3.5 addresses this issue? Previous Comments: [2011-05-18 18:23:29] pyorke at joyent dot com This still broken in PHP 5.3.3 When is it going to be fixed [2010-08-08 10:20:55] php at marino dot st I've been trying to track down this file descriptor leakage problem for months. I was stuck on 5.2.8 because of it. I confirm that the issue is specifically with Solaris 10. I have opensolaris sxce nevada 130 locally and I've not seen FD leakage on it. I confirm that patch suggested by bryan at stansell dot org seemed to correct the problem. FYI, PHP was spawned and remains persistent for use with the Litespeed web server (uses the LSAPI interface), so it would run out of file descriptors between 1 and 12 hours on my site. It's a bit disappointing that this error has been present for 5 releases and was never fixed. [2010-01-12 15:40:45] bryan at stansell dot org I finally got a chance to test a theory. Looks like the volatile attribute fixed things for me. #if HAVE_BROKEN_GETCWD volatile int old_cwd_fd = -1; #else Once I added that, the setjmp/longjmp worked as expected. I got the idea from the manpage on Solaris: The values of register and automatic variables are unde- fined. Register or automatic variables whose value must be relied upon must be declared as volatile. Perhaps it's a gcc/gas/Solaris/x86 optimization somewhere that overlooked the case, but this is a workaround. Of course, undefining HAVE_BROKEN_GETCWD for Solaris also works, if you have a web tree that isn't restricted in some way. [2010-01-09 06:59:22] bryan at stansell dot org I've encountered this problem using OpenSolaris (snv_115), apache 1.3.41 and php-5.2.12 (via mod_php5). It was also a problem with php 5.2.9. My apache processes continue to accumulate open files pointing to the directory which contains the php script. I am using gcc 4.3.3, gnu as, and solaris ld. It makes me wonder if it's a compiler-related thing. I was also talking to a friend and we checked his httpd processes and saw the same file descriptor leak. His setup is Solaris 9 (sparc), apache 1.3.41, php 4.4.8, and gcc 4.0.2. I worked around my problem by unsetting HAVE_BROKEN_GETCWD. I have a couple other ideas on possibly narrowing down the problem, but I haven't had a chance to try them. [2009-06-29 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. 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=47675 -- Edit this bug report at https://bugs.php.net/bug.php?id=47675edit=1
Bug #55660 [Opn-Csd]: SplFixedArray::fromArray causing segmentation fault 11
Edit report at https://bugs.php.net/bug.php?id=55660edit=1 ID: 55660 Updated by: larue...@php.net Reported by:rewilliams at crystaltech dot com Summary:SplFixedArray::fromArray causing segmentation fault 11 -Status: Open +Status: Closed Type: Bug Package:Reproducible crash Operating System: Mac OS X 10.7.1 PHP Version:5.3.8 -Assigned To: +Assigned To:laruence Block user comment: N Private report: N New Comment: closed Previous Comments: [2011-09-13 16:19:54] rewilliams at crystaltech dot com Well, it doesn't seem to show itself under 5.3.8 on the Linux server, so maybe this was fixed and I just missed the report. Since my original report, I've had several similar cases that happened somewhat randomly under 5.3.6, so I'll just keep an eye out and if I get something that's reproducible under the latest version, I'll file another bug. In the mean time, you can close this bug. Thanks for your time. [2011-09-13 02:37:45] larue...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Hi, I still can not reproduce with your data.csv, could you try with the 5.3-trunk? [2011-09-12 18:05:53] rewilliams at crystaltech dot com laruence@: I just caught that you stated your test file had 1005 lines. I'm not sure if you misread what I wrote or if you mistyped what you tested, but the test file I used was 10005 lines - you're off by an order of magnitude. I uploaded my file to Dropbox. You can grab it here: http://dl.dropbox.com/u/9434155/data.csv If you're able to grab it and attach it to the bug or make it available someplace more permanent, that would be great. [2011-09-12 18:00:42] rewilliams at crystaltech dot com FWIW, I just reproduced it on a Linux server running 5.3.4. I'm working on getting a backtrace, but I need to build a debug version of PHP first. [2011-09-10 03:59:47] larue...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. I can not reproduce it with a test csv file(1005 line, 13 cloumns) with 5.3 trunk 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=55660 -- Edit this bug report at https://bugs.php.net/bug.php?id=55660edit=1
Bug #39388 [Com]: provide --with-libzip-dir configure option to allow usage of system's libzip
Edit report at https://bugs.php.net/bug.php?id=39388edit=1 ID: 39388 Comment by: glen at delfi dot ee Reported by:crrodriguez at opensuse dot org Summary:provide --with-libzip-dir configure option to allow usage of system's libzip Status: Bogus Type: Bug Package:Zip Related Operating System: Linux PHP Version:5CVS-2006-11-05 (CVS) Assigned To:pajoye Block user comment: N Private report: N New Comment: i updated the patch to really link with system libzip and not to link with libz (as that it is libzip dependency not zip ext in case of system libzip) http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/php/system-libzip.patch? sortby=date i would reformat the patch indent if there's any interest it getting applied upstream, it's currently broken indent just to get diffs better to understand (and update with new upstream changes) Previous Comments: [2011-07-20 17:40:51] crrodriguez at opensuse dot org tcallawa at redhat dot com : Great, patches look OK, will try them asap in openSUSE packages. [2011-07-20 15:54:40] tcallawa at redhat dot com It doesn't look like 0.10 will work with PHP's zip extension out of the tarball, because it is still missing some necessary features that were never upstreamed (as far as I can tell). I've worked up a patch against 0.10 that adds the necessary functionality, and sent a copy to the libzip upstream for consideration. A copy of that patch can be found here: http://spot.fedorapeople.org/libzip-0.10-php-changes.patch Then, I reworked ext/zip/config.m4 to enable an option to use libzip (the system copy). That patch is here: http://spot.fedorapeople.org/php-5.3.6-libzip.patch I couldn't figure out a good way to test for overwrite support (the bits that the first patch add), so the configure tests will pass on a system libzip without the php changes applied, but I don't think the compile will succeed (it definitely won't work properly). [2011-04-06 08:33:48] oeriksson at mandriva dot com With the recent security flaws related to libzip it's desirable to enable this option. Isn't the latest http://www.nih.at/libzip/libzip-0.10.tar.bz2 going to work fine now? [2006-11-05 19:21:28] paj...@php.net There is no need of it. And no, you should *really* not use an external library. The version bundled have more fixes and features than the released lib. Most of them are already in the libzip cvs, other not. [2006-11-05 03:50:59] crrodriguez at opensuse dot org Description: Currently there is no --with-libzip-dir to easily allow distributions to use independantly packaged system libraries. Reproduce code: --- ./configure --help | grep zip Expected result: --enable-zipInclude Zip read/write support. --with-zlib-dir=DIR zip: Set the path to libz install prefix. --with-libzip=DIR zip : path to libzip sources if not using the bundled library. Actual result: -- --enable-zipInclude Zip read/write support. --with-zlib-dir=DIR zip: Set the path to libz install prefix. -- Edit this bug report at https://bugs.php.net/bug.php?id=39388edit=1
