Bug #51185 [Com]: Apache won't start after PHP 5.3.1 is installed
Edit report at https://bugs.php.net/bug.php?id=51185&edit=1 ID: 51185 Comment by: tony dot bedford at live dot co dot uk Reported by:randy at thehiringsurvey dot com Summary:Apache won't start after PHP 5.3.1 is installed Status: Bogus Type: Bug Package:Windows Installer Operating System: Windows 7 (x64) PHP Version:5.3.1 Block user comment: N Private report: N New Comment: I had the same problem with 5.3.5 on Windows 7 with Apache 2.2. Here's how I fixed it. When reinstalling Apache (as it failed to start after installing PHP) I got the error 'failed to load php5apache2_2.dll'. That of course was a clue. Checking httpd.conf I saw that the PHP installer had not set the PHP ini directory correctly (just empty quotes) and the path to the DLL was not added. I manually fixed these (I installed PHP to C:\PHP) and everything worked fine. By the way, based on comments above and elsewhere, I checked the path was set with correct case. Everything was in order so that wasn't the problem in this case. Hope this helps. Previous Comments: [2010-07-21 21:36:19] smacdav at gmail dot com You're right, of course. I was just realizing the issue and coming back to comment. That was silly of me. Sorry. [2010-07-21 21:30:27] paj...@php.net @smacdav at gmail dot com Your install is a mess then. php 5.2's sapi dll cannot work nor load with 5.3. Please ask php-setup or php-windows mailing for further supports (to any other reporters looking for help regarding the problem described here). [2010-07-21 21:26:58] smacdav at gmail dot com It's not the path variable; it's the dll file. I had exactly the same issue. I made sure my path had the right case and tried starting Apache: no dice. I had backed up my old php (from PHP 5.2.11) folder before installing PHP 5.3, so I tried copying php5apache2_2.dll from the backed up folder into the installation folder for PHP 5.3. Bingo! Apache started up and seems to be running fine. (Haven't tested and PHP 5.3 only features yet, though.) [2010-03-16 00:48:07] randy at thehiringsurvey dot com Two points: 1. I did not have to manually define any PATH variables when I installed PHP 5.2.13 after I had uninstalled 5.3.1. So the 5.2.13 installer is working where the 5.3.1 failed. 2. After I got PHP 5.2.13 running I installed PEAR. I ran into a non-fatal installation problem in PEAR as well. I found out that Windows 7 is case sensitive when referring to PATHs. PEAR was creating it's PATH variable with the directory in all upper, but the actual folder was all lower. That worked on earlier Windows, but not on 7. I don't know which Windows version they made that change in. But once I edited PEAR's PATH variables to match the actual directory case the non-fatal error was resolved. I suspect that PHP 5.3.1's installer is creating a path with the wrong case, based upon the assumption that Windows doesn't care. Can't prove it without uninstalling PHP, and I can't do that right now. [2010-03-16 00:41:04] paj...@php.net @cunobatis at bluewin dot ch that's a configuration problem. Adding the PHP directory to your PATH is a required step when you configure PHP with Apache. 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=51185 -- Edit this bug report at https://bugs.php.net/bug.php?id=51185&edit=1
[PHP-BUG] Bug #55504 [NEW]: Content-Type header is not parsed correctly on HTTP POST request
From:
Operating system: FreeBSD, Windows Server 2008
PHP version: 5.3.8
Package: Unknown/Other Function
Bug Type: Bug
Bug description:Content-Type header is not parsed correctly on HTTP POST request
Description:
HTTP POST is not parsed correctly when the "boundary" parameter of the
Content-Type HTTP header is not the last parameter on the line.
---
Guessing (might be wrong):
In the first case, PHP parses the ";" (and maybe also the rest of the
line)
after the boundary still as part of the boundary value. As a result, the
POST
DATA are not "understood" correctly. However, the following parts from RFC
1521
states clearly that ";" could not be part of the boundary:
tspecials := "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / "\" / <">
/ "/" / "[" / "]" / "?" / "="
; Must be in quoted-string,
; to use within parameter values
boundary := 0*69 bcharsnospace
bchars := bcharsnospace / " "
bcharsnospace :=DIGIT / ALPHA / "'" / "(" / ")" / "+" /"_"
/ "," / "-" / "." / "/" / ":" / "=" / "?"
Test script:
---
Consider the following call to a PHP script running on an Apache server.
Connection: Keep-Alive
Content-Type: multipart/form-data; boundary=BVoyv; charset=iso-8859-1
Accept: */*
Content-Length: 72
Host: example.com
Content-Disposition: form-data; name="data"
abc
--BVoyv--
And a corresponding PHP script:
In this case, the POST data are not seen on the PHP side, as shown on the
output:
Array
(
[Connection] => Keep-Alive
[Content-Type] => multipart/form-data; boundary=BVoyv;
charset=iso-8859-1
[Accept] => */*
[Content-Length] => 72
[Host] => example.com
)
Array
(
)
However, after changing order of parameters in the Content-Type header to:
"Content-Type: multipart/form-data; charset=iso-8859-1; boundary=BVoyv"
the script output is as expected (notify appearing of the [data] line):
Array
(
[Connection] => Keep-Alive
[Content-Type] => multipart/form-data; charset=iso-8859-1;
boundary=BVoyv
[Accept] => */*
[Content-Length] => 72
[Host] => example.com
)
Array
(
[data] => abc
)
Expected result:
Both cases should be equal to each other.
Actual result:
--
In the first case, the "data" parameter is not available to the script.
--
Edit bug report at https://bugs.php.net/bug.php?id=55504&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55504&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55504&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55504&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55504&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55504&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55504&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55504&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55504&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55504&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55504&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55504&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55504&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55504&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55504&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55504&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55504&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55504&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55504&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55504&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55504&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55504&r=mysqlcfg
[PHP-BUG] Req #55503 [NEW]: Extend __getTypes to support enumerations
From: datibbaw
Operating system: N/A
PHP version: 5.4SVN-2011-08-25 (snap)
Package: SOAP related
Bug Type: Feature/Change Request
Bug description:Extend __getTypes to support enumerations
Description:
The __getTypes() method helps to serve as a reference when writing SOAP
consumer
code, which is very useful.
However, enumeration types in WSDL aren't supported properly; they're
printed as
only the enumeration base type (which is usually 'string' in my case).
Test script:
---
Expected result:
string PersonaMemberType
{NEW,LIMITED,FREE,PAID_ACTIVE,TRIAL_ACTIVE,PAID_EXPIRED,TRIAL_EXPIRED}
Actual result:
--
string PersonaMemberType
--
Edit bug report at https://bugs.php.net/bug.php?id=55503&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55503&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55503&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55503&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55503&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55503&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55503&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55503&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55503&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55503&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55503&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55503&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55503&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55503&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55503&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55503&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55503&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55503&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55503&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55503&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55503&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55503&r=mysqlcfg
Bug #55497 [Com]: Credits URL Security ?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000
Edit report at https://bugs.php.net/bug.php?id=55497&edit=1 ID: 55497 Comment by: mhaisley at gmail dot com Reported by:mhaisley at gmail dot com Summary:Credits URL Security ?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C1 Status: Bogus Type: Bug Package:PHP options/info functions Operating System: Any PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Sorry, but it is a real issue. It should be disabled by default. Previous Comments: [2011-08-25 00:19:08] johan...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Attackers can easily brute force without knowing the version. But if youfear this makes things insecure you can set expose_php=Off in php.ini. [2011-08-24 02:35:55] mhaisley at gmail dot com Description: ?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C1 displays php credits, it also displays credits for all modules. This effectively makes it a security issue since it allows an attacker to scan for a specific vulnerable module and then exploit it. Test script: --- http://php.net/?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C1 Expected result: ?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C1 should be disabled by default, or display generic information only. The current behavior is unacceptable. Actual result: -- Specific information regarding installed modules is displayed. -- Edit this bug report at https://bugs.php.net/bug.php?id=55497&edit=1
Bug #55497 [Opn->Bgs]: Credits URL Security ?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000
Edit report at https://bugs.php.net/bug.php?id=55497&edit=1 ID: 55497 Updated by: johan...@php.net Reported by:mhaisley at gmail dot com Summary:Credits URL Security ?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C1 -Status: Open +Status: Bogus Type: Bug Package:PHP options/info functions Operating System: Any PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Attackers can easily brute force without knowing the version. But if youfear this makes things insecure you can set expose_php=Off in php.ini. Previous Comments: [2011-08-24 02:35:55] mhaisley at gmail dot com Description: ?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C1 displays php credits, it also displays credits for all modules. This effectively makes it a security issue since it allows an attacker to scan for a specific vulnerable module and then exploit it. Test script: --- http://php.net/?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C1 Expected result: ?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C1 should be disabled by default, or display generic information only. The current behavior is unacceptable. Actual result: -- Specific information regarding installed modules is displayed. -- Edit this bug report at https://bugs.php.net/bug.php?id=55497&edit=1
Bug #55468 [Fbk->Opn]: UnexpectedValueException caused by an unreleased handle or something
Edit report at https://bugs.php.net/bug.php?id=55468&edit=1 ID: 55468 User updated by:php at tracking-celebs dot info Reported by:php at tracking-celebs dot info Summary:UnexpectedValueException caused by an unreleased handle or something -Status: Feedback +Status: Open Type: Bug Package:SPL related Operating System: win32 PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Permissions aren't a problem here. Besides, the (first, $foo) folder actually gets removed (as indicated by the output of file_exists), that's not the problem. And the problem comes before trying to remove the other one ($folder), it is that when calling the iterator (on that parent), because it'll somehow still "hold"/find a reference to the now non-existing/freshly removed folder, thus causing the exception... Previous Comments: [2011-08-22 13:58:59] ka...@php.net At first glance it doesn't looks like a problem in PHP itself but more that you haven't granted yourself the permission to delete the folder on Windows. Have you tried to chmod or similar it? [2011-08-20 19:56:20] php at tracking-celebs dot info Description: After using a DirectoryIterator on a folder, then removing said folder, using another iterator to iterate on the folder's parent will see/try to look into the removed folder. This only happens on Windows, so maybe due to a cache somewhere or something. Tried adding a clearstatcache() just in case, but that doesn't change anything. FYI if you replace the first DirectoryIterator by a: opendir($foo); without calling closedir() you get the same error, hence why I suggested it might be a handle not (properly) released or something. Test script: --- https://bugs.php.net/bug.php?id=55468&edit=1
Bug #55103 [Com]: Interfaces avoids Classes to exist
Edit report at https://bugs.php.net/bug.php?id=55103&edit=1
ID: 55103
Comment by: imaggens at gmail dot com
Reported by:imaggens at gmail dot com
Summary:Interfaces avoids Classes to exist
Status: Open
Type: Bug
Package:Class/Object related
Operating System: Windows 7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Sorry, I don't know if it's allowed to do that, but is there any position about
this bug report?
Previous Comments:
[2011-07-02 10:11:05] imaggens at gmail dot com
Sorry about the code, it was my mistake.
The correct code for Code Sample #2 is: http://codepad.org/eIUJWp56
And as requested, the code of other file:
getMessage();
}
?>
I tried without the try...catch() and with it and, in both cases the error
remains.
[2011-07-01 16:26:46] f...@php.net
It seems to me your 2 code samples are identical, just one has output attached.
Where's the interface?
Please provide a *complete* sample, i.e. if your including one file make clear
what's in both files, the one having a call to "require" and the one being
required
[2011-07-01 10:07:08] imaggens at gmail dot com
Description:
First at all, one consideration about one of the informations provided in this
form is the PHP version. I'm not using 5.3.6. I'm using 5.3.3, which is not
listed. I f I chose "earlier", the form won't submit.
I can be wrong, but I think this bug is not fixed in newer versions, because
it's not a very common use.
The whole thing is, when interfaces and classes are in the same namespace AND
in same file, the 'implements' breaks the execution of the 'extends'. See Code
#1
As expected I can see "Message from Second Class", without quotes.
But if I add a interface (see Code #2) I get a Fatal Error: "Class 'Test\Zero'
not found", when it could be expected the same result as before.
But why this is important, if the best practices are to develop by following an
organized structure, with each class/interface in its own file?
The thing is, when DEVELOPING, this kind of organization is very useful, but if
the code produced during development stage is a little library, if all the
classes and interfaces are coded in one single file, only one call to
require_once is needed, and the code execution is three times faster than when
using an autoloader resource.
Note about CodePad's codes: I'd only saved the lines of code in this site, they
don't work from it, due PHP versions. But all the tests I made was in machine
with the configurations posted.
Test script:
---
[ Code #1 ]
http://codepad.org/pDOAiqBa
[ Code #2 ]
http://codepad.org/a42WgIT3
Expected result:
As said in Bug's Description, "Message from Second Class", witout quotes.
Actual result:
--
With the first code, I can see the expected result.
With the second code, as I said, I see a Fatal Error. If the stack traces
helps, here is it:
Fatal error: Class 'Test\Test\Zero' not found in C:\root\Test\Library.php on
line 5
Call Stack
# TimeMemory FunctionLocation
1 0.0004 326896 {main}( ) ..\index.php:0
2 0.0018 334024 require_once( 'C:\root\Test\Framework.php' )
..\index.php:3
Dump $_GET
Dump $_POST
--
Edit this bug report at https://bugs.php.net/bug.php?id=55103&edit=1
Req #50029 [Com]: Weird invoke issue on class as property
Edit report at https://bugs.php.net/bug.php?id=50029&edit=1
ID: 50029
Comment by: marc dot gray at gmail dot com
Reported by:marc dot gray at gmail dot com
Summary:Weird invoke issue on class as property
Status: Analyzed
Type: Feature/Change Request
Package:Class/Object related
Operating System: Ubuntu 9.04
PHP Version:5.3.0
Block user comment: N
Private report: N
New Comment:
I've been thinking about this since the same issue appears to exist with
assigning a closure to a static
variable too (tested in 5.3.5, 5.3.8 & 5.4alpha3.
//--
// Create a very basic static class
class closureProperty {
static public $myClosure;
}
// Assign a closure to a class property
closureProperty::$myClosure = function() { echo('Hi'); };
// Fatal error: Function name must be a string
closureProperty::$myClosure();
// Works as expected
$safeCopy = closureProperty::$myClosure;
$safeCopy();
//--
I can understand why it happens with dynamic properties, apparently you can
have a variable and function named
identically? I admit I've never tried.
I would propose making identically named variables and functions as deprecated
(does anyone who's any good
actually do that? Talk about poor readability...) and implement a collision
warning in the mean time. I would
also suggest this makes less sense in a static case (due to $ variable prefix)
than it did in a dynamic case,
and should be changed.
If nothing else, some discussion on the matter would be lovely.
Thoughts?
Previous Comments:
[2011-02-07 22:36:54] dhaarbrink at gmail dot com
@bkarwin: The control would be passed to __call(), since there is no way to
disambiguate. __call() would then be responsible for deciding what to do.
I have to agree with Matthew, it's a huge WTF. It just doesn't work as it
should (that's beyond what is expected).
[2010-04-07 20:22:38] bkar...@php.net
How would Matthew's suggestion work if a magic __call() method is present?
class b {
private $x;
public function __call($method, $args) { echo "Called\n"; }
function __construct() {
$this->x = new a();
$this->x();
}
}
Should this execute $this->__call("x") and output "Called" or should it execute
$this->x->__invoke() and output "Invoked"?
[2010-04-07 14:52:19] ballouc at gmail dot com
I'm in agreement with the Matt's last suggestion. I believe that errors should
only be raised in the event of a collision. The current implementation of the
__invoke method, IMO, would not perform as a third party developer would have
anticipated. My personal choice would be to throw an E_WARNING for collisions
as I have seen ~E_NOTICE far too often.
Personally, I believe that an __invoke collision occurring would be more
indicative of a developer error than intentional. If this is not the case, and
you find many people readily anticipate having both foo() and __invoke called
in succession, this would need to be discussed further as that is also a viable
option.
[2010-04-07 13:41:14] weierophin...@php.net
I can understand wanting to ensure that collisions between existing methods and
invokable properties don't occur, but when there aren't any collisions, it
doesn't make sense.
I'd argue that the following behavior should be implemented:
* If no matching method exists, simply allow invoking.
* If a matching method exists, call the method, and raise either an E_NOTICE or
E_WARNING indicating the collision.
Right now, it's a fairly big WTF moment -- you expect it to work, and instead
get an E_FATAL. Copying to a temporary variable is code clutter, particularly
when you know the object is invokable.
[2009-11-02 15:58:23] ka...@php.net
There was lots of discussion about this, because it could override class
methods like:
class Test {
private $closure;
public function __construct() {
$this->closure = function() {
echo 'Hello World';
};
}
public function closure() {
echo 'Hello PHP';
}
public function call() {
$this->closure();
}
}
$test = new Test;
// Call Test::$closure or Test::closure() now?
$test->call();
What you need to do is to copy the instance into a variable like:
$closoure = $this->closure;
$closure();
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=50029
--
Edit this bu
Bug #53140 [Com]: PHP-CGI (FastCGI IIS) crashes when creating DOTNET instance every second time
Edit report at https://bugs.php.net/bug.php?id=53140&edit=1
ID: 53140
Comment by: johnphayes at gmail dot com
Reported by:jeyb88 at gmail dot com
Summary:PHP-CGI (FastCGI IIS) crashes when creating DOTNET
instance every second time
Status: Open
Type: Bug
Package:COM related
Operating System: XP, Vista, Win 7,Win Server 2008
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
Here is the Application Event log entry in Windows Server 2003 when this crash
occurs in my test case above:
Source: .NET Runtime 2.0 Error
Description:
Faulting application httpd.exe, version 2.2.19.0, stamp 4dd6eda8, faulting
module
php5ts.dll, version 5.2.17.17, stamp 4d25fb49, debug? 0, fault address
0x000ea66d.
This source is a little odd, because I have .NET 4.0 Runtime installed. Note
that although I have PHP 5.2.17 installed at the moment, I have experienced
this
with 5.3 as well.
Previous Comments:
[2011-08-24 16:23:21] johnphayes at gmail dot com
Can this bug's summary be edited to remove "(FastCGI IIS)?" My comment above
shows
that it can be reproduced under Apache as an Apache handler as well.
[2011-08-24 16:18:58] johnphayes at gmail dot com
This error only appears to happen when the offending code is run from a web
server. If I run the offending code directly from the CLI, php never crashes.
If
I run the same code through Apache (via a cURL request), Apache crashes every
other time. My configuration is:
* Windows Server 2003 R2
* Apache 2.2
* PHP 5.3 configured as an Apache handler, not under FastCGI (see
http://www.php.net/manual/en/install.windows.apache2.php)
* The following 2 files:
--
--
http://localhost/testCrash.php';
$client = curl_init();
curl_setopt_array($client, array(
CURLOPT_FRESH_CONNECT => TRUE,
CURLOPT_RETURNTRANSFER => TRUE,
CURLOPT_URL => $endPoint
));
$response = curl_exec($client);
curl_close($client);
var_dump($response);
echo 'done';
?>
--
Use case #1 - run locally, we get no crash:
Steps:
1. Open command prompt
2. Execute:
php.exe testCrash.php
3. Observe that we get the expected resulting output:
success
4. Repeat step 2. Expected result will always be obtained.
Use case #2 - run through the web server, we get the crash:
Steps:
1. Open command prompt
2. Execute:
php.exe testCrashClient.php
3. Observe that we get the expected resulting output:
string(7) "success"
done
4. Repeat step 2.
5. Now observe that we get an error:
bool(false)
done
6. Repeat step 2.
7. Expected successful output is obtained again.
Repeating step 2 will cause the crash every other time. When the crash occurs,
apache's error log gets:
--
[Wed Aug 24 12:13:25 2011] [notice] Parent: child process exited with status 0 -
- Restarting.
[Wed Aug 24 12:13:25 2011] [notice] Apache/2.2.19 (Win32) PHP/5.2.17 configured
-- resuming normal operations
[Wed Aug 24 12:13:25 2011] [notice] Server built: May 20 2011 17:39:35
[Wed Aug 24 12:13:25 2011] [notice] Parent: Created child process 2624
[Wed Aug 24 12:13:26 2011] [notice] Child 2624: Child process is running
[Wed Aug 24 12:13:26 2011] [notice] Child 2624: Acquired the start mutex.
[Wed Aug 24 12:13:26 2011] [notice] Child 2624: Starting 64 worker threads.
[Wed Aug 24 12:13:26 2011] [notice] Child 2624: Starting thread to listen on
port 80.
--
[2010-11-16 23:40:13] davidphp at limegreensocks dot com
It appears this behavior was intentionally introduced by WEZ back in 2003.
http://svn.php.net/viewvc/php/php-src/trunk/ext/com_dotnet/com_dotnet.c?r1=137794&r2=146718
I don't know what problem he was trying to fix back then, so I'm not sure of
the implications of adding these two lines back. But if you are using fastcgi,
then jeyb88 is absolutely correct: this will crash every other time the code is
run.
My repro is even simpler than jeyb88's. I don't even have to call any methods
on the .net object. I have a 1 line php file that calls the "new" against my
.net class:
The constructor for my .net class is empty:
[ComVisible(true),
ClassInterface(ClassInterfaceType.None),
Guid("53C74B01-EC09-45a4-A741-42727858B2A1")]
public class Impersonation
{
public Impersonation()
{
}
// more code follows
When I first browse to the page, it (correctly) shows nothing. Then I hit
refresh, and I get the "FastCGI process exited unexpectedly" 0xc005. If I
hit refresh again, the page again (correctly) shows nothing, next time, fastcgi
AVs again.
I am using php 5.3.3, Windows Server 2003, and I have tried both .Net 2.
Bug #53140 [Com]: PHP-CGI (FastCGI IIS) crashes when creating DOTNET instance every second time
Edit report at https://bugs.php.net/bug.php?id=53140&edit=1
ID: 53140
Comment by: johnphayes at gmail dot com
Reported by:jeyb88 at gmail dot com
Summary:PHP-CGI (FastCGI IIS) crashes when creating DOTNET
instance every second time
Status: Open
Type: Bug
Package:COM related
Operating System: XP, Vista, Win 7,Win Server 2008
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
Can this bug's summary be edited to remove "(FastCGI IIS)?" My comment above
shows
that it can be reproduced under Apache as an Apache handler as well.
Previous Comments:
[2011-08-24 16:18:58] johnphayes at gmail dot com
This error only appears to happen when the offending code is run from a web
server. If I run the offending code directly from the CLI, php never crashes.
If
I run the same code through Apache (via a cURL request), Apache crashes every
other time. My configuration is:
* Windows Server 2003 R2
* Apache 2.2
* PHP 5.3 configured as an Apache handler, not under FastCGI (see
http://www.php.net/manual/en/install.windows.apache2.php)
* The following 2 files:
--
--
http://localhost/testCrash.php';
$client = curl_init();
curl_setopt_array($client, array(
CURLOPT_FRESH_CONNECT => TRUE,
CURLOPT_RETURNTRANSFER => TRUE,
CURLOPT_URL => $endPoint
));
$response = curl_exec($client);
curl_close($client);
var_dump($response);
echo 'done';
?>
--
Use case #1 - run locally, we get no crash:
Steps:
1. Open command prompt
2. Execute:
php.exe testCrash.php
3. Observe that we get the expected resulting output:
success
4. Repeat step 2. Expected result will always be obtained.
Use case #2 - run through the web server, we get the crash:
Steps:
1. Open command prompt
2. Execute:
php.exe testCrashClient.php
3. Observe that we get the expected resulting output:
string(7) "success"
done
4. Repeat step 2.
5. Now observe that we get an error:
bool(false)
done
6. Repeat step 2.
7. Expected successful output is obtained again.
Repeating step 2 will cause the crash every other time. When the crash occurs,
apache's error log gets:
--
[Wed Aug 24 12:13:25 2011] [notice] Parent: child process exited with status 0 -
- Restarting.
[Wed Aug 24 12:13:25 2011] [notice] Apache/2.2.19 (Win32) PHP/5.2.17 configured
-- resuming normal operations
[Wed Aug 24 12:13:25 2011] [notice] Server built: May 20 2011 17:39:35
[Wed Aug 24 12:13:25 2011] [notice] Parent: Created child process 2624
[Wed Aug 24 12:13:26 2011] [notice] Child 2624: Child process is running
[Wed Aug 24 12:13:26 2011] [notice] Child 2624: Acquired the start mutex.
[Wed Aug 24 12:13:26 2011] [notice] Child 2624: Starting 64 worker threads.
[Wed Aug 24 12:13:26 2011] [notice] Child 2624: Starting thread to listen on
port 80.
--
[2010-11-16 23:40:13] davidphp at limegreensocks dot com
It appears this behavior was intentionally introduced by WEZ back in 2003.
http://svn.php.net/viewvc/php/php-src/trunk/ext/com_dotnet/com_dotnet.c?r1=137794&r2=146718
I don't know what problem he was trying to fix back then, so I'm not sure of
the implications of adding these two lines back. But if you are using fastcgi,
then jeyb88 is absolutely correct: this will crash every other time the code is
run.
My repro is even simpler than jeyb88's. I don't even have to call any methods
on the .net object. I have a 1 line php file that calls the "new" against my
.net class:
The constructor for my .net class is empty:
[ComVisible(true),
ClassInterface(ClassInterfaceType.None),
Guid("53C74B01-EC09-45a4-A741-42727858B2A1")]
public class Impersonation
{
public Impersonation()
{
}
// more code follows
When I first browse to the page, it (correctly) shows nothing. Then I hit
refresh, and I get the "FastCGI process exited unexpectedly" 0xc005. If I
hit refresh again, the page again (correctly) shows nothing, next time, fastcgi
AVs again.
I am using php 5.3.3, Windows Server 2003, and I have tried both .Net 2.0 and
.Net 3.5.
The pattern here is easily reproducible, causes an unrecoverable access
violation, and there is no workaround. A fix here would be greatly appreciated.
[2010-10-22 15:59:15] jeyb88 at gmail dot com
Description:
The php-cgi.exe will crash after every second refresh when I make an instance
of the DOTNET class. The Website is hostet via IIS 7 and PHP is configured as
FastCGI module. When I configure PHP on IIS as CGI module everything works
fine, but I can not do without FastCGI. I have made a change in the
com_dot
Bug #53140 [Com]: PHP-CGI (FastCGI IIS) crashes when creating DOTNET instance every second time
Edit report at https://bugs.php.net/bug.php?id=53140&edit=1
ID: 53140
Comment by: johnphayes at gmail dot com
Reported by:jeyb88 at gmail dot com
Summary:PHP-CGI (FastCGI IIS) crashes when creating DOTNET
instance every second time
Status: Open
Type: Bug
Package:COM related
Operating System: XP, Vista, Win 7,Win Server 2008
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
This error only appears to happen when the offending code is run from a web
server. If I run the offending code directly from the CLI, php never crashes.
If
I run the same code through Apache (via a cURL request), Apache crashes every
other time. My configuration is:
* Windows Server 2003 R2
* Apache 2.2
* PHP 5.3 configured as an Apache handler, not under FastCGI (see
http://www.php.net/manual/en/install.windows.apache2.php)
* The following 2 files:
--
--
http://localhost/testCrash.php';
$client = curl_init();
curl_setopt_array($client, array(
CURLOPT_FRESH_CONNECT => TRUE,
CURLOPT_RETURNTRANSFER => TRUE,
CURLOPT_URL => $endPoint
));
$response = curl_exec($client);
curl_close($client);
var_dump($response);
echo 'done';
?>
--
Use case #1 - run locally, we get no crash:
Steps:
1. Open command prompt
2. Execute:
php.exe testCrash.php
3. Observe that we get the expected resulting output:
success
4. Repeat step 2. Expected result will always be obtained.
Use case #2 - run through the web server, we get the crash:
Steps:
1. Open command prompt
2. Execute:
php.exe testCrashClient.php
3. Observe that we get the expected resulting output:
string(7) "success"
done
4. Repeat step 2.
5. Now observe that we get an error:
bool(false)
done
6. Repeat step 2.
7. Expected successful output is obtained again.
Repeating step 2 will cause the crash every other time. When the crash occurs,
apache's error log gets:
--
[Wed Aug 24 12:13:25 2011] [notice] Parent: child process exited with status 0 -
- Restarting.
[Wed Aug 24 12:13:25 2011] [notice] Apache/2.2.19 (Win32) PHP/5.2.17 configured
-- resuming normal operations
[Wed Aug 24 12:13:25 2011] [notice] Server built: May 20 2011 17:39:35
[Wed Aug 24 12:13:25 2011] [notice] Parent: Created child process 2624
[Wed Aug 24 12:13:26 2011] [notice] Child 2624: Child process is running
[Wed Aug 24 12:13:26 2011] [notice] Child 2624: Acquired the start mutex.
[Wed Aug 24 12:13:26 2011] [notice] Child 2624: Starting 64 worker threads.
[Wed Aug 24 12:13:26 2011] [notice] Child 2624: Starting thread to listen on
port 80.
--
Previous Comments:
[2010-11-16 23:40:13] davidphp at limegreensocks dot com
It appears this behavior was intentionally introduced by WEZ back in 2003.
http://svn.php.net/viewvc/php/php-src/trunk/ext/com_dotnet/com_dotnet.c?r1=137794&r2=146718
I don't know what problem he was trying to fix back then, so I'm not sure of
the implications of adding these two lines back. But if you are using fastcgi,
then jeyb88 is absolutely correct: this will crash every other time the code is
run.
My repro is even simpler than jeyb88's. I don't even have to call any methods
on the .net object. I have a 1 line php file that calls the "new" against my
.net class:
The constructor for my .net class is empty:
[ComVisible(true),
ClassInterface(ClassInterfaceType.None),
Guid("53C74B01-EC09-45a4-A741-42727858B2A1")]
public class Impersonation
{
public Impersonation()
{
}
// more code follows
When I first browse to the page, it (correctly) shows nothing. Then I hit
refresh, and I get the "FastCGI process exited unexpectedly" 0xc005. If I
hit refresh again, the page again (correctly) shows nothing, next time, fastcgi
AVs again.
I am using php 5.3.3, Windows Server 2003, and I have tried both .Net 2.0 and
.Net 3.5.
The pattern here is easily reproducible, causes an unrecoverable access
violation, and there is no workaround. A fix here would be greatly appreciated.
[2010-10-22 15:59:15] jeyb88 at gmail dot com
Description:
The php-cgi.exe will crash after every second refresh when I make an instance
of the DOTNET class. The Website is hostet via IIS 7 and PHP is configured as
FastCGI module. When I configure PHP on IIS as CGI module everything works
fine, but I can not do without FastCGI. I have made a change in the
com_dotnet.c file in function php_com_dotnet_rshutdown. The variable called
stuff from type dotnet_runtime_stuff will not be released like in the function
php_com_dotnet_mshutdown. So I have added this two lines to the function
php_com_dotnet_rshutdown:
free(stuff);
COMG(dotnet_run
Req #55493 [Com]: Superglobal variable variables with ${expression} in non-global scope
Edit report at https://bugs.php.net/bug.php?id=55493&edit=1
ID: 55493
Comment by: vovan-ve at yandex dot ru
Reported by:vovan-ve at yandex dot ru
Summary:Superglobal variable variables with ${expression} in
non-global scope
Status: Assigned
Type: Feature/Change Request
Package:Variables related
Operating System: Windows XP SP3
PHP Version:5.3.7
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
Programmers, who use variable variable, dooms themself to slowdown performance
at any way due to calculation of the expressions. They won't see the
difference, I think.
Previous Comments:
[2011-08-24 14:00:39] vovan-ve at yandex dot ru
But what about SUPERglobal? In fact they are almost superglobal :)
[2011-08-24 13:54:34] larue...@php.net
+1 for dmitry
[2011-08-24 13:04:22] dmi...@php.net
ZE decides if a variable have to be fetched from the global scope at compile
time checking predefined list of super-global variables.
The variable fetching by name (e.g. $$name) is always done from local scope.
Of course it's possible to extend executor to check for list of super-global
variables at run-time, but it'll introduce significant slowdown for each fetch
by name. I really don't like it.
[2011-08-24 12:50:02] larue...@php.net
In this case, I make a patch for this, and the test result can be found on:
http://pastebin.com/6pTuLEer
[2011-08-24 12:48:57] larue...@php.net
The following patch has been added/updated:
Patch Name: bug55493.patch
Revision: 1314190137
URL:
https://bugs.php.net/patch-display.php?bug=55493&patch=bug55493.patch&revision=1314190137
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=55493
--
Edit this bug report at https://bugs.php.net/bug.php?id=55493&edit=1
Req #55493 [Com]: Superglobal variable variables with ${expression} in non-global scope
Edit report at https://bugs.php.net/bug.php?id=55493&edit=1
ID: 55493
Comment by: vovan-ve at yandex dot ru
Reported by:vovan-ve at yandex dot ru
Summary:Superglobal variable variables with ${expression} in
non-global scope
Status: Assigned
Type: Feature/Change Request
Package:Variables related
Operating System: Windows XP SP3
PHP Version:5.3.7
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
But what about SUPERglobal? In fact they are almost superglobal :)
Previous Comments:
[2011-08-24 13:54:34] larue...@php.net
+1 for dmitry
[2011-08-24 13:04:22] dmi...@php.net
ZE decides if a variable have to be fetched from the global scope at compile
time checking predefined list of super-global variables.
The variable fetching by name (e.g. $$name) is always done from local scope.
Of course it's possible to extend executor to check for list of super-global
variables at run-time, but it'll introduce significant slowdown for each fetch
by name. I really don't like it.
[2011-08-24 12:50:02] larue...@php.net
In this case, I make a patch for this, and the test result can be found on:
http://pastebin.com/6pTuLEer
[2011-08-24 12:48:57] larue...@php.net
The following patch has been added/updated:
Patch Name: bug55493.patch
Revision: 1314190137
URL:
https://bugs.php.net/patch-display.php?bug=55493&patch=bug55493.patch&revision=1314190137
[2011-08-24 10:21:23] vovan-ve at yandex dot ru
When I tried to obfuscate a part of code I was surprised by this strange
behariour. Of course, current implementation is correct on the one hand. But on
the other hand the situation looks funny: this way is allowad, and this too,
but this is not.
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=55493
--
Edit this bug report at https://bugs.php.net/bug.php?id=55493&edit=1
Req #55493 [Asn]: Superglobal variable variables with ${expression} in non-global scope
Edit report at https://bugs.php.net/bug.php?id=55493&edit=1
ID: 55493
Updated by: larue...@php.net
Reported by:vovan-ve at yandex dot ru
Summary:Superglobal variable variables with ${expression} in
non-global scope
Status: Assigned
Type: Feature/Change Request
Package:Variables related
Operating System: Windows XP SP3
PHP Version:5.3.7
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
+1 for dmitry
Previous Comments:
[2011-08-24 13:04:22] dmi...@php.net
ZE decides if a variable have to be fetched from the global scope at compile
time checking predefined list of super-global variables.
The variable fetching by name (e.g. $$name) is always done from local scope.
Of course it's possible to extend executor to check for list of super-global
variables at run-time, but it'll introduce significant slowdown for each fetch
by name. I really don't like it.
[2011-08-24 12:50:02] larue...@php.net
In this case, I make a patch for this, and the test result can be found on:
http://pastebin.com/6pTuLEer
[2011-08-24 12:48:57] larue...@php.net
The following patch has been added/updated:
Patch Name: bug55493.patch
Revision: 1314190137
URL:
https://bugs.php.net/patch-display.php?bug=55493&patch=bug55493.patch&revision=1314190137
[2011-08-24 10:21:23] vovan-ve at yandex dot ru
When I tried to obfuscate a part of code I was surprised by this strange
behariour. Of course, current implementation is correct on the one hand. But on
the other hand the situation looks funny: this way is allowad, and this too,
but this is not.
[2011-08-24 04:11:14] larue...@php.net
sure, it can be fixed by decide target symbol table again in the execution time
for not const OPs,
but I don't think this is really necessary . :)
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=55493
--
Edit this bug report at https://bugs.php.net/bug.php?id=55493&edit=1
Req #55493 [Asn]: Superglobal variable variables with ${expression} in non-global scope
Edit report at https://bugs.php.net/bug.php?id=55493&edit=1
ID: 55493
Updated by: dmi...@php.net
Reported by:vovan-ve at yandex dot ru
Summary:Superglobal variable variables with ${expression} in
non-global scope
Status: Assigned
Type: Feature/Change Request
Package:Variables related
Operating System: Windows XP SP3
PHP Version:5.3.7
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
ZE decides if a variable have to be fetched from the global scope at compile
time checking predefined list of super-global variables.
The variable fetching by name (e.g. $$name) is always done from local scope.
Of course it's possible to extend executor to check for list of super-global
variables at run-time, but it'll introduce significant slowdown for each fetch
by name. I really don't like it.
Previous Comments:
[2011-08-24 12:50:02] larue...@php.net
In this case, I make a patch for this, and the test result can be found on:
http://pastebin.com/6pTuLEer
[2011-08-24 12:48:57] larue...@php.net
The following patch has been added/updated:
Patch Name: bug55493.patch
Revision: 1314190137
URL:
https://bugs.php.net/patch-display.php?bug=55493&patch=bug55493.patch&revision=1314190137
[2011-08-24 10:21:23] vovan-ve at yandex dot ru
When I tried to obfuscate a part of code I was surprised by this strange
behariour. Of course, current implementation is correct on the one hand. But on
the other hand the situation looks funny: this way is allowad, and this too,
but this is not.
[2011-08-24 04:11:14] larue...@php.net
sure, it can be fixed by decide target symbol table again in the execution time
for not const OPs,
but I don't think this is really necessary . :)
[2011-08-23 18:16:12] ka...@php.net
This still seems a little strange that we cannot pick the correct symbol table
at compile time, all it should need would be a check to see if the compiled
value is matching one thats a super global.
I remember to have encountered something similar a while back, which I'm not
sure if I reported or not, but def. something we should look into at some point.
Dmitry, can you clarify this?
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=55493
--
Edit this bug report at https://bugs.php.net/bug.php?id=55493&edit=1
Req #55493 [Com]: Superglobal variable variables with ${expression} in non-global scope
Edit report at https://bugs.php.net/bug.php?id=55493&edit=1
ID: 55493
Comment by: larue...@php.net
Reported by:vovan-ve at yandex dot ru
Summary:Superglobal variable variables with ${expression} in
non-global scope
Status: Assigned
Type: Feature/Change Request
Package:Variables related
Operating System: Windows XP SP3
PHP Version:5.3.7
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
In this case, I make a patch for this, and the test result can be found on:
http://pastebin.com/6pTuLEer
Previous Comments:
[2011-08-24 12:48:57] larue...@php.net
The following patch has been added/updated:
Patch Name: bug55493.patch
Revision: 1314190137
URL:
https://bugs.php.net/patch-display.php?bug=55493&patch=bug55493.patch&revision=1314190137
[2011-08-24 10:21:23] vovan-ve at yandex dot ru
When I tried to obfuscate a part of code I was surprised by this strange
behariour. Of course, current implementation is correct on the one hand. But on
the other hand the situation looks funny: this way is allowad, and this too,
but this is not.
[2011-08-24 04:11:14] larue...@php.net
sure, it can be fixed by decide target symbol table again in the execution time
for not const OPs,
but I don't think this is really necessary . :)
[2011-08-23 18:16:12] ka...@php.net
This still seems a little strange that we cannot pick the correct symbol table
at compile time, all it should need would be a check to see if the compiled
value is matching one thats a super global.
I remember to have encountered something similar a while back, which I'm not
sure if I reported or not, but def. something we should look into at some point.
Dmitry, can you clarify this?
[2011-08-23 16:49:00] larue...@php.net
As I said, this is a limitation of PHP design, so mark as won't fix.
Thank you for your interest in PHP.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=55493
--
Edit this bug report at https://bugs.php.net/bug.php?id=55493&edit=1
Req #55493 [PATCH]: Superglobal variable variables with ${expression} in non-global scope
Edit report at https://bugs.php.net/bug.php?id=55493&edit=1
ID: 55493
Patch added by: larue...@php.net
Reported by:vovan-ve at yandex dot ru
Summary:Superglobal variable variables with ${expression} in
non-global scope
Status: Assigned
Type: Feature/Change Request
Package:Variables related
Operating System: Windows XP SP3
PHP Version:5.3.7
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug55493.patch
Revision: 1314190137
URL:
https://bugs.php.net/patch-display.php?bug=55493&patch=bug55493.patch&revision=1314190137
Previous Comments:
[2011-08-24 10:21:23] vovan-ve at yandex dot ru
When I tried to obfuscate a part of code I was surprised by this strange
behariour. Of course, current implementation is correct on the one hand. But on
the other hand the situation looks funny: this way is allowad, and this too,
but this is not.
[2011-08-24 04:11:14] larue...@php.net
sure, it can be fixed by decide target symbol table again in the execution time
for not const OPs,
but I don't think this is really necessary . :)
[2011-08-23 18:16:12] ka...@php.net
This still seems a little strange that we cannot pick the correct symbol table
at compile time, all it should need would be a check to see if the compiled
value is matching one thats a super global.
I remember to have encountered something similar a while back, which I'm not
sure if I reported or not, but def. something we should look into at some point.
Dmitry, can you clarify this?
[2011-08-23 16:49:00] larue...@php.net
As I said, this is a limitation of PHP design, so mark as won't fix.
Thank you for your interest in PHP.
[2011-08-23 16:22:46] larue...@php.net
when fetching a variable, the target symbol table is decided in compiling time,
for the script above, in compiling time, only const string "_SERVER" can be
took consider as a SUPERVAR and assign the global symbol table as
target_symbol_table.
the others `varname` only can be see in execution time, so Zend VM think it
should be fetched from a local symbol table.
and the 'local symbol table' for the global scope statement is actual 'global
symbol table', therefor it works 'as expected'.
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=55493
--
Edit this bug report at https://bugs.php.net/bug.php?id=55493&edit=1
Req #55493 [Com]: Superglobal variable variables with ${expression} in non-global scope
Edit report at https://bugs.php.net/bug.php?id=55493&edit=1
ID: 55493
Comment by: vovan-ve at yandex dot ru
Reported by:vovan-ve at yandex dot ru
Summary:Superglobal variable variables with ${expression} in
non-global scope
Status: Assigned
Type: Feature/Change Request
Package:Variables related
Operating System: Windows XP SP3
PHP Version:5.3.7
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
When I tried to obfuscate a part of code I was surprised by this strange
behariour. Of course, current implementation is correct on the one hand. But on
the other hand the situation looks funny: this way is allowad, and this too,
but this is not.
Previous Comments:
[2011-08-24 04:11:14] larue...@php.net
sure, it can be fixed by decide target symbol table again in the execution time
for not const OPs,
but I don't think this is really necessary . :)
[2011-08-23 18:16:12] ka...@php.net
This still seems a little strange that we cannot pick the correct symbol table
at compile time, all it should need would be a check to see if the compiled
value is matching one thats a super global.
I remember to have encountered something similar a while back, which I'm not
sure if I reported or not, but def. something we should look into at some point.
Dmitry, can you clarify this?
[2011-08-23 16:49:00] larue...@php.net
As I said, this is a limitation of PHP design, so mark as won't fix.
Thank you for your interest in PHP.
[2011-08-23 16:22:46] larue...@php.net
when fetching a variable, the target symbol table is decided in compiling time,
for the script above, in compiling time, only const string "_SERVER" can be
took consider as a SUPERVAR and assign the global symbol table as
target_symbol_table.
the others `varname` only can be see in execution time, so Zend VM think it
should be fetched from a local symbol table.
and the 'local symbol table' for the global scope statement is actual 'global
symbol table', therefor it works 'as expected'.
[2011-08-23 14:14:42] vovan-ve at yandex dot ru
Description:
ONLY Superglobal variable variables does not work ONLY in non-global
scope and ONLY with non-constant expression. See test script.
I found Req 38527, but it does not describe the problem properly and
due to misunderstanding it has status Feature Request instead of Bug
(and also it is too old).
Test script:
---
// in global scope everything is right
$name = '_SERVER';
var_dump(
isset(${'_SERVER'}),
isset($$name),
isset(${$name}),
isset(${'_SER' . 'VER'}),
isset(${'na' . 'me'})
);
echo PHP_EOL;
// but outside of global scope there is a trouble
function f() {
$name = '_SERVER';
var_dump(
isset(${'_SERVER'}),
isset($$name),
isset(${$name}),
isset(${'_SER' . 'VER'}),
isset(${'na' . 'me'})
);
}
f();
Expected result:
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
Actual result:
--
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(false)
bool(false)
bool(false)
bool(true)
--
Edit this bug report at https://bugs.php.net/bug.php?id=55493&edit=1
Bug #55484 [Opn->Dup]: file upload bug..
Edit report at https://bugs.php.net/bug.php?id=55484&edit=1 ID: 55484 Updated by: larue...@php.net Reported by:time2t at naver dot com Summary:file upload bug.. -Status: Open +Status: Duplicate Type: Bug Package:Built-in web server Operating System: windows PHP Version:5.3.7 Block user comment: N Private report: N New Comment: dup to #55498 Previous Comments: [2011-08-23 05:16:52] time2t at naver dot com Description: --- POST - Array ( [bo_image_head] => Array ( [name] => Y [type] => [tmp_name] => [error] => 4 [size] => 0 ) [bo_image_tail] => Array ( [name] => [type] => [tmp_name] => [error] => 4 [size] => 0 ) ) [name] => Y <-- bug Test script: --- asas --- POST - Array ( [bo_image_head] => Array ( [name] => Y [type] => [tmp_name] => [error] => 4 [size] => 0 ) [bo_image_tail] => Array ( [name] => [type] => [tmp_name] => [error] => 4 [size] => 0 ) ) [name] => Y <-- bug -- Edit this bug report at https://bugs.php.net/bug.php?id=55484&edit=1
Bug #55498 [Opn->Fbk]: filename bug
Edit report at https://bugs.php.net/bug.php?id=55498&edit=1 ID: 55498 Updated by: larue...@php.net Reported by:time2t at naver dot com Summary:filename bug -Status: Open +Status: Feedback Type: Bug Package:Built-in web server Operating System: windows PHP Version:5.4.0alpha3 Block user comment: N Private report: N Previous Comments: [2011-08-24 09:59:37] larue...@php.net I don't think 5.3.8 has webserver built-in, should be 5.4.0 and this is dup to #55484(since this report is more clearly, I will mark 55484 as dup). at last I can't reproduce this in Linux with php-5.4.0-trunk, can you try with the snapshot For Windows: http://windows.php.net/snapshots/ [2011-08-24 08:09:19] time2t at naver dot com Description: asas - POST file name test.msi - Array ( [bo_image_head] => Array ( [name] => est.msi [type] => application/octet-stream [tmp_name] => D:\server\tmp\php711.tmp [error] => 0 [size] => 664576 ) ) - [name] => est.msi <-- test.msi bug original file name test.msi ?? Test script: --- - POST file name test.msi - Array ( [bo_image_head] => Array ( [name] => est.msi [type] => application/octet-stream [tmp_name] => D:\server\tmp\php711.tmp [error] => 0 [size] => 664576 ) ) - [name] => est.msi <-- test.msi bug original file name test.msi ?? -- Edit this bug report at https://bugs.php.net/bug.php?id=55498&edit=1
Bug #55498 [Opn]: filename bug
Edit report at https://bugs.php.net/bug.php?id=55498&edit=1 ID: 55498 Updated by: larue...@php.net Reported by:time2t at naver dot com Summary:filename bug Status: Open Type: Bug Package:Built-in web server Operating System: windows -PHP Version:5.3.8 +PHP Version:5.4.0alpha3 Block user comment: N Private report: N New Comment: I don't think 5.3.8 has webserver built-in, should be 5.4.0 and this is dup to #55484(since this report is more clearly, I will mark 55484 as dup). at last I can't reproduce this in Linux with php-5.4.0-trunk, can you try with the snapshot For Windows: http://windows.php.net/snapshots/ Previous Comments: [2011-08-24 08:09:19] time2t at naver dot com Description: asas - POST file name test.msi - Array ( [bo_image_head] => Array ( [name] => est.msi [type] => application/octet-stream [tmp_name] => D:\server\tmp\php711.tmp [error] => 0 [size] => 664576 ) ) - [name] => est.msi <-- test.msi bug original file name test.msi ?? Test script: --- - POST file name test.msi - Array ( [bo_image_head] => Array ( [name] => est.msi [type] => application/octet-stream [tmp_name] => D:\server\tmp\php711.tmp [error] => 0 [size] => 664576 ) ) - [name] => est.msi <-- test.msi bug original file name test.msi ?? -- Edit this bug report at https://bugs.php.net/bug.php?id=55498&edit=1
Bug #55222 [Ver]: Fatal Error disappears when using paranthesis
Edit report at https://bugs.php.net/bug.php?id=55222&edit=1 ID: 55222 User updated by:hanskrentel at yahoo dot de Reported by:hanskrentel at yahoo dot de Summary:Fatal Error disappears when using paranthesis Status: Verified Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5.3.6 Block user comment: N Private report: N New Comment: I assume you want to say that the linked answer explicitly explains the problem. Should we make use of this feature when programming PHP or not? Previous Comments: [2011-07-29 09:56:38] cataphr...@php.net See http://stackoverflow.com/questions/6726589/parentheses-altering-semantics-of-function-call-result/6732876#6732876 [2011-07-27 16:34:24] hanskrentel at yahoo dot de I can only remind again that the first comment from php.net obviously misread this report. I am _missing_ the fatal error. [2011-07-19 08:10:56] hanskrentel at yahoo dot de Actually I'm concerned that reset( (get_array()) ); does _not_ give a fatal error. This contradicts the last comment "There's really no way to get around that [getting a fatal error]". Why does it not give a fatal error? There is no variable. [2011-07-18 22:21:36] ahar...@php.net reset() requires a variable that can be passed by reference. There's really no way to get around that, hence the fatal error. [2011-07-17 16:52:26] hanskrentel at yahoo dot de within = without in the description. 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=55222 -- Edit this bug report at https://bugs.php.net/bug.php?id=55222&edit=1
Bug #55495 [Wfx]: Issues with numeric string keys in objects
Edit report at https://bugs.php.net/bug.php?id=55495&edit=1
ID: 55495
User updated by:roan dot kattouw at gmail dot com
Reported by:roan dot kattouw at gmail dot com
Summary:Issues with numeric string keys in objects
Status: Wont fix
Type: Bug
Package:Class/Object related
Operating System: Ubuntu Natty
PHP Version:5.4.0alpha3
Block user comment: N
Private report: N
New Comment:
First of all, this is about objects, not arrays. In arrays, the messed-up
string-but-looks-like-a-number keys are still accessible, both through ["2"]
and [2], but in objects they're completely inaccessible. The object member is
there according to var_dump() but the only way to get its value is to cast the
object to an array.
Second, I don't see how a "known issue" is "wontfix". That sounds like a direct
contradiction to me.
Previous Comments:
[2011-08-24 04:06:53] larue...@php.net
it's a known issue, there is only number key in array if it is ('looks like') a
number.
[2011-08-23 15:31:21] roan dot kattouw at gmail dot com
Description:
If you have an object with numeric string keys such as "1", serialize() and
unserialize() will not round-trip cleanly: if $foo = array("1" =>"foo"),
unserialize(serialize($foo)) will be array(1=>"foo").
I'm not actually sure this is a bug in serialize()/unserialize(); it seems to
be a bug in json_decode() instead. Somewhat counter-intuitively, arrays or
objects with numeric string keys are really hard to produce. Constructs like
array("1"=>"foo") or even $s = "1"; $arr[$s] = "foo"; produce an array with
int(1) as the key rather than string("1"). The same is true for objects. The
only thing that produces numeric string keys, AFAIK, is json_decode().
A very related bug, and the reason I noticed this in the first place, is that
if you have an object with numeric keys and set $s = "2" , $obj->{$s} will not
return the value for key 2. Worse, it seems there's no way to access the value
short of casting the object to an array and using $arr[2].
Related bugs have been filed and closed, but they don't seem to have addressed
this issue properly:
#48557: patch applied to 5.2 and 5.3; I found this bug in 5.4
#48171: basically the same problem, marked as bogus referring to #48959 , which
is about arrays not objects. It claims to have been documented in the manual,
but again that refers to arrays not objects
Test script:
---
{$s});
var_dump($foo->{$i});
var_dump($bar->{$s});
var_dump($bar->{$i});
Expected result:
object(stdClass)#1 (2) {
["1"]=>
string(3) "foo"
["2"]=>
string(3) "bar"
}
string(55) "O:8:"stdClass":2:{s:1:"1";s:3:"foo";s:1:"2";s:3:"bar";}"
object(stdClass)#2 (2) {
["1"]=>
string(3) "foo"
["2"]=>
string(3) "bar"
}
string(3) "bar"
string(3) "bar"
string(3) "bar"
string(3) "bar"
Actual result:
--
object(stdClass)#1 (2) {
["1"]=>
string(3) "foo"
["2"]=>
string(3) "bar"
}
string(55) "O:8:"stdClass":2:{s:1:"1";s:3:"foo";s:1:"2";s:3:"bar";}"
object(stdClass)#2 (2) {
[1]=>
string(3) "foo"
[2]=>
string(3) "bar"
}
string(3) "bar"
string(3) "bar"
Notice: Undefined property: stdClass::$2 in
/home/catrope/php-5.4.0alpha3/testcase.php on line 13
NULL
Notice: Undefined property: stdClass::$2 in
/home/catrope/php-5.4.0alpha3/testcase.php on line 14
NULL
--
Edit this bug report at https://bugs.php.net/bug.php?id=55495&edit=1
[PHP-BUG] Bug #55498 [NEW]: filename bug
From: Operating system: windows PHP version: 5.3.8 Package: Built-in web server Bug Type: Bug Bug description:filename bug Description: asas - POST file name test.msi - Array ( [bo_image_head] => Array ( [name] => est.msi [type] => application/octet-stream [tmp_name] => D:\server\tmp\php711.tmp [error] => 0 [size] => 664576 ) ) - [name] => est.msi <-- test.msi bug original file name test.msi ?? Test script: --- - POST file name test.msi - Array ( [bo_image_head] => Array ( [name] => est.msi [type] => application/octet-stream [tmp_name] => D:\server\tmp\php711.tmp [error] => 0 [size] => 664576 ) ) - [name] => est.msi <-- test.msi bug original file name test.msi ?? -- Edit bug report at https://bugs.php.net/bug.php?id=55498&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55498&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55498&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55498&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55498&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55498&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55498&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55498&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55498&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55498&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55498&r=support Expected behavior: https://bugs.php.net/fix.php?id=55498&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55498&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55498&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55498&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55498&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55498&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55498&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55498&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55498&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55498&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55498&r=mysqlcfg
Bug #42659 [Com]: microtime() loses time in long-running scripts
Edit report at https://bugs.php.net/bug.php?id=42659&edit=1
ID: 42659
Comment by: pv47 at yandex dot ru
Reported by:jdolecek at NetBSD dot org
Summary:microtime() loses time in long-running scripts
Status: No Feedback
Type: Bug
Package:Date/time related
Operating System: win32 only
PHP Version:5.2.4
Block user comment: N
Private report: N
New Comment:
I have the same issue with php 5.3.6 on Windows 7.
Build Date Mar 17 2011 10:34:15
CompilerMSVC9 (Visual C++ 2008)
Architecturex86
Configure Command cscript /nologo configure.js "--enable-snapshot-build"
"--disable-isapi" "--enable-debug-pack" "--disable-isapi" "--without-mssql"
"--without-pdo-mssql" "--without-pi3web"
"--with-pdo-oci=D:\php-sdk\oracle\instantclient10\sdk,shared"
"--with-oci8=D:\php-sdk\oracle\instantclient10\sdk,shared"
"--with-oci8-11g=D:\php-sdk\oracle\instantclient11\sdk,shared"
"--enable-object-out-dir=../obj/" "--enable-com-dotnet" "--with-mcrypt=static"
Server API Apache 2.0 Handler
(from bug 52789)> I ran the script for two hours and a half and couldn't
reproduce it. Is this XP only?
I have 1-2 second difference after ~30 min of running my script on Windows 7.
Is this a windows bug?
Previous Comments:
[2010-09-07 09:34:32] jdolecek at NetBSD dot org
The problem is still there even with PHP 5.3.3:
PHP 5.3.3 (cli) (built: Jul 21 2010 20:36:55)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
The test runs on physical machine (not a virtual) running Windows XP SP3.
Output after about 21 hours with 5.3.3:
msec: [2010-09-07 09:12:15.7766]
sec : [2010-09-07 09:12:18]
msec: [2010-09-07 09:17:15.7700]
sec : [2010-09-07 09:17:18]
msec: [2010-09-07 09:22:15.7634]
sec : [2010-09-07 09:22:18]
msec: [2010-09-07 09:27:15.7568]
sec : [2010-09-07 09:27:18]
For comparison, here is output from parallelly running PHP 5.2.6:
msec: [2010-09-07 09:19:51.6134]
sec : [2010-09-07 09:19:54]
msec: [2010-09-07 09:24:51.6068]
sec : [2010-09-07 09:24:54]
msec: [2010-09-07 09:29:51.6003]
sec : [2010-09-07 09:29:54]
Both show ~3 sec time difference between microtime() and time()
Unfortunately I can't re-open the PR (it says I can't change the PR to that
state), so just adding a comment.
[2008-09-03 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2008-08-26 23:06:36] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.3-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.3-win32-installer-latest.msi
[2007-09-13 15:30:05] jdolecek at NetBSD dot org
Description:
When PHP script runs for long time, the value returned by microtime() gradually
drifts away from time(). The exact value depends on system, but we've seen 5
hour difference to current time for script running about a week, with drift
about 1 minute per 5 minutes run (system running under VMware). The script is
daemon-like process, i.e. it's blocked in select() most of time, and only
occassionally wakes up to process request.
Looking at win32/time.c, I spot one problematic spot in that the code might not
notice counter wrap-off if timer happens to be a higher value after wrap-around
then the last time the function was called. However, that shouldn't be normally
problem, since the counter wraps-around very infrequently.
Reproduce code:
---
#include
#include
#include
int getfilesystemtime(struct timeval *time_Info)
{
FILETIME ft;
__int64 ff;
LARGE_INTEGER li;
GetSystemTimeAsFileTime(&ft); /* 100 ns blocks since 01-Jan-1641 */
/* resolution seems to be 0.01 sec */
li.u.LowPart = ft.dwLowDateTime;
li.u.HighPart = ft.dwHighDateTime;
ff = li.QuadPart;
time_Info->tv_sec = (int)(ff/(__int64)1000-(__int64)11644473600ULL);
time_Info->tv_usec = (int)(ff % 1000)/10;
return 0;
}
#define PW32G(x)(x)
int
main()
{
LARGE_INTEGER li;
__int64 freq, timer;
double dt;
struct timeval tv, *time_Info = &tv, starttime, tv2;
QueryPerformanceFrequency(&li);
freq = li.QuadPart;
getfilesystemtime(&starttime);
QueryPerformanceCounter(&li);
ti
