Bug #64007 [Asn-Csd]: There is an ability to create instance of Generator by hand
Edit report at https://bugs.php.net/bug.php?id=64007edit=1
ID: 64007
Updated by: larue...@php.net
Reported by:lisachenko dot it at gmail dot com
Summary:There is an ability to create instance of Generator
by hand
-Status: Assigned
+Status: Closed
Type: Bug
Package:Reflection related
Operating System: Windows 7 x64
PHP Version:5.5.0alpha2
Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=f7b99c481d0a943d922e99ad9afa82c45193030e
Log: Fixed bug #64007 (There is an ability to create instance of Generator by
hand).
Previous Comments:
[2013-01-17 18:21:38] ni...@php.net
@laruence: Imho `new Foo($bar)` and `(new
ReflectionClass('Foo'))-newInstance($bar)` should behave the same. So if the
constructor throws a fatal error then the constructor invoked through
reflection should also throw a fatal error.
If reflection doesn't go through get_constructor then it won't work correctly
if that handler is overloaded. It just works so well right now because nearly
noone overrides get_constructor.
[2013-01-17 10:40:17] larue...@php.net
@nikic, after a digging, I think it's better to make a private constructor for
generators. here is the reason:
refelction_class-newInstance used to throw exception while the constructor is
non-public..
if change to get_constructor, boom~ FATAL ERROR.
[2013-01-17 10:07:24] larue...@php.net
agree, I will make a patch
[2013-01-16 12:50:56] ni...@php.net
Looks like a bug in Reflection. It should get the constructor through the
`get_constructor` handler, not from the class property.
[2013-01-16 12:37:13] lisachenko dot it at gmail dot com
Description:
Generator is an internal class, so there shouldn't be an ability to create it
by hand. However, the Generator class doesn't have a private constructor and
instance of it can be created via ReflectionClass.
Solution: add a private constructor for this class to prevent instantiation
(like for Closure class).
Test script:
---
$reflection = new ReflectionClass('Generator');
$generator = $reflection-newInstance();
var_dump($generator);
Expected result:
Expected ReflectionException that restricts an object instantiation.
Fatal error: Uncaught exception 'ReflectionException' with message 'Access to
non-public constructor of class Generator'
Actual result:
--
Generator object created:
object(Generator)#2 (0) { }
--
Edit this bug report at https://bugs.php.net/bug.php?id=64007edit=1
Bug #64007 [Csd-Asn]: There is an ability to create instance of Generator by hand
Edit report at https://bugs.php.net/bug.php?id=64007edit=1
ID: 64007
Updated by: larue...@php.net
Reported by:lisachenko dot it at gmail dot com
Summary:There is an ability to create instance of Generator
by hand
-Status: Closed
+Status: Assigned
Type: Bug
Package:Reflection related
Operating System: Windows 7 x64
PHP Version:5.5.0alpha2
-Assigned To:nikic
+Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
The fix for this bug has been committed.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2013-01-19 09:02:23] larue...@php.net
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=f7b99c481d0a943d922e99ad9afa82c45193030e
Log: Fixed bug #64007 (There is an ability to create instance of Generator by
hand).
[2013-01-17 18:21:38] ni...@php.net
@laruence: Imho `new Foo($bar)` and `(new
ReflectionClass('Foo'))-newInstance($bar)` should behave the same. So if the
constructor throws a fatal error then the constructor invoked through
reflection should also throw a fatal error.
If reflection doesn't go through get_constructor then it won't work correctly
if that handler is overloaded. It just works so well right now because nearly
noone overrides get_constructor.
[2013-01-17 10:40:17] larue...@php.net
@nikic, after a digging, I think it's better to make a private constructor for
generators. here is the reason:
refelction_class-newInstance used to throw exception while the constructor is
non-public..
if change to get_constructor, boom~ FATAL ERROR.
[2013-01-17 10:07:24] larue...@php.net
agree, I will make a patch
[2013-01-16 12:50:56] ni...@php.net
Looks like a bug in Reflection. It should get the constructor through the
`get_constructor` handler, not from the class property.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=64007
--
Edit this bug report at https://bugs.php.net/bug.php?id=64007edit=1
Bug #64007 [Asn-Csd]: There is an ability to create instance of Generator by hand
Edit report at https://bugs.php.net/bug.php?id=64007edit=1
ID: 64007
Updated by: larue...@php.net
Reported by:lisachenko dot it at gmail dot com
Summary:There is an ability to create instance of Generator
by hand
-Status: Assigned
+Status: Closed
Type: Bug
Package:Reflection related
Operating System: Windows 7 x64
PHP Version:5.5.0alpha2
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=f7b99c481d0a943d922e99ad9afa82c45193030e
Log: Fixed bug #64007 (There is an ability to create instance of Generator by
hand).
Previous Comments:
[2013-01-19 09:02:42] larue...@php.net
The fix for this bug has been committed.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
[2013-01-19 09:02:23] larue...@php.net
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=f7b99c481d0a943d922e99ad9afa82c45193030e
Log: Fixed bug #64007 (There is an ability to create instance of Generator by
hand).
[2013-01-17 18:21:38] ni...@php.net
@laruence: Imho `new Foo($bar)` and `(new
ReflectionClass('Foo'))-newInstance($bar)` should behave the same. So if the
constructor throws a fatal error then the constructor invoked through
reflection should also throw a fatal error.
If reflection doesn't go through get_constructor then it won't work correctly
if that handler is overloaded. It just works so well right now because nearly
noone overrides get_constructor.
[2013-01-17 10:40:17] larue...@php.net
@nikic, after a digging, I think it's better to make a private constructor for
generators. here is the reason:
refelction_class-newInstance used to throw exception while the constructor is
non-public..
if change to get_constructor, boom~ FATAL ERROR.
[2013-01-17 10:07:24] larue...@php.net
agree, I will make a patch
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=64007
--
Edit this bug report at https://bugs.php.net/bug.php?id=64007edit=1
[PHP-BUG] Req #64030 [NEW]: Extend the ::class-feature
From: bobwei9 at hotmail dot com
Operating system: Irrelevant
PHP version: 5.5Git-2013-01-19 (Git)
Package: Scripting Engine problem
Bug Type: Feature/Change Request
Bug description:Extend the ::class-feature
Description:
I just have seen this commit:
http://git.php.net/?p=php-src.git;a=commitdiff;h=8991ed016fa257c9f8ba42580c34568b3c2ce3e5
Could you also add $instance-class ?
Which operates on an already instanced Object. Would be for example useful
to be able to handle internal and userland classes differently.
Test script:
---
function isInternalObject ($object) {
if (!is_object($object))
return false;
return !file_exists(classes/$object.php);
}
// In the case where you name the files with the name of their class...
include 'classes/Foo.php';
$foo = new Foo();
$std = new stdClass;
var_dump(isInternalObject($foo));
var_dump(isInternalObject($std));
Expected result:
bool(false)
bool(true)
Actual result:
--
Notice: Undefined property: %s::$class in php shell code on line 1
--
Edit bug report at https://bugs.php.net/bug.php?id=64030edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64030r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64030r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64030r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64030r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64030r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64030r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64030r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64030r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64030r=support
Expected behavior: https://bugs.php.net/fix.php?id=64030r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64030r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64030r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64030r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64030r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64030r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64030r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64030r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64030r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64030r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64030r=mysqlcfg
Req #64030 [Opn]: Extend the ::class-feature
Edit report at https://bugs.php.net/bug.php?id=64030edit=1
ID: 64030
User updated by:bobwei9 at hotmail dot com
Reported by:bobwei9 at hotmail dot com
Summary:Extend the ::class-feature
Status: Open
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: Irrelevant
PHP Version:5.5Git-2013-01-19 (Git)
Block user comment: N
Private report: N
New Comment:
I mean:
return !file_exists(classes/{$object-class}.php);
in the test script...
Previous Comments:
[2013-01-19 10:17:57] bobwei9 at hotmail dot com
Description:
I just have seen this commit:
http://git.php.net/?p=php-src.git;a=commitdiff;h=8991ed016fa257c9f8ba42580c34568b3c2ce3e5
Could you also add $instance-class ?
Which operates on an already instanced Object. Would be for example useful to
be able to handle internal and userland classes differently.
Test script:
---
function isInternalObject ($object) {
if (!is_object($object))
return false;
return !file_exists(classes/$object.php);
}
// In the case where you name the files with the name of their class...
include 'classes/Foo.php';
$foo = new Foo();
$std = new stdClass;
var_dump(isInternalObject($foo));
var_dump(isInternalObject($std));
Expected result:
bool(false)
bool(true)
Actual result:
--
Notice: Undefined property: %s::$class in php shell code on line 1
--
Edit this bug report at https://bugs.php.net/bug.php?id=64030edit=1
Bug #62129 [Com]: rfc1867 crashes php even though turned off
Edit report at https://bugs.php.net/bug.php?id=62129edit=1
ID: 62129
Comment by: gxd305 at gmail dot com
Reported by:truth at proposaltech dot com
Summary:rfc1867 crashes php even though turned off
Status: Assigned
Type: Bug
Package:Session related
Operating System: CentOS
PHP Version:5.4.3
Assigned To:iliaa
Block user comment: N
Private report: N
New Comment:
the other extensions have the similar problems if not set the global var to
null in mshutdown after reload.
php_session_rfc1867_orig_callback reserve the last value after reload, instead
of the default value nullã
such as ice-php has the same problem, not set the global vars to null in
mshutdown.
if i set the global vars ' default value explicitly or set the global vars to
null in mshutdown, the problem goes away.
Previous Comments:
[2012-05-24 20:48:14] truth at proposaltech dot com
Here is a the relevant portion of the backtrace from the seg fault:
#104648 0x006cd5b8 in php_session_rfc1867_callback (event=0,
event_data=0x7fffb2b8f950, extra=value optimized out)
at /cns/build/php-5.4.3/ext/session/session.c:2388
#104649 0x006cd5b8 in php_session_rfc1867_callback (event=0,
event_data=0x7fffb2b8f950, extra=value optimized out)
at /cns/build/php-5.4.3/ext/session/session.c:2388
#104650 0x00473841 in rfc1867_post_handler (
content_type_dup=value optimized out, arg=0x11535e8)
at /cns/build/php-5.4.3/main/rfc1867.c:773
#104651 0x00471372 in sapi_handle_post (arg=value optimized out)
at /cns/build/php-5.4.3/main/SAPI.c:182
#104652 0x0067efd8 in mbstr_treat_data (arg=0, str=0x0,
destArray=value optimized out)
at /cns/build/php-5.4.3/ext/mbstring/mb_gpc.c:98
#104653 0x00475e9e in php_auto_globals_create_post (
name=0x12a6a60 _POST, name_len=5)
at /cns/build/php-5.4.3/main/php_variables.c:682
#104654 0x0049aa4b in zend_auto_global_init (auto_global=0x110e800)
at /cns/build/php-5.4.3/Zend/zend_compile.c:
#104655 0x004ca974 in zend_hash_apply (ht=0x111bf20,
apply_func=0x49aa30 zend_auto_global_init)
at /cns/build/php-5.4.3/Zend/zend_hash.c:716
#104656 0x004772bb in php_hash_environment ()
at /cns/build/php-5.4.3/main/php_variables.c:642
#104657 0x004697f5 in php_request_startup ()
at /cns/build/php-5.4.3/main/main.c:1568
#104658 0x0056084f in apache_php_module_main (r=value optimized out,
display_source_mode=0) at /cns/build/php-5.4.3/sapi/apache/sapi_apache.c:33
#104659 0x00461c00 in send_php ()
#104660 0x00461c48 in send_parsed_php ()
#104661 0x0085f773 in ap_invoke_handler ()
#104662 0x00878d90 in process_request_internal ()
#104663 0x00878df3 in ap_process_request ()
#104664 0x0086e46f in child_main ()
#104665 0x0086e728 in make_child ()
#104666 0x0086e7e9 in startup_children ()
#104667 0x0086effb in standalone_main ()
#104668 0x0086f8cc in main ()
I don't know much about internals, but I'll try to translate the
above based on function names and values I saw in the debugger.
While activating auto_globals, the _POST auto_global had a
callback to be called: php_auto_globals_create_post().
That used the mbstring extension, which for the case of
PARSE_POST, relies on sapi_handle_post().
sapi_handle_post() used rfc1867_post_handler()
because the sapi_globals.request_info.post_entry had
an rfc1867 post_handler:
print *sapi_globals.request_info.post_entry
$7 = {content_type = 0x8c4bc9 multipart/form-data, content_type_len = 19,
post_reader = 0, post_handler = 0x473590 rfc1867_post_handler}
I don't know why that post_handler value was set to
rfc1867_post_handler given that my php.ini includes
session.upload_progress.enabled = off
Similarly, I don't know why php_rfc1867_callback was
non-null given my php.ini setting.
Once the php_rfc1867_callback() was called, everything
died quickly. That callback calls the orig_callback
(if non-null) and the orig_callback was the same as
the php_session_rfc1867_callback - endless recursion.
Perhaps the real killer is the following lines from
session.c (~line 2195):
php_session_rfc1867_orig_callback = php_rfc1867_callback;
php_rfc1867_callback = php_session_rfc1867_callback;
I don't think those lines should be called if I have
session.upload_progress.enabled = off
in my php.ini. Setting php_rfc1867_callback seems
to be what cause rfc1867 code to be called. Setting
php_session_rfc1867_orig_callback to php_rfc1867_callback
(which is php_session_rfc1867_callback) leads to the
endless recursion.
Sorry I don't have a fix.
Thanks very much for continuing to improve php!!!
[2012-05-24
Bug #64027 [Opn-Nab]: ForEach fails to add new key/value pairs
Edit report at https://bugs.php.net/bug.php?id=64027edit=1 ID: 64027 Updated by: cataphr...@php.net Reported by:mfuhrman at enetarch dot net Summary:ForEach fails to add new key/value pairs -Status: Open +Status: Not a bug Type: Bug Package:Scripting Engine problem Operating System: Linux svm0907pdv 2.6.18-308.8.2. PHP Version:5.3Git-2013-01-18 (snap) 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: [2013-01-18 22:00:06] matthew dot vince at gmail dot com This is expected behavior. To modify values using a foreach loop, you need to assign by reference, as explained in the foreach documentation: foreach ($aryJunk AS $sub) $sub [munch] = junk; http://php.net/manual/en/control-structures.foreach.php [2013-01-18 20:13:51] mfuhrman at enetarch dot net Description: using PHP Version 5.3.3, Build Date Jun 25 2012 04:51:11 In testing updating nested arrays, I'm finding the that the results of an array is not updated, since the variable used to point to that portion of the array seems to be a copy of the data and not a direct reference to the data. Below is an array of arrays. In the for loop, $sub points to $aryJunk's elements .. 0 .. 4 respectively. When $sub has a new key value pair added, ex. munch = junk, this value only exists as long as $sub exists in the for loop. Outside that loop, the key value pair are lost. It is my understanding that this key value pair should not be lost. Or, at least I cannot find an example that says definitively one way or the other. Please test to see if this issue still exists in the latest version of PHP, and determine the next steps to resolution. Michael J. Fuhrman mfuhr...@enetarch.net skype ENetArch Test script: --- $aryJunk = Array ( 0 = array(), 1 = array(), 2 = array(), 3 = array(), 4 = array(), ); // fails foreach ($aryJunk AS $sub) $sub [munch] = junk; print_r ($aryJunk); // works for ($t=0; $t count ($aryJunk); $t++) $aryJunk[$t] [munch] = junk; print_r ($aryJunk); Expected result: Array ( [0] = Array ( [munch] = junk ) [1] = Array ( [munch] = junk ) [2] = Array ( [munch] = junk ) [3] = Array ( [munch] = junk ) [4] = Array ( [munch] = junk ) ) Actual result: -- Array ( [0] = Array ( ) [1] = Array ( ) [2] = Array ( ) [3] = Array ( ) [4] = Array ( ) ) -- Edit this bug report at https://bugs.php.net/bug.php?id=64027edit=1
Req #52523 [Csd]: mcrypt_create_iv not reliable on win: Could not gather sufficient random data
Edit report at https://bugs.php.net/bug.php?id=52523edit=1 ID: 52523 Updated by: paj...@php.net Reported by:php-bugs at thequod dot de Summary:mcrypt_create_iv not reliable on win: Could not gather sufficient random data Status: Closed Type: Feature/Change Request Package:mcrypt related Operating System: win32 PHP Version:5.3.3 Assigned To:pajoye Block user comment: N Private report: N New Comment: @mah at everybody dot org Again, there is zero difference between the two on Windows. If you can 100% reproduce the problem, then I really need to know your configuration, windows version, php version, etc. Also to test it, you can try using a simple script calling the mcrypt function directly instead of using mediawiki. Previous Comments: [2013-01-19 02:50:08] mah at everybody dot org Just came across this while trying to install the latest MediaWiki on a host with PHP 5.3.5 phpinfo() reports has a system string of Windows NT A1-WHW-B69 6.0 build 6002 (Windows Server 2008 Web Server Edition Service Pack 2) i586 and a build date of Jan 5 2011 20:33:43. Since this was on a hosted account, I didn't have the opportunity to upgrade PHP and I couldn't find a way to test for the bug without causing a fatal error. If I had been able to do that, I would have added code to MediaWiki to test for the bug. I was able to work-around the bug by modifying the installer source so that MCRYPT_RAND was used instead of MCRYPT_DEV_URANDOM. For a package like MediaWiki, though, this is less than ideal. [2011-06-14 11:17:03] paj...@php.net There is no difference between the two on Windows. Both called the same function. How do you get the error? Which windows version do you use? [2011-06-14 10:28:23] s...@php.net I'm still experiencing issues with 5.3.6. Calling the method with both MCRYPT_DEV_RANDOM and MCRYPT_DEV_URANDOM results in the fatal error. IMO the first should block, and the second should just return non-crypto-safe data, but it should return *something*, and ideally do it fast. [2010-08-09 10:14:52] 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-08-09 10:14:16] paj...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=302024 Log: - #52523, fix logic (0 is perfectly valid as part of the data, bin data) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=52523 -- Edit this bug report at https://bugs.php.net/bug.php?id=52523edit=1
Bug #62129 [Com]: rfc1867 crashes php even though turned off
Edit report at https://bugs.php.net/bug.php?id=62129edit=1
ID: 62129
Comment by: gxd305 at gmail dot com
Reported by:truth at proposaltech dot com
Summary:rfc1867 crashes php even though turned off
Status: Assigned
Type: Bug
Package:Session related
Operating System: CentOS
PHP Version:5.4.3
Assigned To:iliaa
Block user comment: N
Private report: N
New Comment:
i'm sorry for the last comment for the wrong analysis.
it should be php_rfc1867_callback reserve the old value (
php_session_rfc1867_callback) after reload, and make
php_session_rfc1867_callback be called recursively.
Previous Comments:
[2013-01-19 11:26:34] gxd305 at gmail dot com
the other extensions have the similar problems if not set the global var to
null in mshutdown after reload.
php_session_rfc1867_orig_callback reserve the last value after reload, instead
of the default value nullã
such as ice-php has the same problem, not set the global vars to null in
mshutdown.
if i set the global vars ' default value explicitly or set the global vars to
null in mshutdown, the problem goes away.
[2012-05-24 20:48:14] truth at proposaltech dot com
Here is a the relevant portion of the backtrace from the seg fault:
#104648 0x006cd5b8 in php_session_rfc1867_callback (event=0,
event_data=0x7fffb2b8f950, extra=value optimized out)
at /cns/build/php-5.4.3/ext/session/session.c:2388
#104649 0x006cd5b8 in php_session_rfc1867_callback (event=0,
event_data=0x7fffb2b8f950, extra=value optimized out)
at /cns/build/php-5.4.3/ext/session/session.c:2388
#104650 0x00473841 in rfc1867_post_handler (
content_type_dup=value optimized out, arg=0x11535e8)
at /cns/build/php-5.4.3/main/rfc1867.c:773
#104651 0x00471372 in sapi_handle_post (arg=value optimized out)
at /cns/build/php-5.4.3/main/SAPI.c:182
#104652 0x0067efd8 in mbstr_treat_data (arg=0, str=0x0,
destArray=value optimized out)
at /cns/build/php-5.4.3/ext/mbstring/mb_gpc.c:98
#104653 0x00475e9e in php_auto_globals_create_post (
name=0x12a6a60 _POST, name_len=5)
at /cns/build/php-5.4.3/main/php_variables.c:682
#104654 0x0049aa4b in zend_auto_global_init (auto_global=0x110e800)
at /cns/build/php-5.4.3/Zend/zend_compile.c:
#104655 0x004ca974 in zend_hash_apply (ht=0x111bf20,
apply_func=0x49aa30 zend_auto_global_init)
at /cns/build/php-5.4.3/Zend/zend_hash.c:716
#104656 0x004772bb in php_hash_environment ()
at /cns/build/php-5.4.3/main/php_variables.c:642
#104657 0x004697f5 in php_request_startup ()
at /cns/build/php-5.4.3/main/main.c:1568
#104658 0x0056084f in apache_php_module_main (r=value optimized out,
display_source_mode=0) at /cns/build/php-5.4.3/sapi/apache/sapi_apache.c:33
#104659 0x00461c00 in send_php ()
#104660 0x00461c48 in send_parsed_php ()
#104661 0x0085f773 in ap_invoke_handler ()
#104662 0x00878d90 in process_request_internal ()
#104663 0x00878df3 in ap_process_request ()
#104664 0x0086e46f in child_main ()
#104665 0x0086e728 in make_child ()
#104666 0x0086e7e9 in startup_children ()
#104667 0x0086effb in standalone_main ()
#104668 0x0086f8cc in main ()
I don't know much about internals, but I'll try to translate the
above based on function names and values I saw in the debugger.
While activating auto_globals, the _POST auto_global had a
callback to be called: php_auto_globals_create_post().
That used the mbstring extension, which for the case of
PARSE_POST, relies on sapi_handle_post().
sapi_handle_post() used rfc1867_post_handler()
because the sapi_globals.request_info.post_entry had
an rfc1867 post_handler:
print *sapi_globals.request_info.post_entry
$7 = {content_type = 0x8c4bc9 multipart/form-data, content_type_len = 19,
post_reader = 0, post_handler = 0x473590 rfc1867_post_handler}
I don't know why that post_handler value was set to
rfc1867_post_handler given that my php.ini includes
session.upload_progress.enabled = off
Similarly, I don't know why php_rfc1867_callback was
non-null given my php.ini setting.
Once the php_rfc1867_callback() was called, everything
died quickly. That callback calls the orig_callback
(if non-null) and the orig_callback was the same as
the php_session_rfc1867_callback - endless recursion.
Perhaps the real killer is the following lines from
session.c (~line 2195):
php_session_rfc1867_orig_callback = php_rfc1867_callback;
php_rfc1867_callback = php_session_rfc1867_callback;
I don't think those lines should be called if I have
session.upload_progress.enabled = off
in my php.ini. Setting php_rfc1867_callback seems
to be
Bug #64023 [Opn-Ver]: Overloading __toString() in SplFileInfo has no effect
Edit report at https://bugs.php.net/bug.php?id=64023edit=1
ID: 64023
Updated by: cataphr...@php.net
Reported by:php at lightning dot hu
Summary:Overloading __toString() in SplFileInfo has no
effect
-Status: Open
+Status: Verified
Type: Bug
Package:SPL related
Operating System: Linux
PHP Version:Irrelevant
Block user comment: N
Private report: N
Previous Comments:
[2013-01-18 15:24:39] php at lightning dot hu
Description:
When I overload the __toString() magic method in the SplFileInfo class or in
one
of it's derivatives it does not work if I concatenate the object with a string.
See the example for a simple demonstration.
Test script:
---
class A extends \SplFileInfo
{
public function __toString() {return ' -expected- ';}
}
$a = new A('/');
// Works
echo $a, $a-__toString(), $a-__toString() . '';
// Does not work - outputs parent::__toString()
echo $a . '';
Expected result:
-expected- -expected- -expected- /
--
Edit this bug report at https://bugs.php.net/bug.php?id=64023edit=1
Bug #64023 [Ver]: Overloading __toString() in SplFileInfo has no effect
Edit report at https://bugs.php.net/bug.php?id=64023edit=1
ID: 64023
Updated by: cataphr...@php.net
Reported by:php at lightning dot hu
Summary:Overloading __toString() in SplFileInfo has no
effect
Status: Verified
Type: Bug
Package:SPL related
Operating System: Linux
PHP Version:Irrelevant
Assigned To:cataphract
Block user comment: N
Private report: N
New Comment:
Fix: https://github.com/cataphract/php-src/compare/bug64023
Previous Comments:
[2013-01-18 15:24:39] php at lightning dot hu
Description:
When I overload the __toString() magic method in the SplFileInfo class or in
one
of it's derivatives it does not work if I concatenate the object with a string.
See the example for a simple demonstration.
Test script:
---
class A extends \SplFileInfo
{
public function __toString() {return ' -expected- ';}
}
$a = new A('/');
// Works
echo $a, $a-__toString(), $a-__toString() . '';
// Does not work - outputs parent::__toString()
echo $a . '';
Expected result:
-expected- -expected- -expected- /
--
Edit this bug report at https://bugs.php.net/bug.php?id=64023edit=1
Bug #46378 [Com]: IIS7 FastCGI - upload_tmp_dir not working correctly
Edit report at https://bugs.php.net/bug.php?id=46378edit=1 ID: 46378 Comment by: bigtrend at gmx dot us Reported by:tomas dot hlavacek at telekomaustria dot cz Summary:IIS7 FastCGI - upload_tmp_dir not working correctly Status: Not a bug Type: Bug Package:*Configuration Issues Operating System: Windows Server 2008 PHP Version:5.2.6 Block user comment: N Private report: N New Comment: In addition can add that the following permissions exactly are required for IIS_IUSRS to the PARENT folder: 1. Traverse folder/Execute file 2. List folder/ read data 3. Write attributes 4. Write extended attributes It is strange, but read attributes is not required and also create file/write data is not required as well. Hope it will help to protect your servers from the granting too many permissions for anonymous system accounts. Previous Comments: [2012-02-11 16:07:47] julientld at free dot fr Hi Pierre Joye, I have the same problem with an IIS 6 server with PHP 5.3.10 and FastCGI 1.5. I want to use a custom temp directory for php file uploads. If I set upload_tmp_dir=D:\Temp\ and set read and write acls for the user IUSR on the Temp directory, upload fails. As said by tomas, if we want the upload to function, the acls must also be set on the parent directory (D:\). Obviously, I do not want to give IUSR write acls to the whole partition !! For the moment, I have created a sub-directory for php uploads (D:\Temp\php\). I have given IUSR acls on \Temp and \php directories (not D:\) and uploads run fine now. But I would like to understand this phenomenon. If PHP can't write in a directory if the parent directory does not have also same acls, it is a specific behavior related to PHP or it is a Windows problem ? For me it is a bug. It has no sense to be forced to give acls also to the parent directory... Thanks for your clarifications ;) Julien [2008-10-24 13:04:27] paj...@php.net Not a bug bogus [2008-10-24 12:51:07] tomas dot hlavacek at telekomaustria dot cz Finally, I found the problem. Listing on E: must be allowed for IIS_IUSRS: E:\icacls e: e: NT AUTHORITY\SYSTEM:(OI)(CI)(F) BUILTIN\Administrators:(OI)(CI)(F) BUILTIN\IIS_IUSRS:(S,RD) [2008-10-24 12:20:01] tomas dot hlavacek at telekomaustria dot cz Description: Hello, in php.ini I have set upload_tmp_dir directive to e:\php5-uploadtemp. phpinfo() confirms, the directive is set to this value. But PHP is using C:\Windows\Temp for uploading files instead. This is confirmed by printing $_FILES['uploadedfile']['tmp_name'] in script. Server configuration: - Windows Server 2008 IIS 7 PHP 5.2.6 as FastCGI module with fastcgi.impersonate = 1 phpcgi.exe processes are running with Network Service privileges (same as w3wp.exe) and are impersonating to IUSR_xxx accounts (each customer has one). IUSR_xxx accounts are members of IIS_IUSRS group. Rights on folders: C:\icacls c:\windows\temp c:\windows\temp CREATOR OWNER:(OI)(CI)(IO)(F) NT AUTHORITY\SYSTEM:(OI)(CI)(F) BUILTIN\Administrators:(OI)(CI)(F) BUILTIN\Users:(CI)(S,WD,AD,X) BUILTIN\IIS_IUSRS:(OI)(CI)(M) C:\icacls e:\php5-uploadtemp e:\php5-uploadtemp BUILTIN\IIS_IUSRS:(OI)(CI)(M) BUILTIN\Administrators:(I)(OI)(CI)(F) NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F) Under Windows Server 2003, IIS6, PHP5 as CGI, with same configuration it was working. The rights should be ok, because I have also set session.save_path = e:\php5-sessiondata with same rights as on e:\php5-uploadtemp and this is working correctly. Reproduce code: --- ? ... print $_FILES['uploadedfile']['tmp_name']; ... ? Expected result: e:\php5-uploadtemp\php214E.tmp Actual result: -- C:\Windows\Temp\php214E.tmp -- Edit this bug report at https://bugs.php.net/bug.php?id=46378edit=1
Bug #46378 [Nab]: IIS7 FastCGI - upload_tmp_dir not working correctly
Edit report at https://bugs.php.net/bug.php?id=46378edit=1 ID: 46378 Updated by: paj...@php.net Reported by:tomas dot hlavacek at telekomaustria dot cz Summary:IIS7 FastCGI - upload_tmp_dir not working correctly Status: Not a bug Type: Bug Package:*Configuration Issues Operating System: Windows Server 2008 PHP Version:5.2.6 Block user comment: N Private report: N New Comment: You need read attributes on any parent directories. Previous Comments: [2013-01-19 16:45:26] bigtrend at gmx dot us In addition can add that the following permissions exactly are required for IIS_IUSRS to the PARENT folder: 1. Traverse folder/Execute file 2. List folder/ read data 3. Write attributes 4. Write extended attributes It is strange, but read attributes is not required and also create file/write data is not required as well. Hope it will help to protect your servers from the granting too many permissions for anonymous system accounts. [2012-02-11 16:07:47] julientld at free dot fr Hi Pierre Joye, I have the same problem with an IIS 6 server with PHP 5.3.10 and FastCGI 1.5. I want to use a custom temp directory for php file uploads. If I set upload_tmp_dir=D:\Temp\ and set read and write acls for the user IUSR on the Temp directory, upload fails. As said by tomas, if we want the upload to function, the acls must also be set on the parent directory (D:\). Obviously, I do not want to give IUSR write acls to the whole partition !! For the moment, I have created a sub-directory for php uploads (D:\Temp\php\). I have given IUSR acls on \Temp and \php directories (not D:\) and uploads run fine now. But I would like to understand this phenomenon. If PHP can't write in a directory if the parent directory does not have also same acls, it is a specific behavior related to PHP or it is a Windows problem ? For me it is a bug. It has no sense to be forced to give acls also to the parent directory... Thanks for your clarifications ;) Julien [2008-10-24 13:04:27] paj...@php.net Not a bug bogus [2008-10-24 12:51:07] tomas dot hlavacek at telekomaustria dot cz Finally, I found the problem. Listing on E: must be allowed for IIS_IUSRS: E:\icacls e: e: NT AUTHORITY\SYSTEM:(OI)(CI)(F) BUILTIN\Administrators:(OI)(CI)(F) BUILTIN\IIS_IUSRS:(S,RD) [2008-10-24 12:20:01] tomas dot hlavacek at telekomaustria dot cz Description: Hello, in php.ini I have set upload_tmp_dir directive to e:\php5-uploadtemp. phpinfo() confirms, the directive is set to this value. But PHP is using C:\Windows\Temp for uploading files instead. This is confirmed by printing $_FILES['uploadedfile']['tmp_name'] in script. Server configuration: - Windows Server 2008 IIS 7 PHP 5.2.6 as FastCGI module with fastcgi.impersonate = 1 phpcgi.exe processes are running with Network Service privileges (same as w3wp.exe) and are impersonating to IUSR_xxx accounts (each customer has one). IUSR_xxx accounts are members of IIS_IUSRS group. Rights on folders: C:\icacls c:\windows\temp c:\windows\temp CREATOR OWNER:(OI)(CI)(IO)(F) NT AUTHORITY\SYSTEM:(OI)(CI)(F) BUILTIN\Administrators:(OI)(CI)(F) BUILTIN\Users:(CI)(S,WD,AD,X) BUILTIN\IIS_IUSRS:(OI)(CI)(M) C:\icacls e:\php5-uploadtemp e:\php5-uploadtemp BUILTIN\IIS_IUSRS:(OI)(CI)(M) BUILTIN\Administrators:(I)(OI)(CI)(F) NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F) Under Windows Server 2003, IIS6, PHP5 as CGI, with same configuration it was working. The rights should be ok, because I have also set session.save_path = e:\php5-sessiondata with same rights as on e:\php5-uploadtemp and this is working correctly. Reproduce code: --- ? ... print $_FILES['uploadedfile']['tmp_name']; ... ? Expected result: e:\php5-uploadtemp\php214E.tmp Actual result: -- C:\Windows\Temp\php214E.tmp -- Edit this bug report at https://bugs.php.net/bug.php?id=46378edit=1
Bug #35105 [Com]: stream_set_timeout() has no effect on SSL stream
Edit report at https://bugs.php.net/bug.php?id=35105edit=1 ID: 35105 Comment by: bbroerman at bbroerman dot net Reported by:wckits at rit dot edu Summary:stream_set_timeout() has no effect on SSL stream Status: Closed Type: Bug Package:Streams related Operating System: SunOS 5.9 PHP Version:5CVS-2005-11-08 (snap) Assigned To:wez Block user comment: N Private report: N New Comment: I can still recreate this issue in the current 5.4 branch of PHP. Previous Comments: [2006-12-30 02:35:25] il...@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. [2005-11-08 21:31:18] sni...@php.net Assigned to the maintainer and author of streams. [2005-11-08 21:07:52] wckits at rit dot edu Ok, I figured it was just the copy in cvs being broken (some feature half done or some such), I wasn't trying to be a jerk. I had to add -mimpure-text to CFLAGS for the last few linking steps to fix the problem (otherwise I'd get about 16,000 lines of linker errors). Anyway: /u01/wckits/php5-200511081730/sapi/cli/php ?phpinfo()? phpinfo() PHP Version = 5.1.0RC5-dev System = SunOS myHostname 5.9 Generic_117171-13 sun4u Build Date = Nov 8 2005 14:52:09 The timeout problem still exists in php5-latest. [2005-11-08 20:14:32] sni...@php.net Guess what? The snapshot you tried IS the next stable release. So can you please tell us what didn't work with it? Just saying it wont build does not help much.. [2005-11-08 19:43:26] wckits at rit dot edu 'Latest' (php5-200511081330) just wont build on my system, same configuration as 5.0.5... Unless you are willing to cut and paste the example code into your own latest cvs build this may have to wait for the next stable release. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=35105 -- Edit this bug report at https://bugs.php.net/bug.php?id=35105edit=1
Bug #63957 [Com]: REQUEST_TIME_FLOAT too high
Edit report at https://bugs.php.net/bug.php?id=63957edit=1 ID: 63957 Comment by: bugzilla77 at gmail dot com Reported by:bugzilla77 at gmail dot com Summary:REQUEST_TIME_FLOAT too high Status: Wont fix Type: Bug Package:*Web Server problem Operating System: win32, apache module PHP Version:5.5.0alpha2 Block user comment: N Private report: N New Comment: Maybe PHP should set the $_SERVER['REQUEST_TIME_FLOAT'] value to MIN of apr_time_as_msec() , microtime(true) ??? Previous Comments: [2013-01-14 01:40:33] ahar...@php.net I can't reproduce this very reliably on either branch, so I don't think it's version specific as such. Changing $_SERVER['REQUEST_TIME_FLOAT'] to be microtime(true) on startup misses the point of what the server variable represents: it's what the Web server believes the request time to be, not when the PHP interpreter was invoked. If you want microtime(true), then set a variable to that at the top of your script. [2013-01-11 09:23:27] bugzilla77 at gmail dot com Why this problem is not found in PHP 5.4? [2013-01-11 09:21:20] bugzilla77 at gmail dot com Currently $_SERVER['REQUEST_TIME_FLOAT'] is useless in determining the time of generating web pages. I think that PHP should setting $_SERVER['REQUEST_TIME_FLOAT'] = microtime(true) on PHP's request handling. [2013-01-11 00:36:15] ahar...@php.net microtime() and $_SERVER['REQUEST_TIME_FLOAT'] use different mechanisms to get the time: microtime() calls gettimeofday() internally, whereas $_SERVER['REQUEST_TIME_FLOAT'] uses whatever method the SAPI provides to get the request time (for instance, the apache2handler SAPI calls apr_time_as_msec()). In practice, there are likely to be slight variances between the two methods, since they do different things. I don't see a sensible way we could change this without removing the semantics of $_SERVER['REQUEST_TIME_FLOAT'] actually being the server's request time (as opposed to just the startup time of PHP's request handling). Marking won't fix. [2013-01-10 10:28:44] bugzilla77 at gmail dot com Description: $_SERVER['REQUEST_TIME_FLOAT'] is greater than microtime(true) introduced in PHP 5.5 alpha (1-3) Test script: --- ?=$_SERVER['REQUEST_TIME_FLOAT']-microtime(true)? Expected result: positive float (PHP 5.4 OK) Actual result: -- negative float -- Edit this bug report at https://bugs.php.net/bug.php?id=63957edit=1
Bug #63957 [Com]: REQUEST_TIME_FLOAT too high
Edit report at https://bugs.php.net/bug.php?id=63957edit=1 ID: 63957 Comment by: bugzilla77 at gmail dot com Reported by:bugzilla77 at gmail dot com Summary:REQUEST_TIME_FLOAT too high Status: Wont fix Type: Bug Package:*Web Server problem Operating System: win32, apache module PHP Version:5.5.0alpha2 Block user comment: N Private report: N New Comment: Test script (fixed): ?=microtime(true)-$_SERVER['REQUEST_TIME_FLOAT']? but problem still the same Previous Comments: [2013-01-19 19:34:59] bugzilla77 at gmail dot com Maybe PHP should set the $_SERVER['REQUEST_TIME_FLOAT'] value to MIN of apr_time_as_msec() , microtime(true) ??? [2013-01-14 01:40:33] ahar...@php.net I can't reproduce this very reliably on either branch, so I don't think it's version specific as such. Changing $_SERVER['REQUEST_TIME_FLOAT'] to be microtime(true) on startup misses the point of what the server variable represents: it's what the Web server believes the request time to be, not when the PHP interpreter was invoked. If you want microtime(true), then set a variable to that at the top of your script. [2013-01-11 09:23:27] bugzilla77 at gmail dot com Why this problem is not found in PHP 5.4? [2013-01-11 09:21:20] bugzilla77 at gmail dot com Currently $_SERVER['REQUEST_TIME_FLOAT'] is useless in determining the time of generating web pages. I think that PHP should setting $_SERVER['REQUEST_TIME_FLOAT'] = microtime(true) on PHP's request handling. [2013-01-11 00:36:15] ahar...@php.net microtime() and $_SERVER['REQUEST_TIME_FLOAT'] use different mechanisms to get the time: microtime() calls gettimeofday() internally, whereas $_SERVER['REQUEST_TIME_FLOAT'] uses whatever method the SAPI provides to get the request time (for instance, the apache2handler SAPI calls apr_time_as_msec()). In practice, there are likely to be slight variances between the two methods, since they do different things. I don't see a sensible way we could change this without removing the semantics of $_SERVER['REQUEST_TIME_FLOAT'] actually being the server's request time (as opposed to just the startup time of PHP's request handling). Marking won't fix. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63957 -- Edit this bug report at https://bugs.php.net/bug.php?id=63957edit=1
Bug #49815 [NoF-Opn]: Problem with imagettfbbox
Edit report at https://bugs.php.net/bug.php?id=49815edit=1 ID: 49815 Updated by: phi...@php.net Reported by:christian dot roy at orange dot fr Summary:Problem with imagettfbbox -Status: No Feedback +Status: Open Type: Bug Package:GD related Operating System: Linux PHP Version:5.2.11 Assigned To:tabe Block user comment: N Private report: N Previous Comments: [2010-10-31 19:55:31] php at zunderer dot de It seems like this Bug is still present, both of the Testscripts provided by rasmus here and by ch+php in Bug #49600 produce correct results in PHP 5.0.5 and 5.2.5 but wrong results (x-coord of boundingbox shifted to left or right depending on Font and letter) on PHP 5.2.11 and 5.3.3 [2010-01-22 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2010-01-14 05:00:49] t...@php.net s/#45600/#49600/ [2010-01-14 04:59:07] t...@php.net rasmus, your observation is essential to understand this bug. fix for bug#45600 also seems to work well. With PHP_5_2 or trunk: bbox returned rectangle for a : -1 * 2 * 38 * 2 * 38 * -42 * -1 * -42 bbox returned rectangle for k : -1 * -1 * 42 * -1 * 42 * -62 * -1 * -62 bbox returned rectangle for j : -1 * 17 * 23 * 17 * 23 * -57 * -1 * -57 [2009-12-23 17:49:24] christian dot roy at orange dot fr Hi, Did you progress on this issue whicj sticks me to PHP 4. Thanks for your answer. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=49815 -- Edit this bug report at https://bugs.php.net/bug.php?id=49815edit=1
