Bug #54680 [Opn->Csd]: missing TRACK_VARS_SERVER check
Edit report at http://bugs.php.net/bug.php?id=54680&edit=1
ID: 54680
Updated by: fel...@php.net
Reported by:cxib at securityreason dot com
-Summary:missing TRACK_VARS_SERVER
+Summary:missing TRACK_VARS_SERVER check
-Status: Open
+Status: Closed
Type: Bug
Package:*General Issues
Operating System: NetBSD
PHP Version:5.3.6
-Assigned To:
+Assigned To:felipe
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/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2011-06-12 04:47:50] fel...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revision&revision=312079
Log: - Fixed bug #54680 (missing TRACK_VARS_SERVER check)
[2011-05-07 00:44:53] cxib at securityreason dot com
Description:
./work/php-5.3.6/ext/standard/basic_functions.c:if
((zend_hash_find(HASH_OF(PG(http_globals)[TRACK_VARS_SERVER]), "argv",
sizeof("argv"), (void **) &args) != FAILURE ||
Some 'if' condition is missing here. In all others [TRACK_VARS SERVER]
calls, we can see used if condition like
if (!PG(http_globals)[TRACK_VARS_SERVER]) {
Only in basic_function.c is missing. Please see..
# find . -name "*.c"|xargs grep '\[TRACK_VARS_SERVER\]'
./work/php-5.3.6/ext/phar/phar_object.c:if
(!PG(http_globals)[TRACK_VARS_SERVER]) {
./work/php-5.3.6/ext/phar/phar_object.c:_SERVER =
Z_ARRVAL_P(PG(http_globals)[TRACK_VARS_SERVER]);
./work/php-5.3.6/ext/phar/phar_object.c:if
(PG(http_globals)[TRACK_VARS_SERVER]) {
./work/php-5.3.6/ext/phar/phar_object.c:
HashTable *_server = Z_ARRVAL_P(PG(http_globals)[TRACK_VARS_SERVER]);
./work/php-5.3.6/ext/soap/soap.c: if
(PG(http_globals)[TRACK_VARS_SERVER] &&
./work/php-5.3.6/ext/soap/soap.c:
zend_hash_find(PG(http_globals)[TRACK_VARS_SERVER]->value.ht,
"HTTP_USER_AGENT", sizeof("HTTP_USER_AGENT"), (void **) &agent_name) ==
SUCCESS &&
./work/php-5.3.6/ext/zlib/zlib.c: if
(!PG(http_globals)[TRACK_VARS_SERVER]
./work/php-5.3.6/ext/zlib/zlib.c: ||
zend_hash_find(PG(http_globals)[TRACK_VARS_SERVER]->value.ht,
"HTTP_ACCEPT_ENCODING", sizeof("HTTP_ACCEPT_ENCODING"), (void **)
&a_encoding) == FAILURE
./work/php-5.3.6/ext/zlib/zlib.c: if
(!PG(http_globals)[TRACK_VARS_SERVER]
./work/php-5.3.6/ext/zlib/zlib.c: ||
zend_hash_find(PG(http_globals)[TRACK_VARS_SERVER]->value.ht,
"HTTP_ACCEPT_ENCODING", sizeof("HTTP_ACCEPT_ENCODING"), (void **)
&a_encoding) == FAILURE
./work/php-5.3.6/ext/session/session.c: if (!PS(use_only_cookies) &&
!PS(id) && PG(http_globals)[TRACK_VARS_SERVER] &&
./work/php-5.3.6/ext/session/session.c:
zend_hash_find(Z_ARRVAL_P(PG(http_globals)[TRACK_VARS_SERVER]),
"REQUEST_URI", sizeof("REQUEST_URI"), (void **) &data) == SUCCESS &&
./work/php-5.3.6/ext/session/session.c:
PG(http_globals)[TRACK_VARS_SERVER] &&
./work/php-5.3.6/ext/session/session.c:
zend_hash_find(Z_ARRVAL_P(PG(http_globals)[TRACK_VARS_SERVER]),
"HTTP_REFERER", sizeof("HTTP_REFERER"), (void **) &data) == SUCCESS &&
./work/php-5.3.6/ext/standard/basic_functions.c:if
((zend_hash_find(HASH_OF(PG(http_globals)[TRACK_VARS_SERVER]), "argv",
sizeof("argv"), (void **) &args) != FAILURE ||
./work/php-5.3.6/ext/standard/browscap.c: if
(!PG(http_globals)[TRACK_VARS_SERVER] ||
./work/php-5.3.6/ext/standard/browscap.c:
zend_hash_find(HASH_OF(PG(http_globals)[TRACK_VARS_SERVER]),
"HTTP_USER_AGENT", sizeof("HTTP_USER_AGENT"), (void **)
&http_user_agent) == FAILURE
./work/php-5.3.6/main/php_variables.c: if
(PG(http_globals)[TRACK_VARS_SERVER]) {
./work/php-5.3.6/main/php_variables.c:
zval_ptr_dtor(&PG(http_globals)[TRACK_VARS_SERVER]);
./work/php-5.3.6/main/php_variables.c:
PG(http_globals)[TRACK_VARS_SERVER] = array_ptr;
./work/php-5.3.6/main/php_variables.c:
php_autoglobal_merge(&EG(symbol_table),
Z_ARRVAL_P(PG(http_globals)[TRACK_VARS_SERVER]) TSRMLS_CC);
./work/php-5.3.6/main/php_variables.c:
php_build_argv(SG(request_info).query_string,
PG(http_globals)[TRACK_VARS_SERVER] TSRMLS_CC);
./work/php-5.3.6/main/php_variables.c:
zend_hash_update(Z_ARRVAL_P(PG(http_globals)[TRACK_VARS_SERVER]),
"argv", sizeof("argv"), argv, sizeof(zval *), NULL);
./work/php-5.3.6/main/php_variables.c:
zend_hash_update(Z_ARRVAL_P(PG(http_globals)[TRACK_VARS_SERVER]),
"argc", sizeof("argc"), argc, sizeof(zval *), NULL);
./work/php-5.3.6/main/php_variables.c:
php_build_argv(SG(request_info).query_string,
PG(http_globals)[TR
Bug #54729 [Opn->Bgs]: mail is not sent when the body contains a specific web-link
Edit report at http://bugs.php.net/bug.php?id=54729&edit=1 ID: 54729 Updated by: fel...@php.net Reported by:peter dot ihrler at ku-eichstaett dot de Summary:mail is not sent when the body contains a specific web-link -Status: Open +Status: Bogus Type: Bug Package:Scripting Engine problem Operating System: sles11, opensuse PHP Version:5.2.17 Block user comment: N Private report: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2011-05-18 09:59:31] peter dot ihrler at ku-eichstaett dot de I am sorry for this. My emails didn't pass our anti-spam-filter. That is why they never where received. The links like "http://www.ku-ett.de.ms"; are interpreted as phishing-links. Peter [2011-05-13 16:07:21] peter dot ihrler at ku-eichstaett dot de Description: mail() does not send an email when the body contains a specific web-link. This happens also with 5.3.3. It seems that mail() does interpret the Link and doesn't send an e-mail if after the ".de" is something appended. Test script: --- http://www.ku-ett.de";); mail( "to...@ku-ett.de", "Bad Link", "http://www.ku-ett.de.ms";); ?> -- Edit this bug report at http://bugs.php.net/bug.php?id=54729&edit=1
[PHP-BUG] Bug #55038 [NEW]: inconsistent error-handling for $this
From: Operating system: Win7 PHP version: 5.3.6 Package: Class/Object related Bug Type: Bug Bug description:inconsistent error-handling for $this Description: $this is not generally allowed outside an object context, but sometimes it is. I discovered this while trying to write a cheeky little base-class that would allow you to decorate objects with new methods, at run-time. I would have gotten away with it, too - and I still could of course, only I would have to break from the convention of $this, and naming the context-object something else, which kind of sucks. Test script: --- bar); // this will blow up }; $ouch($test); Expected result: The two examples should either fail consistently, or succeed consistently. >From my point of view, why should I not be allowed to have a local variable named $this if I wanted to? There's nothing special or magical about this variable, besides the fact that it gets automatically assigned on call. Actual result: -- The second example fails. -- Edit bug report at http://bugs.php.net/bug.php?id=55038&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=55038&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=55038&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=55038&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=55038&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=55038&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=55038&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=55038&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=55038&r=needscript Try newer version: http://bugs.php.net/fix.php?id=55038&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=55038&r=support Expected behavior: http://bugs.php.net/fix.php?id=55038&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=55038&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=55038&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=55038&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=55038&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=55038&r=dst IIS Stability: http://bugs.php.net/fix.php?id=55038&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=55038&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=55038&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=55038&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=55038&r=mysqlcfg
Bug #52404 [Com]: All TTF Files are invalid [ALL PHP.NET]
Edit report at http://bugs.php.net/bug.php?id=52404&edit=1 ID: 52404 Comment by: gozmeu at gmail dot com Reported by:h...@php.net Summary:All TTF Files are invalid [ALL PHP.NET] Status: Open Type: Bug Package:*General Issues PHP Version:Irrelevant Block user comment: N Private report: N New Comment: same here Warning: imagettftext() [function.imagettftext]: Could not find/open font in /home/gozmeu/domains/pwiguilds.com/public_html/travelcounter.php on line 40 â°PNG IHDRP Ã-q" PLTEÿÿÿÿÿÿsxÂ¥c IDAT(âcpñ,»ÃQ3GÃÃk&]7> 7¡ËFIEND®B`â with a valid or invalid ttf file :s Previous Comments: [2010-12-07 12:51:33] h...@php.net This is not a difficult bug to fix. Anybody with commit access should be able to fix it. Can somebody fix it? Thanks. [2010-10-18 18:30:24] h...@php.net I would if I could. I don't think I have commit access to all of the ttf files on the php.net svn. [2010-07-27 01:54:48] ras...@php.net You may just have to re-import them into Subversion or something. All I did was flip the svn property so Subversion wouldn't mangle them. [2010-07-27 01:02:53] ka...@php.net Confirmed on Windows XP aswell (unreadable font files in the font viewer) Rasmus: You did this change, should it be reverted or do you have any easy fix on your mind? [2010-07-22 15:13:56] h...@php.net Description: All of the TTF files that are on PHP.net appear to be invalid/corrupt. A change that happened 12 months ago with the description of "Fix TTF files" appears to be where the problem lies. http://svn.php.net/viewvc?view=revision&revision=284292 To fix this, this revision should be reverted to all files. On Windows, when you try to open any of these files it will say "The requested file *.ttf was not a valid font file". Here at PHP, we get a different message when using the imagettfbbox() function... "Could not read font". In the example below I am using the arial.ttf file which can be downloaded here: http://svn.php.net/viewvc/web/php/trunk/bin/arial.ttf?view=co Test script: --- Does font '$font' exist? ".$read; $read = is_readable($font)?'Yes':'No'; echo "\nIs font '$font' readable? ".$read; $test = @imagettfbbox(1, 1, $font, 1)?'Yes':'No'; echo "\nIs font '$font' valid? ".$test; echo "\nWhat PHP version? ".phpversion(); ?> Expected result: Does font 'fonts/arial.ttf' exist? Yes Is font 'fonts/arial.ttf' readable? Yes Is font 'fonts/arial.ttf' valid? Yes What PHP version? 5.2.13 Actual result: -- Does font 'fonts/arial.ttf' exist? Yes Is font 'fonts/arial.ttf' readable? Yes Is font 'fonts/arial.ttf' valid? No What PHP version? 5.2.13 -- Edit this bug report at http://bugs.php.net/bug.php?id=52404&edit=1
Bug #55037 [Opn->Fbk]: php_zval_filter_recursive segfault
Edit report at http://bugs.php.net/bug.php?id=55037&edit=1
ID: 55037
Updated by: fel...@php.net
Reported by:crrodriguez at opensuse dot org
Summary:php_zval_filter_recursive segfault
-Status: Open
+Status: Feedback
Type: Bug
Package:Filter related
Operating System: Linux
PHP Version:5.3SVN-2011-06-12 (SVN)
Block user comment: N
Private report: N
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Previous Comments:
[2011-06-12 03:18:48] crrodriguez at opensuse dot org
Description:
Hi:
php_zval_filter_recursive segfaults once in a while, with the following
backtrace
Test script:
---
Program terminated with signal 11, Segmentation fault.
#0 0x7fb81e3a58a2 in php_zval_filter_recursive (value=0x7fb823d86768,
filter=140736822777868, flags=140736822777848, options=0x7fb823d86790,
copy=, charset=0x0)
at /usr/src/debug/php-5.3.6.201106102115/ext/filter/filter.c:524
529 if (Z_TYPE_PP(element) == IS_ARRAY) {
(gdb) bt full
#0 0x7fb81e3a58a2 in php_zval_filter_recursive (value=0x7fb823d86768,
filter=140736822777868, flags=140736822777848, options=0x7fb823d86790,
copy=, charset=0x0)
at /usr/src/debug/php-5.3.6.201106102115/ext/filter/filter.c:524
element = 0x0
pos = 0x7fb823d86790
#1 0x in ?? ()
Im not familiar with the code so Im not sure if checking element != NULL is a
correct fix.,
Expected result:
---
Actual result:
--
--
--
Edit this bug report at http://bugs.php.net/bug.php?id=55037&edit=1
[PHP-BUG] Bug #55037 [NEW]: php_zval_filter_recursive segfault
From:
Operating system: Linux
PHP version: 5.3SVN-2011-06-12 (SVN)
Package: Filter related
Bug Type: Bug
Bug description:php_zval_filter_recursive segfault
Description:
Hi:
php_zval_filter_recursive segfaults once in a while, with the following
backtrace
Test script:
---
Program terminated with signal 11, Segmentation fault.
#0 0x7fb81e3a58a2 in php_zval_filter_recursive (value=0x7fb823d86768,
filter=140736822777868, flags=140736822777848, options=0x7fb823d86790,
copy=, charset=0x0)
at /usr/src/debug/php-5.3.6.201106102115/ext/filter/filter.c:524
529 if (Z_TYPE_PP(element) == IS_ARRAY) {
(gdb) bt full
#0 0x7fb81e3a58a2 in php_zval_filter_recursive (value=0x7fb823d86768,
filter=140736822777868, flags=140736822777848, options=0x7fb823d86790,
copy=, charset=0x0)
at /usr/src/debug/php-5.3.6.201106102115/ext/filter/filter.c:524
element = 0x0
pos = 0x7fb823d86790
#1 0x in ?? ()
Im not familiar with the code so Im not sure if checking element != NULL is
a correct fix.,
Expected result:
---
Actual result:
--
--
--
Edit bug report at http://bugs.php.net/bug.php?id=55037&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=55037&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=55037&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=55037&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=55037&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=55037&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=55037&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=55037&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=55037&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=55037&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=55037&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=55037&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=55037&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=55037&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=55037&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=55037&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=55037&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=55037&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=55037&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=55037&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=55037&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=55037&r=mysqlcfg
Bug #54742 [Opn->Fbk]: ' The memory could not be "read" ' when calling mb_eregi_replace
Edit report at http://bugs.php.net/bug.php?id=54742&edit=1
ID: 54742
Updated by: fel...@php.net
Reported by:reg at argi dot ru
Summary:' The memory could not be "read" ' when calling
mb_eregi_replace
-Status: Open
+Status: Feedback
Type: Bug
Package:Apache2 related
Operating System: Windows 2003
PHP Version:5.2.17
Block user comment: N
Private report: N
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2011-05-16 05:40:32] reg at argi dot ru
Description:
>From time to time in the line / * dead line * /$str = mb_eregi_replace (
>"U\\+([A-F0-9]{4})", "U+\\1", $str); apache error:
Application popup: httpd.exe - Application Error: The instruction at
"0x016657e9" referenced memory at "0x0001" (sometimes 000100 or 02).
The memory could not be "read".
OR The instruction at "0x0165c37a" referenced memory at "0x6f647468". The
memory could not be "read".
If an error occurs at least once, it starts to appear each time you run this
line.
Write a short script that causes this error I could not.
At address 0x016657e9 located php_mbstring.dll (base address 0x0164, file
version 5.2.17.17).
Test script:
---
function smartUtf8to1251($str) {
mb_internal_encoding("utf-8");
mb_substitute_character('long');
/*dead line*/$str = mb_eregi_replace ( "U\\+([A-F0-9]{4})",
"U+\\1", $str);
$str = mb_convert_encoding($str, 'windows-1251', 'utf-8');
$str = preg_replace("~U\+([A-F0-9]{4})~ie", '"&#".hexdec("$1").";"',
$str);
return $str;
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=54742&edit=1
Bug #54744 [Opn->Bgs]: ob_gzhandler does not work
Edit report at http://bugs.php.net/bug.php?id=54744&edit=1 ID: 54744 Updated by: fel...@php.net Reported by:bugzilla33 at gmail dot com Summary:ob_gzhandler does not work -Status: Open +Status: Bogus Type: Bug Package:Output Control Operating System: win32 PHP Version:trunk-SVN-2011-05-16 (snap) Block user comment: N Private report: N New Comment: ob_gzhandler() is not a PHP function anymore (5.4+). So the execution is being aborted by the fatal error. Previous Comments: [2011-05-16 10:26:17] bugzilla33 at gmail dot com Description: ob_gzhandler does not work Test script: --- Expected result: prints 'ok' like PHP 5.3.6 Actual result: -- PHP 5.3.99 prints empty buffer -- Edit this bug report at http://bugs.php.net/bug.php?id=54744&edit=1
Bug #54798 [Opn->Asn]: Segfault when CURLOPT_STDERR file pointer is closed before calling curl_exec
Edit report at http://bugs.php.net/bug.php?id=54798&edit=1
ID: 54798
Updated by: fel...@php.net
Reported by:sh...@php.net
Summary:Segfault when CURLOPT_STDERR file pointer is closed
before calling curl_exec
-Status: Open
+Status: Assigned
Type: Bug
Package:cURL related
Operating System: Ubuntu Linux 11.04 x86
PHP Version:trunk-SVN-2011-05-17 (SVN)
-Assigned To:
+Assigned To:iliaa
Block user comment: N
Private report: N
Previous Comments:
[2011-05-17 16:25:32] sh...@php.net
Description:
Related to http://bugs.php.net/bug.php?id=48203
Curl crashes when CURLOPT_STDERR file pointer is closed before calling
curl_exec(), i.e.
$fp = fopen(dirname(__FILE__) . '/bug48203.tmp', 'w');
$ch = curl_init();
curl_setopt($ch, CURLOPT_VERBOSE, 1);
curl_setopt($ch, CURLOPT_STDERR, $fp);
curl_setopt($ch, CURLOPT_URL, getenv("PHP_CURL_HTTP_REMOTE_SERVER"));
fclose($fp); // <-- premature close of $fp caused a crash!
curl_exec($ch); // segfault
Error is reproduced on latest svn php5.3, php5.4 and trunk
Fix is also attached here.
Test script:
---
Full test script is available here:
http://svn.php.net/viewvc/php/php-src/trunk/ext/curl/tests/bug48203.phpt?view=markup
Expected result:
No segfault, see test script
Actual result:
--
Segfault
--
Edit this bug report at http://bugs.php.net/bug.php?id=54798&edit=1
Bug #54851 [Opn->Asn]: DateTime::createFromFormat, $format=='D' or $format=='l' Always Returns Today.
Edit report at http://bugs.php.net/bug.php?id=54851&edit=1
ID: 54851
Updated by: fel...@php.net
Reported by:phpbugs at nicholassloan dot com
Summary:DateTime::createFromFormat, $format=='D' or
$format=='l' Always Returns Today.
-Status: Open
+Status: Assigned
Type: Bug
Package:Date/time related
Operating System: Mac OS X
PHP Version:trunk-SVN-2011-05-18 (SVN)
-Assigned To:
+Assigned To:derick
Block user comment: N
Private report: N
Previous Comments:
[2011-05-19 15:00:59] mats dot lindh at gmail dot com
The issue seems to be that there is currently no parsing done for the D/l
parameters. I've added a patch and a test that seems to fix the issue.
[2011-05-19 00:51:31] phpbugs at nicholassloan dot com
Description:
If the format only includes a day string ('D' or 'l'), it is ignored, and a
DateTime instance for the current date/time is returned. Maybe I'm a stupid
idiot,
but I would expect either an error, or for it to return a DateTime object for
the
next occurrence of the given day (similar to \DateTime::__construct('Monday');)
Test script:
---
format('D'));
var_dump($date);
var_dump($date->format('D'));
var_dump($date2);
var_dump($date2->format('D'));
Expected result:
I expect the same date/day to be selected in both cases.
Actual result:
--
object(DateTime)#1 (3) {
["date"]=>
string(19) "2011-05-19 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/New_York"
}
string(3) "Thu"
object(DateTime)#2 (3) {
["date"]=>
string(19) "2011-05-18 18:49:33"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/New_York"
}
string(3) "Wed"
--
Edit this bug report at http://bugs.php.net/bug.php?id=54851&edit=1
Bug #50887 [Com]: preg_match , last optional sub-patterns ignored when empy
Edit report at http://bugs.php.net/bug.php?id=50887&edit=1
ID: 50887
Comment by: cappuccino dot e dot cornetto at gmail dot com
Reported by:hapo at gmail dot com
Summary:preg_match , last optional sub-patterns ignored when
empy
Status: Wont fix
Type: Bug
Package:PCRE related
Operating System: Windows
PHP Version:5.3.1
Block user comment: N
Private report: N
New Comment:
I cannot imagine how fixing it would break anything older.
If I expect 3 submatches from my pattern, but I get 2, then I know (for the
bug)
that the missing submatch is the last one and itâs an empty string. So I add
it
myself to the submatches array. Would a programmer do anything different to fix
this
bug?
If the bug is fixed, it means that my old code will always get 3 submatches
from
that pattern. So my own fix wonât get triggered, and having the last submatch
the
same value (empty string) as the one my fix would have added, I wonât have
any
issue, except a bit of (stale) unused code.
Previous Comments:
[2010-01-31 11:57:09] nlop...@php.net
I don't think we can change that behaviour at this point for the sake of not
brekaing BC.
[2010-01-30 16:58:58] hapo at gmail dot com
Description:
in preg_match , when optional sub-patterns (using ? or {0,n} ) are the last
sub-patterns and empty (e.g. not matched) they are ignored in $matches array
this behavior is inconsistent with preg_match_all , and with the case when the
empty optional sub-pattern isn't the last one
Reproduce code:
---
$str="1";
preg_match("#\d(\d)?#",$str,$mt);
var_dump($mt);
Expected result:
array(2) {
[0]=>
string(1) "1"
[1]=>
string(0) ""
}
(the string(0) "" does appear on all cases with preg_match_all , and with
preg_match , when there is any additional sub-patterns after it)
Actual result:
--
array(1) {
[0]=>
string(1) "1"
}
(the value of sub-pattern vanished)
--
Edit this bug report at http://bugs.php.net/bug.php?id=50887&edit=1
Bug #48831 [Asn->Csd]: php -i has different output to php --ini
Edit report at http://bugs.php.net/bug.php?id=48831&edit=1
ID: 48831
Updated by: fel...@php.net
Reported by:RQuadling at GMail dot com
Summary:php -i has different output to php --ini
-Status: Assigned
+Status: Closed
Type: Bug
Package:CGI related
Operating System: *
PHP Version:5.*
Assigned To:pajoye
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/.
Thank you for the report, and for helping us make PHP better.
Yeah, I noticed that was comparing the wrong lines, thanks.
Previous Comments:
[2011-06-12 01:46:36] fel...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revision&revision=312072
Log: - Fix missing change from r303357 (related to bug #48831)
[2011-06-12 01:43:52] rquadl...@php.net
Please look at the patch : http://bugs.php.net/patch-display.php?
bug_id=48831&patch=ScanIniDir&revision=latest
The line to be removed is ...
zend_printf("Scan for additional .ini files in: %s\n",
*PHP_CONFIG_FILE_SCAN_DIR
? PHP_CONFIG_FILE_SCAN_DIR : "(none)");
and should be replaced with ...
zend_printf("Scan for additional .ini files in: %s\n", php_ini_scanned_path ?
php_ini_scanned_path : "(none)");
As you've shown in lxr, this has not happened in PHP_5_3
OOI, I've never actually built trunk, only PHP_5_3 (and soon to be using 5.4
also, just as soon as I work out a way to build both on 1 setup AND support
testing of them AND having an official build as standard).
What I mean by that is that I only ever tested my patch on 5.3. I was quite new
to building things and didn't touch trunk.
Thanks for coming back and looking.
[2011-06-12 01:27:14] fel...@php.net
Oh sorry, I was comparing rev 303357. :)
[2011-06-12 01:24:22] paj...@php.net
http://lxr.php.net/opengrok/xref/PHP_5_3/sapi/cli/php_cli.c#1365
and
http://lxr.php.net/opengrok/xref/PHP_TRUNK/sapi/cli/php_cli.c#1314
The patch has been applied as it was afaict. Or what are you referring to?
[2011-06-11 04:01:50] fel...@php.net
The changes in 5_3 were different from 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
http://bugs.php.net/bug.php?id=48831
--
Edit this bug report at http://bugs.php.net/bug.php?id=48831&edit=1
Bug #48831 [Asn]: php -i has different output to php --ini
Edit report at http://bugs.php.net/bug.php?id=48831&edit=1
ID: 48831
Updated by: rquadl...@php.net
Reported by:RQuadling at GMail dot com
Summary:php -i has different output to php --ini
Status: Assigned
Type: Bug
Package:CGI related
Operating System: *
PHP Version:5.*
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
Please look at the patch : http://bugs.php.net/patch-display.php?
bug_id=48831&patch=ScanIniDir&revision=latest
The line to be removed is ...
zend_printf("Scan for additional .ini files in: %s\n",
*PHP_CONFIG_FILE_SCAN_DIR
? PHP_CONFIG_FILE_SCAN_DIR : "(none)");
and should be replaced with ...
zend_printf("Scan for additional .ini files in: %s\n", php_ini_scanned_path ?
php_ini_scanned_path : "(none)");
As you've shown in lxr, this has not happened in PHP_5_3
OOI, I've never actually built trunk, only PHP_5_3 (and soon to be using 5.4
also, just as soon as I work out a way to build both on 1 setup AND support
testing of them AND having an official build as standard).
What I mean by that is that I only ever tested my patch on 5.3. I was quite new
to building things and didn't touch trunk.
Thanks for coming back and looking.
Previous Comments:
[2011-06-12 01:27:14] fel...@php.net
Oh sorry, I was comparing rev 303357. :)
[2011-06-12 01:24:22] paj...@php.net
http://lxr.php.net/opengrok/xref/PHP_5_3/sapi/cli/php_cli.c#1365
and
http://lxr.php.net/opengrok/xref/PHP_TRUNK/sapi/cli/php_cli.c#1314
The patch has been applied as it was afaict. Or what are you referring to?
[2011-06-11 04:01:50] fel...@php.net
The changes in 5_3 were different from trunk.
[2011-06-09 00:05:43] rquadl...@php.net
The bug is still in effect. The changes made don't actually effect the output.
The
commit made only added a single extern and did not amend the code to display
the
php ini scan dir.
The supplied patch covered all the bases.
[2010-09-14 12:36:28] paj...@php.net
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/.
Thank you for the report, and for helping us make PHP better.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=48831
--
Edit this bug report at http://bugs.php.net/bug.php?id=48831&edit=1
Bug #48831 [Asn]: php -i has different output to php --ini
Edit report at http://bugs.php.net/bug.php?id=48831&edit=1 ID: 48831 Updated by: fel...@php.net Reported by:RQuadling at GMail dot com Summary:php -i has different output to php --ini Status: Assigned Type: Bug Package:CGI related Operating System: * PHP Version:5.* Assigned To:pajoye Block user comment: N Private report: N New Comment: Oh sorry, I was comparing rev 303357. :) Previous Comments: [2011-06-12 01:24:22] paj...@php.net http://lxr.php.net/opengrok/xref/PHP_5_3/sapi/cli/php_cli.c#1365 and http://lxr.php.net/opengrok/xref/PHP_TRUNK/sapi/cli/php_cli.c#1314 The patch has been applied as it was afaict. Or what are you referring to? [2011-06-11 04:01:50] fel...@php.net The changes in 5_3 were different from trunk. [2011-06-09 00:05:43] rquadl...@php.net The bug is still in effect. The changes made don't actually effect the output. The commit made only added a single extern and did not amend the code to display the php ini scan dir. The supplied patch covered all the bases. [2010-09-14 12:36:28] paj...@php.net 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/. Thank you for the report, and for helping us make PHP better. [2010-09-14 12:36:23] paj...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=303357 Log: - fix #48831 php -i has different output to php --ini The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=48831 -- Edit this bug report at http://bugs.php.net/bug.php?id=48831&edit=1
Bug #48831 [Asn]: php -i has different output to php --ini
Edit report at http://bugs.php.net/bug.php?id=48831&edit=1 ID: 48831 Updated by: paj...@php.net Reported by:RQuadling at GMail dot com Summary:php -i has different output to php --ini Status: Assigned Type: Bug Package:CGI related Operating System: * PHP Version:5.* Assigned To:pajoye Block user comment: N Private report: N New Comment: http://lxr.php.net/opengrok/xref/PHP_5_3/sapi/cli/php_cli.c#1365 and http://lxr.php.net/opengrok/xref/PHP_TRUNK/sapi/cli/php_cli.c#1314 The patch has been applied as it was afaict. Or what are you referring to? Previous Comments: [2011-06-11 04:01:50] fel...@php.net The changes in 5_3 were different from trunk. [2011-06-09 00:05:43] rquadl...@php.net The bug is still in effect. The changes made don't actually effect the output. The commit made only added a single extern and did not amend the code to display the php ini scan dir. The supplied patch covered all the bases. [2010-09-14 12:36:28] paj...@php.net 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/. Thank you for the report, and for helping us make PHP better. [2010-09-14 12:36:23] paj...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=303357 Log: - fix #48831 php -i has different output to php --ini [2010-04-12 17:23:30] rquadl...@php.net The following patch has been added/updated: Patch Name: ScanIniDir Revision: 1271085810 URL: http://bugs.php.net/patch-display.php?bug=48831&patch=ScanIniDir&revision=1271085810 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=48831 -- Edit this bug report at http://bugs.php.net/bug.php?id=48831&edit=1
Bug #54984 [Opn->Wfx]: ArrayObject creates invalid variable reference
Edit report at http://bugs.php.net/bug.php?id=54984&edit=1
ID: 54984
Updated by: fel...@php.net
Reported by:pwharman at gmail dot com
Summary:ArrayObject creates invalid variable reference
-Status: Open
+Status: Wont fix
Type: Bug
Package:SPL related
Operating System: Windows/Linux
PHP Version:5.2.17
Block user comment: N
Private report: N
New Comment:
Since 5.2.x is not a maintained version, consider using 5.3. :)
Previous Comments:
[2011-06-04 13:50:16] pwharman at gmail dot com
I agree it makes no sense!
I have just retested using PHP 5.3.6 and can not reproduce this, it seems
limited to 5.2.x. I have just ran the script against 5.2.17 and can confirm the
problem exists.
[2011-06-04 01:25:07] fel...@php.net
This makes no sense, Are you reproducing it just with this posted test script?!
[2011-06-03 12:49:42] pwharman at gmail dot com
Description:
If ArrayAccess is extended and then the subclass accessed using object notation
then unpredicatable results occur. In the test script below an undefined
variable $xyz is somehow referencing the ArrayObject subclass Foo.
The same result occurs on Linux systems.
This came to light when using an unitialised value in the Zend Framework
Zend_Registry class, although it is not limited to that.
Test script:
---
Foo['bar'] = 1;
var_dump($xyz['xyz']); # This should throw a warning then null??
?>
Expected result:
PHP Notice: Undefined index: Foo in C:\jirasource\ABC\sites\partners.rfp-gener
ator.com\web\test.html.php on line 8
PHP Stack trace:
PHP 1. {main}() C:\jirasource\ABC\sites\partners.rfp-generator.com\web\test.ht
ml.php:0
Notice: Undefined index: Foo in C:\jirasource\ABC\sites\partners.rfp-generator.
com\web\test.html.php on line 8
Call Stack:
0.0212 60112 1. {main}() C:\jirasource\ABC\sites\partners.rfp-generat
or.com\web\test.html.php:0
PHP Notice: Undefined variable: xyz in C:\jirasource\ABC\sites\partners.rfp-gen
erator.com\web\test.html.php on line 9
PHP Stack trace:
PHP 1. {main}() C:\jirasource\ABC\sites\partners.rfp-generator.com\web\test.ht
ml.php:0
Notice: Undefined variable: xyz in C:\jirasource\ABC\sites\partners.rfp-generato
r.com\web\test.html.php on line 9
Call Stack:
0.0212 60112 1. {main}() C:\jirasource\ABC\sites\partners.rfp-generat
or.com\web\test.html.php:0
PHP Notice: Undefined index: xyz in C:\jirasource\ABC\sites\partners.rfp-gener
ator.com\web\test.html.php on line 9
PHP Stack trace:
PHP 1. {main}() C:\jirasource\ABC\sites\partners.rfp-generator.com\web\test.ht
ml.php:0
Notice: Undefined index: xyz in C:\jirasource\ABC\sites\partners.rfp-generator.
com\web\test.html.php on line 9
Call Stack:
0.0212 60112 1. {main}() C:\jirasource\ABC\sites\partners.rfp-generat
or.com\web\test.html.php:0
null
Actual result:
--
PHP Notice: Undefined index: Foo in C:\jirasource\ABC\sites\partners.rfp-gener
ator.com\web\test.html.php on line 8
PHP Stack trace:
PHP 1. {main}() C:\jirasource\ABC\sites\partners.rfp-generator.com\web\test.ht
ml.php:0
Notice: Undefined index: Foo in C:\jirasource\ABC\sites\partners.rfp-generator.
com\web\test.html.php on line 8
Call Stack:
0.0212 60112 1. {main}() C:\jirasource\ABC\sites\partners.rfp-generat
or.com\web\test.html.php:0
PHP Notice: Undefined variable: xyz in C:\jirasource\ABC\sites\partners.rfp-gen
erator.com\web\test.html.php on line 9
PHP Stack trace:
PHP 1. {main}() C:\jirasource\ABC\sites\partners.rfp-generator.com\web\test.ht
ml.php:0
Notice: Undefined variable: xyz in C:\jirasource\ABC\sites\partners.rfp-generato
r.com\web\test.html.php on line 9
Call Stack:
0.0212 60112 1. {main}() C:\jirasource\ABC\sites\partners.rfp-generat
or.com\web\test.html.php:0
PHP Notice: Undefined index: xyz in C:\jirasource\ABC\sites\partners.rfp-gener
ator.com\web\test.html.php on line 9
PHP Stack trace:
PHP 1. {main}() C:\jirasource\ABC\sites\partners.rfp-generator.com\web\test.ht
ml.php:0
Notice: Undefined index: xyz in C:\jirasource\ABC\sites\partners.rfp-generator.
com\web\test.html.php on line 9
Call Stack:
0.0212 60112 1. {main}() C:\jirasource\ABC\sites\partners.rfp-generat
or.com\web\test.html.php:0
array(1) {
["bar"]=>
int(1)
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=54984&edit=1
Bug #48203 [ReO->Asn]: crash when CURLOPT_STDERR is set to regular file
Edit report at http://bugs.php.net/bug.php?id=48203&edit=1 ID: 48203 Updated by: fel...@php.net Reported by:php-bug at paulsohier dot nl Summary:crash when CURLOPT_STDERR is set to regular file -Status: Re-Opened +Status: Assigned Type: Bug Package:cURL related Operating System: * PHP Version:5.*, 6CVS (2009-05-09) -Assigned To:jani +Assigned To:iliaa Block user comment: N Private report: N Previous Comments: [2011-06-09 09:31:15] sh...@php.net The following patch has been added/updated: Patch Name: reset_to_default_with_multi.patch.txt Revision: 1307604675 URL: http://bugs.php.net/patch-display.php?bug=48203&patch=reset_to_default_with_multi.patch.txt&revision=1307604675 [2011-06-09 09:30:05] sh...@php.net Added patch for updated tests (tests were commited here http://news.php.net/php.cvs/65161). See also discussion here: http://markmail.org/message/dfjgty27qfhj4ulf [2011-06-09 09:16:16] sh...@php.net Automatic comment from SVN on behalf of shein Revision: http://svn.php.net/viewvc/?view=revision&revision=311959 Log: Updated (currently failing) test for bug48203 with curl_stderr and added also curl_multi_exec variant of this test. [2009-05-26 17:16:53] j...@php.net This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2009-05-26 12:34:48] j...@php.net This fixes all the test cases I could come up with: http://pecl.php.net/~jani/patches/bug48203.patch Even the quite insane ones too. It falls back to using STDERR which is the default anyway if the file pointer is closed prematurely. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=48203 -- Edit this bug report at http://bugs.php.net/bug.php?id=48203&edit=1
Bug #54462 [Opn->Bgs]: 'echo $e->getTrace()' hangs
Edit report at http://bugs.php.net/bug.php?id=54462&edit=1
ID: 54462
Updated by: fel...@php.net
Reported by:softwarevamp at gmail dot com
Summary:'echo $e->getTrace()' hangs
-Status: Open
+Status: Bogus
Type: Bug
Package:Output Control
Operating System: Window Xp Japanese
PHP Version:5.2.17
Block user comment: N
Private report: N
New Comment:
Only with ZendDebugger? So not an issue in PHP itself.
Previous Comments:
[2011-06-10 03:53:30] softwarevamp at gmail dot com
seems this only occurs in debug mode.
i am using ZendDebugger.dll 5.2.x
[2011-06-10 03:38:17] d...@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.
cannot reproduce it. please provide a stack trace where it's hanging.
[2011-04-04 04:06:43] softwarevamp at gmail dot com
Description:
try to print out exception stacktrace, php hangs.
Test script:
---
try {
throw new ErrorException("test");
} catch(Exception $e) {
echo $e; //hangs here
}
i am using WINDOWS XP JAPANESE
Expected result:
print out the stack trace
Actual result:
--
hangs
--
Edit this bug report at http://bugs.php.net/bug.php?id=54462&edit=1
Req #55036 [Opn]: Have crypt() throw E_WARNING when salt parameter missing
Edit report at http://bugs.php.net/bug.php?id=55036&edit=1
ID: 55036
User updated by:ss23 at ss23 dot geek dot nz
Reported by:ss23 at ss23 dot geek dot nz
Summary:Have crypt() throw E_WARNING when salt parameter
missing
Status: Open
Type: Feature/Change Request
Package:*Encryption and hash functions
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Another possible way to "fix" the security risk here would be to choose a sane
hash as a default. Now that they're built in, it shouldn't be a problem to do
this.
Previous Comments:
[2011-06-11 21:00:55] ss23 at ss23 dot geek dot nz
Description:
Currently, you can call crypt('foo') without any problems, however, given how
useless that is for anything, it's a security risk if someone was actually to
do
this.
Test script:
---
http://bugs.php.net/bug.php?id=55036&edit=1
Bug #55033 [Bgs]: Memory Leak in magic method __get() [Zend Memory Manager]
Edit report at http://bugs.php.net/bug.php?id=55033&edit=1 ID: 55033 Updated by: fel...@php.net Reported by:rodney dot rehm at medialize dot de Summary:Memory Leak in magic method __get() [Zend Memory Manager] Status: Bogus Type: Bug Package:Performance problem Operating System: Mac OS X 10.6.7 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Hi, this behavior is some needs to be changed, I'm not ignoring your point, just closed the report since it has been already reported. Thanks. Previous Comments: [2011-06-11 21:45:56] rodney dot rehm at medialize dot de Well, I figure since Bug #48197 is still open, the issue will be resolved eventually. If you're facing memory problems because of __get() you might want to sporadically clone the object: $object = clone $object; The wasted memory is not cloned. Beware that you are trading memory for runtime. Only consider this if you are facing memory issues or runtime is not an issue. [2011-06-11 17:42:22] rodney dot rehm at medialize dot de Just to get this straight. This is not a bug, it's expected behavior. Anything returned from a magic method is internally handled as a copy. That means that anything a magic methods returns, even if it's a reference to another object, is kept in memory. That is, until the $object the magic methods were invoked on, is unset(). Are you kidding me? Not a bug? Where is this not a bug? A note on this topic wouldn't harm the docs, you know? [2011-06-11 17:02:32] fel...@php.net A copy of returned variable is done. [2011-06-11 17:01:14] rodney dot rehm at medialize dot de What exactly do you mean by "separating return from __get()"? The memory is pumped regardless of how I return (value, reference). How am I supposed to "separate" here? [2011-06-11 16:48:14] fel...@php.net There is no memleak, what happens is that the return from __get() needs to be separated. See bug #48197 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=55033 -- Edit this bug report at http://bugs.php.net/bug.php?id=55033&edit=1
Bug #55033 [Com]: Memory Leak in magic method __get() [Zend Memory Manager]
Edit report at http://bugs.php.net/bug.php?id=55033&edit=1
ID: 55033
Comment by: rodney dot rehm at medialize dot de
Reported by:rodney dot rehm at medialize dot de
Summary:Memory Leak in magic method __get() [Zend Memory
Manager]
Status: Bogus
Type: Bug
Package:Performance problem
Operating System: Mac OS X 10.6.7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Well, I figure since Bug #48197 is still open, the issue will be resolved
eventually.
If you're facing memory problems because of __get() you might want to
sporadically clone the object: $object = clone $object; The wasted memory is
not cloned. Beware that you are trading memory for runtime. Only consider this
if you are facing memory issues or runtime is not an issue.
Previous Comments:
[2011-06-11 17:42:22] rodney dot rehm at medialize dot de
Just to get this straight. This is not a bug, it's expected behavior.
Anything returned from a magic method is internally handled as a copy. That
means that anything a magic methods returns, even if it's a reference to
another object, is kept in memory. That is, until the $object the magic methods
were invoked on, is unset().
Are you kidding me? Not a bug? Where is this not a bug?
A note on this topic wouldn't harm the docs, you know?
[2011-06-11 17:02:32] fel...@php.net
A copy of returned variable is done.
[2011-06-11 17:01:14] rodney dot rehm at medialize dot de
What exactly do you mean by "separating return from __get()"? The memory is
pumped regardless of how I return (value, reference). How am I supposed to
"separate" here?
[2011-06-11 16:48:14] fel...@php.net
There is no memleak, what happens is that the return from __get() needs to be
separated.
See bug #48197
[2011-06-11 14:40:52] rodney dot rehm at medialize dot de
Description:
For some reason values returned by __get() aren't released from memory.
$ php memory.php # (without --debug)
0.0096 seconds and 1.3461 MB for 1 accessing known property
$ php memory.php # (with --debug)
0.0317 seconds and 2.6435 MB for 1 accessing known property
$ export USE_ZEND_ALLOC=0
$ php memory.php # (with --debug)
0.0267 seconds and 0. MB for 1 accessing known property
since disabling Zend Memory Manager solved the issue, the valgrind log is
pretty much useless, thus not attached.
Test script:
---
{'bar' . $i};
}
$_mem = memory_get_usage();
$_start = microtime(true);
printf("%0.4f seconds and %0.4f MB for %d accessing known property\n", $_start
- $start, ($_mem - $mem) / 1024 / 1024, $iterations);
?>
Expected result:
0.0099 seconds and 0. MB for 1 accessing known property
Actual result:
--
0.0099 seconds and 1.3460 MB for 1 accessing known property
--
Edit this bug report at http://bugs.php.net/bug.php?id=55033&edit=1
[PHP-BUG] Req #55036 [NEW]: Have crypt() throw E_WARNING when salt parameter missing
From:
Operating system:
PHP version: Irrelevant
Package: *Encryption and hash functions
Bug Type: Feature/Change Request
Bug description:Have crypt() throw E_WARNING when salt parameter missing
Description:
Currently, you can call crypt('foo') without any problems, however, given
how
useless that is for anything, it's a security risk if someone was actually
to do
this.
Test script:
---
http://bugs.php.net/bug.php?id=55036&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=55036&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=55036&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=55036&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=55036&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=55036&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=55036&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=55036&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=55036&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=55036&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=55036&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=55036&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=55036&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=55036&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=55036&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=55036&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=55036&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=55036&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=55036&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=55036&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=55036&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=55036&r=mysqlcfg
Bug #55009 [Fbk]: Error when compile
Edit report at http://bugs.php.net/bug.php?id=55009&edit=1 ID: 55009 Updated by: fel...@php.net Reported by:hexes at mail dot ru Summary:Error when compile Status: Feedback Type: Bug Package:Sybase-ct (ctlib) related Operating System: Linux 2.6.36-gentoo-r5 PHP Version:5.3.6 Assigned To:thekid Block user comment: N Private report: N New Comment: But using INCDIR on: elif test -f $SYBASE_CT_INCDIR/libsybct.so; then seems wrong. Previous Comments: [2011-06-11 20:25:27] the...@php.net This is the error as far as I see: /opt/sybase/OCS-15_0/include/ctpublic.h:269: error: expected declaration specifiers or â...â before âSQLDAâ It doesn't look like this has anything to do with PHP. [2011-06-09 10:11:19] hexes at mail dot ru /var/tmp/portage/dev-lang/php-5.3.6/work/sapis- build/cli/ext/sybase_ct/php_sybase_ct.c:391: warning: format â%dâ expects type âintâ, but argument 5 has type âlong intâ just change %d to %ld. [2011-06-08 08:33:34] hexes at mail dot ru Description: In file included from /var/tmp/portage/dev-lang/php-5.3.6/work/sapis- build/cli/ext/sybase_ct/php_sybase_ct.h:63, from /var/tmp/portage/dev-lang/php-5.3.6/work/sapis- build/cli/ext/sybase_ct/php_sybase_ct.c:30: /opt/sybase/OCS-15_0/include/ctpublic.h:269: error: expected declaration specifiers or â...â before âSQLDAâ /var/tmp/portage/dev-lang/php-5.3.6/work/sapis- build/cli/ext/sybase_ct/php_sybase_ct.c: In function â_client_message_handlerâ: /var/tmp/portage/dev-lang/php-5.3.6/work/sapis- build/cli/ext/sybase_ct/php_sybase_ct.c:391: warning: format â%dâ expects type âintâ, but argument 5 has type âlong intâ make: *** [ext/sybase_ct/php_sybase_ct.lo] Error 1 make: *** Waiting for unfinished jobs emake failed I think that error can be in config.m4 (str 60): elif test -f $SYBASE_CT_INCDIR/libsybct.so; then $PHP_SYBASE_CT = '/opt/sybase/OCS-15_0' $SYBASE_CT_INCDIR = $PHP_SYBASE_CT/include But libraries are located in: $SYBASE_CT_LIBDIR=$PHP_SYBASE_CT/lib ls /opt/sybase/OCS-15_0/include/ bkpublic.h cobpub.cbl csconfig.h cspublic.h cstypes.h ctpublic.h mcconfig.h mcpublic.h mctypes.h oscompat.h oserror.h ospublic.h sqlca.h sqlda.h srverror.h srv.h sybdb.h sybdbn.h syberror.h sybesql.c sybfront.h sybhesql.cbl sybhesql.h sybhstmt.h syblogin.h sybtesql.cbl sybtesql.h ls -1 /opt/sybase/OCS-15_0/lib/ libs.a libsmapp.a libsybblk.a libsybblk_r.a libsybblk_r.so libsybblk.so libsybcobct.a libsybcobct_r.a libsybcomn.a libsybcomn_r.a libsybcomn_r.so libsybcomn.so libsybcs.a libsybcs_r.a libsybcs_r.so libsybcs.so libsybct.a libsybct_r.a libsybct_r.so libsybct.so libsybdb.a libsybdb.so libsybdldap.so.15.0.0 libsybdldap.so.15.0.3 libsybfssl.so.15.0.0 libsybfssl.so.15.0.3 libsybintl.a libsybintl_r.a libsybintl_r.so libsybintl.so libsybskrb.so.15.0.0 libsybskrb.so.15.0.3 libsybtcl.a libsybtcl_r.a libsybtcl_r.so libsybtcl.so libsybunic.a libsybunic.so And also, there is no libs: PHP_ADD_LIBRARY(cs,, SYBASE_CT_SHARED_LIBADD) PHP_ADD_LIBRARY(ct,, SYBASE_CT_SHARED_LIBADD) PHP_ADD_LIBRARY(comn,, SYBASE_CT_SHARED_LIBADD) PHP_ADD_LIBRARY(intl,, SYBASE_CT_SHARED_LIBADD) -- Edit this bug report at http://bugs.php.net/bug.php?id=55009&edit=1
Bug #55009 [Asn->Fbk]: Error when compile
Edit report at http://bugs.php.net/bug.php?id=55009&edit=1 ID: 55009 Updated by: the...@php.net Reported by:hexes at mail dot ru Summary:Error when compile -Status: Assigned +Status: Feedback Type: Bug Package:Sybase-ct (ctlib) related Operating System: Linux 2.6.36-gentoo-r5 PHP Version:5.3.6 Assigned To:thekid Block user comment: N Private report: N New Comment: This is the error as far as I see: /opt/sybase/OCS-15_0/include/ctpublic.h:269: error: expected declaration specifiers or â...â before âSQLDAâ It doesn't look like this has anything to do with PHP. Previous Comments: [2011-06-09 10:11:19] hexes at mail dot ru /var/tmp/portage/dev-lang/php-5.3.6/work/sapis- build/cli/ext/sybase_ct/php_sybase_ct.c:391: warning: format â%dâ expects type âintâ, but argument 5 has type âlong intâ just change %d to %ld. [2011-06-08 08:33:34] hexes at mail dot ru Description: In file included from /var/tmp/portage/dev-lang/php-5.3.6/work/sapis- build/cli/ext/sybase_ct/php_sybase_ct.h:63, from /var/tmp/portage/dev-lang/php-5.3.6/work/sapis- build/cli/ext/sybase_ct/php_sybase_ct.c:30: /opt/sybase/OCS-15_0/include/ctpublic.h:269: error: expected declaration specifiers or â...â before âSQLDAâ /var/tmp/portage/dev-lang/php-5.3.6/work/sapis- build/cli/ext/sybase_ct/php_sybase_ct.c: In function â_client_message_handlerâ: /var/tmp/portage/dev-lang/php-5.3.6/work/sapis- build/cli/ext/sybase_ct/php_sybase_ct.c:391: warning: format â%dâ expects type âintâ, but argument 5 has type âlong intâ make: *** [ext/sybase_ct/php_sybase_ct.lo] Error 1 make: *** Waiting for unfinished jobs emake failed I think that error can be in config.m4 (str 60): elif test -f $SYBASE_CT_INCDIR/libsybct.so; then $PHP_SYBASE_CT = '/opt/sybase/OCS-15_0' $SYBASE_CT_INCDIR = $PHP_SYBASE_CT/include But libraries are located in: $SYBASE_CT_LIBDIR=$PHP_SYBASE_CT/lib ls /opt/sybase/OCS-15_0/include/ bkpublic.h cobpub.cbl csconfig.h cspublic.h cstypes.h ctpublic.h mcconfig.h mcpublic.h mctypes.h oscompat.h oserror.h ospublic.h sqlca.h sqlda.h srverror.h srv.h sybdb.h sybdbn.h syberror.h sybesql.c sybfront.h sybhesql.cbl sybhesql.h sybhstmt.h syblogin.h sybtesql.cbl sybtesql.h ls -1 /opt/sybase/OCS-15_0/lib/ libs.a libsmapp.a libsybblk.a libsybblk_r.a libsybblk_r.so libsybblk.so libsybcobct.a libsybcobct_r.a libsybcomn.a libsybcomn_r.a libsybcomn_r.so libsybcomn.so libsybcs.a libsybcs_r.a libsybcs_r.so libsybcs.so libsybct.a libsybct_r.a libsybct_r.so libsybct.so libsybdb.a libsybdb.so libsybdldap.so.15.0.0 libsybdldap.so.15.0.3 libsybfssl.so.15.0.0 libsybfssl.so.15.0.3 libsybintl.a libsybintl_r.a libsybintl_r.so libsybintl.so libsybskrb.so.15.0.0 libsybskrb.so.15.0.3 libsybtcl.a libsybtcl_r.a libsybtcl_r.so libsybtcl.so libsybunic.a libsybunic.so And also, there is no libs: PHP_ADD_LIBRARY(cs,, SYBASE_CT_SHARED_LIBADD) PHP_ADD_LIBRARY(ct,, SYBASE_CT_SHARED_LIBADD) PHP_ADD_LIBRARY(comn,, SYBASE_CT_SHARED_LIBADD) PHP_ADD_LIBRARY(intl,, SYBASE_CT_SHARED_LIBADD) -- Edit this bug report at http://bugs.php.net/bug.php?id=55009&edit=1
Bug #55033 [Com]: Memory Leak in magic method __get() [Zend Memory Manager]
Edit report at http://bugs.php.net/bug.php?id=55033&edit=1
ID: 55033
Comment by: rodney dot rehm at medialize dot de
Reported by:rodney dot rehm at medialize dot de
Summary:Memory Leak in magic method __get() [Zend Memory
Manager]
Status: Bogus
Type: Bug
Package:Performance problem
Operating System: Mac OS X 10.6.7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Just to get this straight. This is not a bug, it's expected behavior.
Anything returned from a magic method is internally handled as a copy. That
means that anything a magic methods returns, even if it's a reference to
another object, is kept in memory. That is, until the $object the magic methods
were invoked on, is unset().
Are you kidding me? Not a bug? Where is this not a bug?
A note on this topic wouldn't harm the docs, you know?
Previous Comments:
[2011-06-11 17:02:32] fel...@php.net
A copy of returned variable is done.
[2011-06-11 17:01:14] rodney dot rehm at medialize dot de
What exactly do you mean by "separating return from __get()"? The memory is
pumped regardless of how I return (value, reference). How am I supposed to
"separate" here?
[2011-06-11 16:48:14] fel...@php.net
There is no memleak, what happens is that the return from __get() needs to be
separated.
See bug #48197
[2011-06-11 14:40:52] rodney dot rehm at medialize dot de
Description:
For some reason values returned by __get() aren't released from memory.
$ php memory.php # (without --debug)
0.0096 seconds and 1.3461 MB for 1 accessing known property
$ php memory.php # (with --debug)
0.0317 seconds and 2.6435 MB for 1 accessing known property
$ export USE_ZEND_ALLOC=0
$ php memory.php # (with --debug)
0.0267 seconds and 0. MB for 1 accessing known property
since disabling Zend Memory Manager solved the issue, the valgrind log is
pretty much useless, thus not attached.
Test script:
---
{'bar' . $i};
}
$_mem = memory_get_usage();
$_start = microtime(true);
printf("%0.4f seconds and %0.4f MB for %d accessing known property\n", $_start
- $start, ($_mem - $mem) / 1024 / 1024, $iterations);
?>
Expected result:
0.0099 seconds and 0. MB for 1 accessing known property
Actual result:
--
0.0099 seconds and 1.3460 MB for 1 accessing known property
--
Edit this bug report at http://bugs.php.net/bug.php?id=55033&edit=1
Bug #55035 [Bgs]: pcre_exec() deadlock causing Segmentation fault (11)
Edit report at http://bugs.php.net/bug.php?id=55035&edit=1 ID: 55035 User updated by:jimmy dot axenhus at gmail dot com Reported by:jimmy dot axenhus at gmail dot com Summary:pcre_exec() deadlock causing Segmentation fault (11) Status: Bogus Type: Bug Package:PCRE related Operating System: Ubuntu 11.04 and Trisquel 4.5 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: That does not solve the problem, still get a segfault :( Previous Comments: [2011-06-11 16:52:20] fel...@php.net Try setting a bigger pcre.backtrack_limit and pcre.recursion_limit. See http://docs.php.net/manual/en/pcre.configuration.php [2011-06-11 15:52:43] jimmy dot axenhus at gmail dot com Description: It appears that PHP can deadlock in pcre_exec(), repeatingly calling a function(itself?). Was converting a vBulletin forum to phpBB, therefore might be hard to reproduce. Despite that I managed to reproduce it on three different computers. I spent several hours debugging this, and will dig deeper into the code that caused this problem to find the specific string causing this. Expect more debug data soon. Test script: --- phpBB 3.0.8, converting from vBulletin 3.8.x, with code attached to http://www.phpbb.com/community/viewtopic.php?f=65&t=1722325#p10391895 You also need a database to convert. Expected result: Normal phpBB progress when converting (php deliving an HTML page) Actual result: -- PHP delivered a blank php script file to the browser and apache logged a segfault (11). After a very long session trying to debug this I finally managed to generate a stacktrace with gdb. The resource below will be accessible as long as this bug is unresolved. http://jimmy.axenhus.com/gdb.txt -- Edit this bug report at http://bugs.php.net/bug.php?id=55035&edit=1
Bug #55033 [Bgs]: Memory Leak in magic method __get() [Zend Memory Manager]
Edit report at http://bugs.php.net/bug.php?id=55033&edit=1
ID: 55033
Updated by: fel...@php.net
Reported by:rodney dot rehm at medialize dot de
Summary:Memory Leak in magic method __get() [Zend Memory
Manager]
Status: Bogus
Type: Bug
Package:Performance problem
Operating System: Mac OS X 10.6.7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
A copy of returned variable is done.
Previous Comments:
[2011-06-11 17:01:14] rodney dot rehm at medialize dot de
What exactly do you mean by "separating return from __get()"? The memory is
pumped regardless of how I return (value, reference). How am I supposed to
"separate" here?
[2011-06-11 16:48:14] fel...@php.net
There is no memleak, what happens is that the return from __get() needs to be
separated.
See bug #48197
[2011-06-11 14:40:52] rodney dot rehm at medialize dot de
Description:
For some reason values returned by __get() aren't released from memory.
$ php memory.php # (without --debug)
0.0096 seconds and 1.3461 MB for 1 accessing known property
$ php memory.php # (with --debug)
0.0317 seconds and 2.6435 MB for 1 accessing known property
$ export USE_ZEND_ALLOC=0
$ php memory.php # (with --debug)
0.0267 seconds and 0. MB for 1 accessing known property
since disabling Zend Memory Manager solved the issue, the valgrind log is
pretty much useless, thus not attached.
Test script:
---
{'bar' . $i};
}
$_mem = memory_get_usage();
$_start = microtime(true);
printf("%0.4f seconds and %0.4f MB for %d accessing known property\n", $_start
- $start, ($_mem - $mem) / 1024 / 1024, $iterations);
?>
Expected result:
0.0099 seconds and 0. MB for 1 accessing known property
Actual result:
--
0.0099 seconds and 1.3460 MB for 1 accessing known property
--
Edit this bug report at http://bugs.php.net/bug.php?id=55033&edit=1
Bug #54985 [Bgs]: round doesn't work with non-14 precision
Edit report at http://bugs.php.net/bug.php?id=54985&edit=1 ID: 54985 User updated by:jille at hexon dot cx Reported by:jille at hexon dot cx Summary:round doesn't work with non-14 precision Status: Bogus Type: Bug Package:*Math Functions Operating System: n/a PHP Version:5.3.6 Assigned To:cataphract Block user comment: N Private report: N New Comment: Or I could just use number_format(). Stupid I didn't think of that earlier. Previous Comments: [2011-06-11 16:48:37] ras...@php.net You can write your own little string rounding wrapper. If you are rounding to 3 decimal places, set your precision accordingly. [2011-06-11 16:09:41] cataphr...@php.net It does give the correct result; it gives the nearest double number to a multiple of 0.01. The problem is you are showing digits beyond the number of digits guaranteed to be correct (i.e. not affected by rounding error). For doubles, with an effective precision of 53 bits, the (possibly non-integer) number of digits to the right of the decimal point that is guaranteed to be correct is given by 53*log10(2) - log10(abs(x)); for x=0.055, this is around 17.21. So for this number you must not set 'precision' beyond 17, otherwise you might see garbage. [2011-06-11 15:20:23] jille at hexon dot cx I disagree with that this behaviour is correct. I think there should be a function which can round() in a reliable way. If it isn't possible with floats I think there should be a function which returns a string. [2011-06-11 04:00:55] cataphr...@php.net This is a bogus report (.055 is not exactly representable, the closest is 7926335344172073*2^-57); r301991 did introduce a bug, but it's completely unrelated. [2011-06-10 20:10:39] cataphr...@php.net Seems to have been introduced by the fix to bug #52550 (r301991). The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=54985 -- Edit this bug report at http://bugs.php.net/bug.php?id=54985&edit=1
Bug #55033 [Com]: Memory Leak in magic method __get() [Zend Memory Manager]
Edit report at http://bugs.php.net/bug.php?id=55033&edit=1
ID: 55033
Comment by: rodney dot rehm at medialize dot de
Reported by:rodney dot rehm at medialize dot de
Summary:Memory Leak in magic method __get() [Zend Memory
Manager]
Status: Bogus
Type: Bug
Package:Performance problem
Operating System: Mac OS X 10.6.7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
What exactly do you mean by "separating return from __get()"? The memory is
pumped regardless of how I return (value, reference). How am I supposed to
"separate" here?
Previous Comments:
[2011-06-11 16:48:14] fel...@php.net
There is no memleak, what happens is that the return from __get() needs to be
separated.
See bug #48197
[2011-06-11 14:40:52] rodney dot rehm at medialize dot de
Description:
For some reason values returned by __get() aren't released from memory.
$ php memory.php # (without --debug)
0.0096 seconds and 1.3461 MB for 1 accessing known property
$ php memory.php # (with --debug)
0.0317 seconds and 2.6435 MB for 1 accessing known property
$ export USE_ZEND_ALLOC=0
$ php memory.php # (with --debug)
0.0267 seconds and 0. MB for 1 accessing known property
since disabling Zend Memory Manager solved the issue, the valgrind log is
pretty much useless, thus not attached.
Test script:
---
{'bar' . $i};
}
$_mem = memory_get_usage();
$_start = microtime(true);
printf("%0.4f seconds and %0.4f MB for %d accessing known property\n", $_start
- $start, ($_mem - $mem) / 1024 / 1024, $iterations);
?>
Expected result:
0.0099 seconds and 0. MB for 1 accessing known property
Actual result:
--
0.0099 seconds and 1.3460 MB for 1 accessing known property
--
Edit this bug report at http://bugs.php.net/bug.php?id=55033&edit=1
Bug #55035 [Opn->Bgs]: pcre_exec() deadlock causing Segmentation fault (11)
Edit report at http://bugs.php.net/bug.php?id=55035&edit=1 ID: 55035 Updated by: fel...@php.net Reported by:jimmy dot axenhus at gmail dot com Summary:pcre_exec() deadlock causing Segmentation fault (11) -Status: Open +Status: Bogus Type: Bug Package:PCRE related Operating System: Ubuntu 11.04 and Trisquel 4.5 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Try setting a bigger pcre.backtrack_limit and pcre.recursion_limit. See http://docs.php.net/manual/en/pcre.configuration.php Previous Comments: [2011-06-11 15:52:43] jimmy dot axenhus at gmail dot com Description: It appears that PHP can deadlock in pcre_exec(), repeatingly calling a function(itself?). Was converting a vBulletin forum to phpBB, therefore might be hard to reproduce. Despite that I managed to reproduce it on three different computers. I spent several hours debugging this, and will dig deeper into the code that caused this problem to find the specific string causing this. Expect more debug data soon. Test script: --- phpBB 3.0.8, converting from vBulletin 3.8.x, with code attached to http://www.phpbb.com/community/viewtopic.php?f=65&t=1722325#p10391895 You also need a database to convert. Expected result: Normal phpBB progress when converting (php deliving an HTML page) Actual result: -- PHP delivered a blank php script file to the browser and apache logged a segfault (11). After a very long session trying to debug this I finally managed to generate a stacktrace with gdb. The resource below will be accessible as long as this bug is unresolved. http://jimmy.axenhus.com/gdb.txt -- Edit this bug report at http://bugs.php.net/bug.php?id=55035&edit=1
Bug #54985 [Bgs]: round doesn't work with non-14 precision
Edit report at http://bugs.php.net/bug.php?id=54985&edit=1
ID: 54985
Updated by: ras...@php.net
Reported by:jille at hexon dot cx
Summary:round doesn't work with non-14 precision
Status: Bogus
Type: Bug
Package:*Math Functions
Operating System: n/a
PHP Version:5.3.6
Assigned To:cataphract
Block user comment: N
Private report: N
New Comment:
You can write your own little string rounding wrapper. If you are rounding to 3
decimal places, set your precision accordingly.
Previous Comments:
[2011-06-11 16:09:41] cataphr...@php.net
It does give the correct result; it gives the nearest double number to a
multiple of 0.01. The problem is you are showing digits beyond the number of
digits guaranteed to be correct (i.e. not affected by rounding error). For
doubles, with an effective precision of 53 bits, the (possibly non-integer)
number of digits to the right of the decimal point that is guaranteed to be
correct is given by 53*log10(2) - log10(abs(x)); for x=0.055, this is around
17.21. So for this number you must not set 'precision' beyond 17, otherwise you
might see garbage.
[2011-06-11 15:20:23] jille at hexon dot cx
I disagree with that this behaviour is correct. I think there should be a
function which can round() in a reliable way. If it isn't possible with floats
I
think there should be a function which returns a string.
[2011-06-11 04:00:55] cataphr...@php.net
This is a bogus report (.055 is not exactly representable, the closest is
7926335344172073*2^-57); r301991 did introduce a bug, but it's completely
unrelated.
[2011-06-10 20:10:39] cataphr...@php.net
Seems to have been introduced by the fix to bug #52550 (r301991).
[2011-06-03 16:10:14] jille at hexon dot cx
Description:
Round() doesn't work right when the precision is set to e.g. 16.
The last comment in #51701 also makes notice of this. (However it seems
unrelated to that bugreport.)
Bug #5500 states that you shouldn't set the precision higher than the data-type
can hold. If that's still true I think we should add a warning when setting the
precision too high instead of just accepting it and trying to work it out.
_php_math_round in ext/standard/math.c cites:
if ((precision_places = php_intlog10abs(value)) > 0) {
precision_places = 14 - php_intlog10abs(value);
} else {
precision_places = 14;
}
and I guess 14 shouldn't be hardcoded there.
Test script:
---
php > ini_set('precision', 30);
php > var_dump(round((5.5/100), 3));
Expected result:
float(0.055)
Actual result:
--
float(0.0550002775557561563)
--
Edit this bug report at http://bugs.php.net/bug.php?id=54985&edit=1
Bug #55033 [Opn->Bgs]: Memory Leak in magic method __get() [Zend Memory Manager]
Edit report at http://bugs.php.net/bug.php?id=55033&edit=1
ID: 55033
Updated by: fel...@php.net
Reported by:rodney dot rehm at medialize dot de
Summary:Memory Leak in magic method __get() [Zend Memory
Manager]
-Status: Open
+Status: Bogus
Type: Bug
Package:Performance problem
Operating System: Mac OS X 10.6.7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
There is no memleak, what happens is that the return from __get() needs to be
separated.
See bug #48197
Previous Comments:
[2011-06-11 14:40:52] rodney dot rehm at medialize dot de
Description:
For some reason values returned by __get() aren't released from memory.
$ php memory.php # (without --debug)
0.0096 seconds and 1.3461 MB for 1 accessing known property
$ php memory.php # (with --debug)
0.0317 seconds and 2.6435 MB for 1 accessing known property
$ export USE_ZEND_ALLOC=0
$ php memory.php # (with --debug)
0.0267 seconds and 0. MB for 1 accessing known property
since disabling Zend Memory Manager solved the issue, the valgrind log is
pretty much useless, thus not attached.
Test script:
---
{'bar' . $i};
}
$_mem = memory_get_usage();
$_start = microtime(true);
printf("%0.4f seconds and %0.4f MB for %d accessing known property\n", $_start
- $start, ($_mem - $mem) / 1024 / 1024, $iterations);
?>
Expected result:
0.0099 seconds and 0. MB for 1 accessing known property
Actual result:
--
0.0099 seconds and 1.3460 MB for 1 accessing known property
--
Edit this bug report at http://bugs.php.net/bug.php?id=55033&edit=1
Bug #54985 [Bgs]: round doesn't work with non-14 precision
Edit report at http://bugs.php.net/bug.php?id=54985&edit=1
ID: 54985
Updated by: cataphr...@php.net
Reported by:jille at hexon dot cx
Summary:round doesn't work with non-14 precision
Status: Bogus
Type: Bug
Package:*Math Functions
Operating System: n/a
PHP Version:5.3.6
Assigned To:cataphract
Block user comment: N
Private report: N
New Comment:
It does give the correct result; it gives the nearest double number to a
multiple of 0.01. The problem is you are showing digits beyond the number of
digits guaranteed to be correct (i.e. not affected by rounding error). For
doubles, with an effective precision of 53 bits, the (possibly non-integer)
number of digits to the right of the decimal point that is guaranteed to be
correct is given by 53*log10(2) - log10(abs(x)); for x=0.055, this is around
17.21. So for this number you must not set 'precision' beyond 17, otherwise you
might see garbage.
Previous Comments:
[2011-06-11 15:20:23] jille at hexon dot cx
I disagree with that this behaviour is correct. I think there should be a
function which can round() in a reliable way. If it isn't possible with floats
I
think there should be a function which returns a string.
[2011-06-11 04:00:55] cataphr...@php.net
This is a bogus report (.055 is not exactly representable, the closest is
7926335344172073*2^-57); r301991 did introduce a bug, but it's completely
unrelated.
[2011-06-10 20:10:39] cataphr...@php.net
Seems to have been introduced by the fix to bug #52550 (r301991).
[2011-06-03 16:10:14] jille at hexon dot cx
Description:
Round() doesn't work right when the precision is set to e.g. 16.
The last comment in #51701 also makes notice of this. (However it seems
unrelated to that bugreport.)
Bug #5500 states that you shouldn't set the precision higher than the data-type
can hold. If that's still true I think we should add a warning when setting the
precision too high instead of just accepting it and trying to work it out.
_php_math_round in ext/standard/math.c cites:
if ((precision_places = php_intlog10abs(value)) > 0) {
precision_places = 14 - php_intlog10abs(value);
} else {
precision_places = 14;
}
and I guess 14 shouldn't be hardcoded there.
Test script:
---
php > ini_set('precision', 30);
php > var_dump(round((5.5/100), 3));
Expected result:
float(0.055)
Actual result:
--
float(0.0550002775557561563)
--
Edit this bug report at http://bugs.php.net/bug.php?id=54985&edit=1
Bug #55034 [Opn]: ImageCopyResampled doesn't calculate colours properly with alpha
Edit report at http://bugs.php.net/bug.php?id=55034&edit=1 ID: 55034 User updated by:php at mrphlip dot com Reported by:php at mrphlip dot com -Summary:ImageCopyResampled doesn't calculate alpha properly +Summary:ImageCopyResampled doesn't calculate colours properly with alpha Status: Open Type: Bug Package:GD related Operating System: Ubuntu Natty PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Changed summary to be more accurate... it calculates the alpha fine, it's the colours it doesn't calculate correctly in the presence of an alpha channel. Previous Comments: [2011-06-11 15:48:17] php at mrphlip dot com Description: It appears that ImageCopyResampled uses a naive averaging, which isn't correct when there is an alpha channel involved. It should instead use a weighted average for the colour channel, weighting each input pixel according to its opacity (so a more opaque input pixel has more weight in the average). This comes up particularly if you have eg a solid white shape against a solid black-but-transparent background. The original image, every pixel is either white or transparent. But shrink it down, and the object will have a thin dark halo around the edge, because of averaging those black pixels into the result. The expected result would fade from full opacity white, to half opacity white, to transparent any-colour... but the actual result fades from full opacity white, to half opacity *grey*, to transparent black. Test script: --- # create an image with an almost-transparent white pixel and an almost-opaque black pixel $img1 = ImageCreateTrueColor(2, 1); ImageAlphaBlending($img1, FALSE); ImageSetPixel($img1, 0, 0, ImageColorAllocateAlpha($img1, 255, 255, 255, 0x70)); ImageSetPixel($img1, 1, 0, ImageColorAllocateAlpha($img1, 0, 0, 0, 0x10)); # scale the image down to a single pixel - make it mix the two together $img2 = ImageCreateTrueColor(1, 1); ImageAlphaBlending($img2, FALSE); ImageCopyResampled($img2, $img1, 0, 0, 0, 0, 1, 1, 2, 1); # find out what colour the resulting pixel is $col = ImageColorAt($img2, 0, 0); print "R: " . (($col >> 16) & 0xFF) . ""; print "G: " . (($col >> 8) & 0xFF) . ""; print "B: " . ($col & 0xFF) . ""; print "A: " . (($col >> 24) & 0xFF) . ""; # clean up ImageDestroy($img1); ImageDestroy($img2); Expected result: R: 30 G: 30 B: 30 A: 64 Each of the colour channels has been weighted in the average... the almost-transparent white pixel with a weight of 0xF (0x7F - 0x70), and the almost-opaque black pixel with a weight of 0x6F (0x7F - 0x10), giving a weighted average of (255 * 0xF + 0 * 0x6F) / (0xF + 0x6F) == 30. The alpha channel is averaged in the normal way. Actual result: -- R: 127 G: 127 B: 127 A: 64 Each channel has been averaged separately, with no regard for the alpha channel. -- Edit this bug report at http://bugs.php.net/bug.php?id=55034&edit=1
[PHP-BUG] Bug #55035 [NEW]: pcre_exec() deadlock causing Segmentation fault (11)
From: Operating system: Ubuntu 11.04 and Trisquel 4.5 PHP version: 5.3.6 Package: PCRE related Bug Type: Bug Bug description:pcre_exec() deadlock causing Segmentation fault (11) Description: It appears that PHP can deadlock in pcre_exec(), repeatingly calling a function(itself?). Was converting a vBulletin forum to phpBB, therefore might be hard to reproduce. Despite that I managed to reproduce it on three different computers. I spent several hours debugging this, and will dig deeper into the code that caused this problem to find the specific string causing this. Expect more debug data soon. Test script: --- phpBB 3.0.8, converting from vBulletin 3.8.x, with code attached to http://www.phpbb.com/community/viewtopic.php?f=65&t=1722325#p10391895 You also need a database to convert. Expected result: Normal phpBB progress when converting (php deliving an HTML page) Actual result: -- PHP delivered a blank php script file to the browser and apache logged a segfault (11). After a very long session trying to debug this I finally managed to generate a stacktrace with gdb. The resource below will be accessible as long as this bug is unresolved. http://jimmy.axenhus.com/gdb.txt -- Edit bug report at http://bugs.php.net/bug.php?id=55035&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=55035&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=55035&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=55035&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=55035&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=55035&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=55035&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=55035&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=55035&r=needscript Try newer version: http://bugs.php.net/fix.php?id=55035&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=55035&r=support Expected behavior: http://bugs.php.net/fix.php?id=55035&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=55035&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=55035&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=55035&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=55035&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=55035&r=dst IIS Stability: http://bugs.php.net/fix.php?id=55035&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=55035&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=55035&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=55035&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=55035&r=mysqlcfg
[PHP-BUG] Bug #55034 [NEW]: ImageCopyResampled doesn't calculate alpha properly
From: Operating system: Ubuntu Natty PHP version: 5.3.6 Package: GD related Bug Type: Bug Bug description:ImageCopyResampled doesn't calculate alpha properly Description: It appears that ImageCopyResampled uses a naive averaging, which isn't correct when there is an alpha channel involved. It should instead use a weighted average for the colour channel, weighting each input pixel according to its opacity (so a more opaque input pixel has more weight in the average). This comes up particularly if you have eg a solid white shape against a solid black-but-transparent background. The original image, every pixel is either white or transparent. But shrink it down, and the object will have a thin dark halo around the edge, because of averaging those black pixels into the result. The expected result would fade from full opacity white, to half opacity white, to transparent any-colour... but the actual result fades from full opacity white, to half opacity *grey*, to transparent black. Test script: --- # create an image with an almost-transparent white pixel and an almost-opaque black pixel $img1 = ImageCreateTrueColor(2, 1); ImageAlphaBlending($img1, FALSE); ImageSetPixel($img1, 0, 0, ImageColorAllocateAlpha($img1, 255, 255, 255, 0x70)); ImageSetPixel($img1, 1, 0, ImageColorAllocateAlpha($img1, 0, 0, 0, 0x10)); # scale the image down to a single pixel - make it mix the two together $img2 = ImageCreateTrueColor(1, 1); ImageAlphaBlending($img2, FALSE); ImageCopyResampled($img2, $img1, 0, 0, 0, 0, 1, 1, 2, 1); # find out what colour the resulting pixel is $col = ImageColorAt($img2, 0, 0); print "R: " . (($col >> 16) & 0xFF) . ""; print "G: " . (($col >> 8) & 0xFF) . ""; print "B: " . ($col & 0xFF) . ""; print "A: " . (($col >> 24) & 0xFF) . ""; # clean up ImageDestroy($img1); ImageDestroy($img2); Expected result: R: 30 G: 30 B: 30 A: 64 Each of the colour channels has been weighted in the average... the almost-transparent white pixel with a weight of 0xF (0x7F - 0x70), and the almost-opaque black pixel with a weight of 0x6F (0x7F - 0x10), giving a weighted average of (255 * 0xF + 0 * 0x6F) / (0xF + 0x6F) == 30. The alpha channel is averaged in the normal way. Actual result: -- R: 127 G: 127 B: 127 A: 64 Each channel has been averaged separately, with no regard for the alpha channel. -- Edit bug report at http://bugs.php.net/bug.php?id=55034&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=55034&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=55034&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=55034&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=55034&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=55034&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=55034&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=55034&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=55034&r=needscript Try newer version: http://bugs.php.net/fix.php?id=55034&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=55034&r=support Expected behavior: http://bugs.php.net/fix.php?id=55034&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=55034&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=55034&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=55034&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=55034&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=55034&r=dst IIS Stability: http://bugs.php.net/fix.php?id=55034&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=55034&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=55034&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=55034&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=55034&r=mysqlcfg
Bug #54985 [Bgs]: round doesn't work with non-14 precision
Edit report at http://bugs.php.net/bug.php?id=54985&edit=1
ID: 54985
User updated by:jille at hexon dot cx
Reported by:jille at hexon dot cx
Summary:round doesn't work with non-14 precision
Status: Bogus
Type: Bug
Package:*Math Functions
Operating System: n/a
PHP Version:5.3.6
Assigned To:cataphract
Block user comment: N
Private report: N
New Comment:
I disagree with that this behaviour is correct. I think there should be a
function which can round() in a reliable way. If it isn't possible with floats
I
think there should be a function which returns a string.
Previous Comments:
[2011-06-11 04:00:55] cataphr...@php.net
This is a bogus report (.055 is not exactly representable, the closest is
7926335344172073*2^-57); r301991 did introduce a bug, but it's completely
unrelated.
[2011-06-10 20:10:39] cataphr...@php.net
Seems to have been introduced by the fix to bug #52550 (r301991).
[2011-06-03 16:10:14] jille at hexon dot cx
Description:
Round() doesn't work right when the precision is set to e.g. 16.
The last comment in #51701 also makes notice of this. (However it seems
unrelated to that bugreport.)
Bug #5500 states that you shouldn't set the precision higher than the data-type
can hold. If that's still true I think we should add a warning when setting the
precision too high instead of just accepting it and trying to work it out.
_php_math_round in ext/standard/math.c cites:
if ((precision_places = php_intlog10abs(value)) > 0) {
precision_places = 14 - php_intlog10abs(value);
} else {
precision_places = 14;
}
and I guess 14 shouldn't be hardcoded there.
Test script:
---
php > ini_set('precision', 30);
php > var_dump(round((5.5/100), 3));
Expected result:
float(0.055)
Actual result:
--
float(0.0550002775557561563)
--
Edit this bug report at http://bugs.php.net/bug.php?id=54985&edit=1
[PHP-BUG] Bug #55033 [NEW]: Memory Leak in magic method __get() [Zend Memory Manager]
From:
Operating system: Mac OS X 10.6.7
PHP version: 5.3.6
Package: Performance problem
Bug Type: Bug
Bug description:Memory Leak in magic method __get() [Zend Memory Manager]
Description:
For some reason values returned by __get() aren't released from memory.
$ php memory.php # (without --debug)
0.0096 seconds and 1.3461 MB for 1 accessing known property
$ php memory.php # (with --debug)
0.0317 seconds and 2.6435 MB for 1 accessing known property
$ export USE_ZEND_ALLOC=0
$ php memory.php # (with --debug)
0.0267 seconds and 0. MB for 1 accessing known property
since disabling Zend Memory Manager solved the issue, the valgrind log is
pretty much useless, thus not attached.
Test script:
---
{'bar' . $i};
}
$_mem = memory_get_usage();
$_start = microtime(true);
printf("%0.4f seconds and %0.4f MB for %d accessing known property\n",
$_start - $start, ($_mem - $mem) / 1024 / 1024, $iterations);
?>
Expected result:
0.0099 seconds and 0. MB for 1 accessing known property
Actual result:
--
0.0099 seconds and 1.3460 MB for 1 accessing known property
--
Edit bug report at http://bugs.php.net/bug.php?id=55033&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=55033&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=55033&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=55033&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=55033&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=55033&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=55033&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=55033&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=55033&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=55033&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=55033&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=55033&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=55033&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=55033&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=55033&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=55033&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=55033&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=55033&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=55033&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=55033&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=55033&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=55033&r=mysqlcfg
Req #52569 [Ana]: Implement "ondemand" process-manager (to allow zero children)
Edit report at http://bugs.php.net/bug.php?id=52569&edit=1 ID: 52569 User updated by:mplomer at gmx dot de Reported by:mplomer at gmx dot de Summary:Implement "ondemand" process-manager (to allow zero children) Status: Analyzed Type: Feature/Change Request Package:FPM related PHP Version:5.3.3 Assigned To:fat Block user comment: N Private report: N New Comment: Unfortunately not, as libevent was removed from FPM in PHP 5.3.4, the patch has to be ported to the new simple mini event library. If you are interested to do the port and you are familar with C you are welcome, and I can give you a quick starting point. Previous Comments: [2011-06-11 10:22:33] denoc at gmx dot de I tried to patch php5-5.3.5 with the last offered patch, but it did not work. Does a patch against the current version exist? Thanks [2010-11-12 02:30:36] luca at fantacast dot it Just to be clear, I'm not advocating this solution, just contemplating the implications. Hand built disable_functions by sysadmins is not realistic and centralized maintenance in FPM code (if at all possible) would still require work and be prone to error. Running as root is very bad security wise and makes almost every other security check useless in case of a bug. [2010-11-12 01:53:01] f...@php.net > However this could be easily prevented by using disable_functions > to prevent these and other potentially harmful functions from > being called (system, exec, etc) which could be used to achieve > the same goal and are not desirable in a shared hosting environment anyway. - it's very complex to do. - you have no guarantee that nothing will be forgotten (until a security hole is found) - you have to maintain this security layer over the time, adding new functions, ... - If the sysadm have to list the functions to be forgotten, it will forget some (by following a buggy how-to -- which are all over the Internet btw) > Obviously this wouldn't protect against PHP bugs > allowing arbitrary code execution, so it only > mitigates the potential risk. I'm sorry, but it's not an option to me. There security checks at kernel level which must not be gotten arround by code running from userland (PHP core). [2010-11-12 01:28:55] luca at fantacast dot it Just a thought on the dynamic setuid/setgid/chroot via fastcgi variables exclusion because of security concerns. In the group discussion you pointed out how this opens up the possibility for an attacker to call posix_setuid/posix_setgid in PHP code to get root privileges. However this could be easily prevented by using disable_functions to prevent these and other potentially harmful functions from being called (system, exec, etc) which could be used to achieve the same goal and are not desirable in a shared hosting environment anyway. I guess this and other protections could be even enforced automatically by PHP FPM if dynamic setuid/setgid/chroot via fastcgi variables is requested. Obviously this wouldn't protect against PHP bugs allowing arbitrary code execution, so it only mitigates the potential risk. [2010-09-25 18:26:58] mplomer at gmx dot de Released patch v6 - Updated patch to be compatible with current PHP_5_3 branch (rev 303365) There are no functional changes against v5 Merged (removed) parts which have already been committed: - rev 301886: only one process (for all pools) could be killed by the 'dynamic' process manager - rev 301912: Changed listen.backlog in the FPM configuration file to default to 128 instead of -1 - rev 301913: Add libevent version to the startup debug log in FPM - rev 301925: add 'max children reached' to the FPM status page Changes: - Undo change in config.m4 which has IMHO nothing to do with this patch - Merged listen.backlog part in php-fpm.conf.in from trunk (trunk and 5.3-branch is currently out of sync here!) - (small code beautify) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52569 -- Edit this bug report at http://bugs.php.net/bug.php?id=52569&edit=1
Req #52569 [Com]: Implement "ondemand" process-manager (to allow zero children)
Edit report at http://bugs.php.net/bug.php?id=52569&edit=1 ID: 52569 Comment by: denoc at gmx dot de Reported by:mplomer at gmx dot de Summary:Implement "ondemand" process-manager (to allow zero children) Status: Analyzed Type: Feature/Change Request Package:FPM related PHP Version:5.3.3 Assigned To:fat Block user comment: N Private report: N New Comment: I tried to patch php5-5.3.5 with the last offered patch, but it did not work. Does a patch against the current version exist? Thanks Previous Comments: [2010-11-12 02:30:36] luca at fantacast dot it Just to be clear, I'm not advocating this solution, just contemplating the implications. Hand built disable_functions by sysadmins is not realistic and centralized maintenance in FPM code (if at all possible) would still require work and be prone to error. Running as root is very bad security wise and makes almost every other security check useless in case of a bug. [2010-11-12 01:53:01] f...@php.net > However this could be easily prevented by using disable_functions > to prevent these and other potentially harmful functions from > being called (system, exec, etc) which could be used to achieve > the same goal and are not desirable in a shared hosting environment anyway. - it's very complex to do. - you have no guarantee that nothing will be forgotten (until a security hole is found) - you have to maintain this security layer over the time, adding new functions, ... - If the sysadm have to list the functions to be forgotten, it will forget some (by following a buggy how-to -- which are all over the Internet btw) > Obviously this wouldn't protect against PHP bugs > allowing arbitrary code execution, so it only > mitigates the potential risk. I'm sorry, but it's not an option to me. There security checks at kernel level which must not be gotten arround by code running from userland (PHP core). [2010-11-12 01:28:55] luca at fantacast dot it Just a thought on the dynamic setuid/setgid/chroot via fastcgi variables exclusion because of security concerns. In the group discussion you pointed out how this opens up the possibility for an attacker to call posix_setuid/posix_setgid in PHP code to get root privileges. However this could be easily prevented by using disable_functions to prevent these and other potentially harmful functions from being called (system, exec, etc) which could be used to achieve the same goal and are not desirable in a shared hosting environment anyway. I guess this and other protections could be even enforced automatically by PHP FPM if dynamic setuid/setgid/chroot via fastcgi variables is requested. Obviously this wouldn't protect against PHP bugs allowing arbitrary code execution, so it only mitigates the potential risk. [2010-09-25 18:26:58] mplomer at gmx dot de Released patch v6 - Updated patch to be compatible with current PHP_5_3 branch (rev 303365) There are no functional changes against v5 Merged (removed) parts which have already been committed: - rev 301886: only one process (for all pools) could be killed by the 'dynamic' process manager - rev 301912: Changed listen.backlog in the FPM configuration file to default to 128 instead of -1 - rev 301913: Add libevent version to the startup debug log in FPM - rev 301925: add 'max children reached' to the FPM status page Changes: - Undo change in config.m4 which has IMHO nothing to do with this patch - Merged listen.backlog part in php-fpm.conf.in from trunk (trunk and 5.3-branch is currently out of sync here!) - (small code beautify) [2010-09-13 06:27:20] f...@php.net You should "make clean" before recompiling with v5 patch. The v5 patch does not apply on 5.3.3, it applies on the svn PHP5_3_3 branch. ++ Jerome The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52569 -- Edit this bug report at http://bugs.php.net/bug.php?id=52569&edit=1
Req #39234 [Asn->Csd]: Retrieve short names to files
Edit report at http://bugs.php.net/bug.php?id=39234&edit=1 ID: 39234 Updated by: rquadl...@php.net Reported by:RQuadling at GMail dot com Summary:Retrieve short names to files -Status: Assigned +Status: Closed Type: Feature/Change Request Package:Filesystem function related Operating System: Windows only PHP Version:* Assigned To:pajoye Block user comment: N Private report: N New Comment: As PHP now uses another feature of cmd.exe, this allows all elements of the command line (programs and parameters) to be quoted quite happily. As such, this request is no longer needed. Previous Comments: [2006-10-23 12:39:29] RQuadling at GMail dot com http://msdn.microsoft.com/library/en-us/fileio/fs/getfullpathname.asp and http://msdn.microsoft.com/library/en-us/fileio/fs/getshortpathname.asp (Maybe these will fit?) [2006-10-23 12:37:56] RQuadling at GMail dot com Description: Hello. (I was required to pick a version, but that is not really relevant). This issue extends from a bug/feature of the Windows command shell executable (cmd.exe) which only allows a single set of double quotes to be used when being used with the /C option. e.g. You get an error which is the same at the command prompt. These work (the parameter is useless). C:\windows\system32\calc.exe 123 "C:\windows\system32\calc.exe" 123 C:\windows\system32\calc.exe "123" "C:\windows\system32\calc.exe" "123" cmd /c C:\windows\system32\calc.exe 123 cmd /c "C:\windows\system32\calc.exe" 123 cmd /c C:\windows\system32\calc.exe "123" But this doesn't work at the command line. cmd /c "C:\windows\system32\calc.exe" "123" You get the error ... 'C:\windows\system32\calc.exe" "123' is not recognized as an internal or external command, operable program or batch file. So, whilst this isn't a PHP bug, PHP could certainly help get around the problem. My proposal is to either extend the PHP function realpath() to allow for a boolean parameter to indicate the short name is to be returned. e.g. string realpath ( string path [, boolean return_short_name] ) or to introduce 2 new functions string shortname ( string longname ) string longname ( string shortname ) In addition, extending the SPL to have a getShortName() method. To get the shortname within MS VC++, there is a function called GetShortPathName(). There is also GetLongPathName(). References to these functions can be found at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/getshortpathname.asp and http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/getlongpathname.asp DWORD GetShortPathName( LPCTSTR lpszLongPath, LPTSTR lpszShortPath, DWORD cchBuffer ); DWORD GetLongPathName( LPCTSTR lpszShortPath, LPTSTR lpszLongPath, DWORD cchBuffer ); With the shortname() function, a filename like ... C:\Program Files\Microsoft SQL Server\80\Tools\Binn\osql.exe would become ... C:\PROGRA~1\MI6841~1\80\TOOLS\BINN\OSQL.EXE The name supplied is system dependent. I have a LOT of directories in "C:\Program Files" starting with Microsoft. 27/10/2004 15:01 MI3AA1~1 Microsoft ActiveSync 16/03/2006 11:13 MIAF83~1 Microsoft AntiSpyware 05/01/2005 10:02 MIDA86~1 Microsoft Baseline Security Analyzer 23/02/2005 16:17 MIAF01~1 Microsoft Firewall Client 27/10/2004 12:13 MICROS~1 microsoft frontpage 06/04/2006 09:22 MICROS~3 Microsoft IntelliPoint 06/04/2006 09:26 MICROS~2 Microsoft IntelliType Pro 06/04/2006 10:13 MICROS~4 Microsoft Office 29/10/2004 14:36 MI6841~1 Microsoft SQL Server 16/11/2004 16:31 MIAF9D~1 Microsoft Visual Studio 28/10/2004 08:44 MIF2B0~1 Microsoft Works 23/02/2005 12:02 MICROS~1.NET Microsoft.NET In terms of impact, making 2 new functions which are Windows only would probably be easier. -- Edit this bug report at http://bugs.php.net/bug.php?id=39234&edit=1
