Bug #65340 [Com]: Memory leak when using magic __set ?
Edit report at https://bugs.php.net/bug.php?id=65340&edit=1
ID: 65340
Comment by: vitalif at mail dot ru
Reported by:vitalif at mail dot ru
Summary:Memory leak when using magic __set ?
Status: Open
Type: Bug
Package:Class/Object related
Operating System: Linux
PHP Version:5.5.1
Block user comment: N
Private report: N
New Comment:
I don't think bug #48197 is related to this issue... There are no memory leaks.
I.e. extra alloc done by __call in that bug is freed without problem (if you
remove "$b[$i] =" and just throw away the value after each call).
And here I describe that an identical object takes twice more memory if you
write in its array property using __set.
Previous Comments:
[2013-07-26 01:51:01] fel...@php.net
See bug #48197
[2013-07-25 21:38:37] vitalif at mail dot ru
Description:
Hello!
I've discovered that when setting properties via __set() the object takes much
more memory than it should. It's reproducible at least on PHP 5.5 and 5.4. Is
it a memory leak?
Test script:
---
data[$k];
}
function __set($k, $v)
{
return $this->data[$k] = $v;
}
}
$b = new A();
for ($i = 0; $i < 50; $i++)
$b->{"a$i"} = 'abc';
var_dump(memory_get_usage()); // int(78318488) - why so big?
$c = clone $b;
unset($b);
var_dump(memory_get_usage()); // int(42220972) - OK
unset($c);
$b = new A();
for ($i = 0; $i < 50; $i++)
$b->__set("a$i", 'abc');
var_dump(memory_get_usage()); // int(42221492) - OK
Expected result:
I expect roughly the same memory usage at all three points. Like:
int(42220972)
int(42220972)
int(42221492)
Actual result:
--
The first value is much bigger:
int(78318488)
int(42220972)
int(42221492)
--
Edit this bug report at https://bugs.php.net/bug.php?id=65340&edit=1
Bug #65338 [Com]: Enabling both php_opcache and php_wincache AVs on shutdown
Edit report at https://bugs.php.net/bug.php?id=65338&edit=1 ID: 65338 Comment by: phpdev at ehrhardt dot nl Reported by:erics...@php.net Summary:Enabling both php_opcache and php_wincache AVs on shutdown Status: Feedback Type: Bug Package:Reproducible crash Operating System: Windows PHP Version:5.5.1 Assigned To:dmitry Block user comment: N Private report: N New Comment: @Anatol: which older versions? PHP 5.4.x users that run into this problem should upgrade to 5.4.18, the moment that is released with this patch. Making special arrangements for older 5.4.x users would be a waste of developer resources IMO. And PHP 5.3 (or lower) users do not run into this, because interned_string was introduced in the Zend engine for 5.4. Previous Comments: [2013-07-27 15:25:39] a...@php.net Jan, I meant exactly that, there still will be some users on versions lower than 5.4.17 or which is the current. The question is just whether it's worth the effort to be aware of that. [2013-07-27 12:18:07] phpdev at ehrhardt dot nl @Anatol: there is no need to disable interned strings in extensions for older PHP-versions if you backport the patch. I do not think I have the karma to put a patch here, but this is the backport for PHP 5.4: http://x32.elijst.nl/zend_interned_strings_shutdown_AV.patch Maybe except for some line numbers it is literally the same patch. [2013-07-27 08:30:25] a...@php.net @Eric ok, so the catch is to use the wincache with disabled opcode cache. Whereby interned strings are neither opcode cache nor any other functionality. The patch would solve it only for newer PHP versions, maybe it should be possible to disable interned strings explicitly in wincache/opcache, maybe per ini? That would solve it also for users with older PHP without TS. @Jan that's obvious now where people start to mix the cache engines :) [2013-07-27 05:02:11] paj...@php.net Agreed,should be applied in php-src and github repos. [2013-07-27 01:27:59] phpdev at ehrhardt dot nl The problem is so obvious, that I am surprised it did not com to surface earlier. And the patch is elegant: do not assume interned_strings_start is still the same, but free only the memory that you owned at startup. In fact, the patch should be backported to PHP 5.4 as well. I do not have a use case for X86, but I ran into the same problem woth PHP 5.4 X64. I know this is no official version, but as an illustration of the problem it still is useful. Compare these two builds: https://dl.dropboxusercontent.com/u/8954372/php-5.4.17-nts-Win32-VC9-x64.zip https://dl.dropboxusercontent.com/u/8954372/php-5.4.17-nts-Win32-VC9-x64_patched.zip Try the unpatched one first. Put this in your php.ini: extension=php_wincache.dll zend_extension=ext/php_opcache.dll zend_opcache.memory_consumption=128 zend_opcache.interned_strings_buffer=8 zend_opcache.max_accelerated_files=4000 zend_opcache.revalidate_freq=60 zend_opcache.fast_shutdown=1 zend_opcache.enable_cli=1 wincache.ocenabled=0 wincache.fcenabled=0 wincache.ucachesize=768 wincache.enablecli=1 session.savehandler=wincache Then run from the commandline in your php-directory: php-cgi.exe -m php-cgi will crash after showing the loaded modules. Debugging with VC9 gave this result: http://x32.elijst.nl/zendfree.png Quite another breakpoint as in the PHP 5.5 example, but with the same cause: freeing memory you do not own. In the patched build I backported Eric's patch for zend_string.c to PHP 5.4. Result: no crash anymore. A last remark: i do not think the problem is Windows specific. This is exectly the same problem, but with the combination of opcache and apc: http://svn.php.net/viewvc?view=revision&revision=330859 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=65338 -- Edit this bug report at https://bugs.php.net/bug.php?id=65338&edit=1
Bug #65338 [Fbk]: Enabling both php_opcache and php_wincache AVs on shutdown
Edit report at https://bugs.php.net/bug.php?id=65338&edit=1 ID: 65338 Updated by: a...@php.net Reported by:erics...@php.net Summary:Enabling both php_opcache and php_wincache AVs on shutdown Status: Feedback Type: Bug Package:Reproducible crash Operating System: Windows PHP Version:5.5.1 Assigned To:dmitry Block user comment: N Private report: N New Comment: Jan, I meant exactly that, there still will be some users on versions lower than 5.4.17 or which is the current. The question is just whether it's worth the effort to be aware of that. Previous Comments: [2013-07-27 12:18:07] phpdev at ehrhardt dot nl @Anatol: there is no need to disable interned strings in extensions for older PHP-versions if you backport the patch. I do not think I have the karma to put a patch here, but this is the backport for PHP 5.4: http://x32.elijst.nl/zend_interned_strings_shutdown_AV.patch Maybe except for some line numbers it is literally the same patch. [2013-07-27 08:30:25] a...@php.net @Eric ok, so the catch is to use the wincache with disabled opcode cache. Whereby interned strings are neither opcode cache nor any other functionality. The patch would solve it only for newer PHP versions, maybe it should be possible to disable interned strings explicitly in wincache/opcache, maybe per ini? That would solve it also for users with older PHP without TS. @Jan that's obvious now where people start to mix the cache engines :) [2013-07-27 05:02:11] paj...@php.net Agreed,should be applied in php-src and github repos. [2013-07-27 01:27:59] phpdev at ehrhardt dot nl The problem is so obvious, that I am surprised it did not com to surface earlier. And the patch is elegant: do not assume interned_strings_start is still the same, but free only the memory that you owned at startup. In fact, the patch should be backported to PHP 5.4 as well. I do not have a use case for X86, but I ran into the same problem woth PHP 5.4 X64. I know this is no official version, but as an illustration of the problem it still is useful. Compare these two builds: https://dl.dropboxusercontent.com/u/8954372/php-5.4.17-nts-Win32-VC9-x64.zip https://dl.dropboxusercontent.com/u/8954372/php-5.4.17-nts-Win32-VC9-x64_patched.zip Try the unpatched one first. Put this in your php.ini: extension=php_wincache.dll zend_extension=ext/php_opcache.dll zend_opcache.memory_consumption=128 zend_opcache.interned_strings_buffer=8 zend_opcache.max_accelerated_files=4000 zend_opcache.revalidate_freq=60 zend_opcache.fast_shutdown=1 zend_opcache.enable_cli=1 wincache.ocenabled=0 wincache.fcenabled=0 wincache.ucachesize=768 wincache.enablecli=1 session.savehandler=wincache Then run from the commandline in your php-directory: php-cgi.exe -m php-cgi will crash after showing the loaded modules. Debugging with VC9 gave this result: http://x32.elijst.nl/zendfree.png Quite another breakpoint as in the PHP 5.5 example, but with the same cause: freeing memory you do not own. In the patched build I backported Eric's patch for zend_string.c to PHP 5.4. Result: no crash anymore. A last remark: i do not think the problem is Windows specific. This is exectly the same problem, but with the combination of opcache and apc: http://svn.php.net/viewvc?view=revision&revision=330859 [2013-07-26 21:07:09] me at laurinkeithdavis dot com I can confirm that this patch works as well. https://bugs.php.net/bug.php?id=65247 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=65338 -- Edit this bug report at https://bugs.php.net/bug.php?id=65338&edit=1
Bug #65338 [Com]: Enabling both php_opcache and php_wincache AVs on shutdown
Edit report at https://bugs.php.net/bug.php?id=65338&edit=1 ID: 65338 Comment by: phpdev at ehrhardt dot nl Reported by:erics...@php.net Summary:Enabling both php_opcache and php_wincache AVs on shutdown Status: Feedback Type: Bug Package:Reproducible crash Operating System: Windows PHP Version:5.5.1 Assigned To:dmitry Block user comment: N Private report: N New Comment: @Anatol: there is no need to disable interned strings in extensions for older PHP-versions if you backport the patch. I do not think I have the karma to put a patch here, but this is the backport for PHP 5.4: http://x32.elijst.nl/zend_interned_strings_shutdown_AV.patch Maybe except for some line numbers it is literally the same patch. Previous Comments: [2013-07-27 08:30:25] a...@php.net @Eric ok, so the catch is to use the wincache with disabled opcode cache. Whereby interned strings are neither opcode cache nor any other functionality. The patch would solve it only for newer PHP versions, maybe it should be possible to disable interned strings explicitly in wincache/opcache, maybe per ini? That would solve it also for users with older PHP without TS. @Jan that's obvious now where people start to mix the cache engines :) [2013-07-27 05:02:11] paj...@php.net Agreed,should be applied in php-src and github repos. [2013-07-27 01:27:59] phpdev at ehrhardt dot nl The problem is so obvious, that I am surprised it did not com to surface earlier. And the patch is elegant: do not assume interned_strings_start is still the same, but free only the memory that you owned at startup. In fact, the patch should be backported to PHP 5.4 as well. I do not have a use case for X86, but I ran into the same problem woth PHP 5.4 X64. I know this is no official version, but as an illustration of the problem it still is useful. Compare these two builds: https://dl.dropboxusercontent.com/u/8954372/php-5.4.17-nts-Win32-VC9-x64.zip https://dl.dropboxusercontent.com/u/8954372/php-5.4.17-nts-Win32-VC9-x64_patched.zip Try the unpatched one first. Put this in your php.ini: extension=php_wincache.dll zend_extension=ext/php_opcache.dll zend_opcache.memory_consumption=128 zend_opcache.interned_strings_buffer=8 zend_opcache.max_accelerated_files=4000 zend_opcache.revalidate_freq=60 zend_opcache.fast_shutdown=1 zend_opcache.enable_cli=1 wincache.ocenabled=0 wincache.fcenabled=0 wincache.ucachesize=768 wincache.enablecli=1 session.savehandler=wincache Then run from the commandline in your php-directory: php-cgi.exe -m php-cgi will crash after showing the loaded modules. Debugging with VC9 gave this result: http://x32.elijst.nl/zendfree.png Quite another breakpoint as in the PHP 5.5 example, but with the same cause: freeing memory you do not own. In the patched build I backported Eric's patch for zend_string.c to PHP 5.4. Result: no crash anymore. A last remark: i do not think the problem is Windows specific. This is exectly the same problem, but with the combination of opcache and apc: http://svn.php.net/viewvc?view=revision&revision=330859 [2013-07-26 21:07:09] me at laurinkeithdavis dot com I can confirm that this patch works as well. https://bugs.php.net/bug.php?id=65247 [2013-07-26 16:48:39] phpdev at ehrhardt dot nl @Anatol: Xinchen ran into the same problem while combining APC usercache with OPcache opcode cache. See http://svn.php.net/viewvc?view=revision&revision=330859 He solved it by disabling interned_string. @Eric: I can confirm your patch works. Tested it as well under X86 as X64. 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=65338 -- Edit this bug report at https://bugs.php.net/bug.php?id=65338&edit=1
Req #65257 [Com]: new function for preventing XSS attack
Edit report at https://bugs.php.net/bug.php?id=65257&edit=1
ID: 65257
Comment by: ni...@php.net
Reported by:masakielastic at gmail dot com
Summary:new function for preventing XSS attack
Status: Open
Type: Feature/Change Request
Package:JSON related
PHP Version:5.5.0
Block user comment: N
Private report: N
New Comment:
I don't really understand this issue (and also why the JSON_HEX_* flags were
necessary in the first place). If you are going to embed JSON into HTML, why
not use the usual htmlspecialchars function? Why do we have to implement HTML
escaping functionality inside json_encode? Both things seem very distinct to me.
Previous Comments:
[2013-07-26 22:31:00] yohg...@php.net
Alternatively, we may introduce JSON_UNICODE and make it default. Unicode
escape
is defined in FRC4627. e.g. \uD834\uDD1E
This would be most secure way of escaping unicode. The disadvantage is
increased
data size.
[2013-07-26 21:23:07] yohg...@php.net
Sounds good to me. Anyone else have comments?
[2013-07-13 14:31:24] masakielastic at gmail dot com
Description:
Although JSON_HEX_TAG, JSON_HEX_APOS, JSON_HEX_QUOT, JSON_HEX_AMP options
were added in PHP 5.3 for preventing XSS attack,
a lot of people don't specify these options.
https://github.com/search?l=PHP&q=json_encode&ref=advsearch&type=Code
The one of PHP's goal is to provide a secure way for creating
web application without CMSes and frameworks.
The one of mesures for the problem is providing new function
with make these options default.
Adding recommend opitons as a default also make sense.
function json_secure_encode($value, $options = 0, $depth = 512)
{
// JSON_NOTUTF8_SUBSTITUTE
// an option replacing ill-formd byte sequences with substitute characters
// https://bugs.php.net/bug.php?id=65082
$options |= JSON_HEX_TAG
| JSON_HEX_APOS | JSON_HEX_QUOT
| JSON_HEX_AMP | JSON_NOTUTF8_SUBSTITUTE;
return json_secure_encode($value, $options, $depth);
}
A shortcut for these options may be helpful a bit.
if (!defined('JSON_QUOTES')) {
define('JSON_QUOTES', JSON_HEX_TAG | JSON_HEX_APOS | JSON_HEX_AMP |
JSON_HEX_QUOT);
}
The following RFC shows various functions for less options.
Escaping RFC for PHP Core
https://wiki.php.net/rfc/escaper
Ruby on Rails provide json_escape via ERB::Util.
http://api.rubyonrails.org/classes/ERB/Util.html
OWAPS shows the guidelines for XSS attack.
RULE #3.1 - HTML escape JSON values in an HTML context and read the data with
JSON.parse
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Shee
t#RULE_.233.1_-
_HTML_escape_JSON_values_in_an_HTML_context_and_read_the_data_with_JSON.parse
As a sidenote, the default HTTP headers of Rails
include "X-Content-Type-Options: nosniff" for IE.
http://edgeguides.rubyonrails.org/security.html#default-headers
https://github.com/rails/docrails/blob/master/actionpack/lib/action_dispatch/rai
ltie.rb#L20=L24
The following articles describe JSON-based XSS exploitation.
http://blog.watchfire.com/wfblog/2011/10/json-based-xss-exploitation.html
https://superevr.com/blog/2012/exploiting-xss-in-ajax-web-applications
--
Edit this bug report at https://bugs.php.net/bug.php?id=65257&edit=1
Req #65350 [Opn->Nab]: v5.5 packages (compiled by VS 2012) do not run on Windows XP.
Edit report at https://bugs.php.net/bug.php?id=65350&edit=1 ID: 65350 Updated by: a...@php.net Reported by:dualchannel at centrum dot cz Summary:v5.5 packages (compiled by VS 2012) do not run on Windows XP. -Status: Open +Status: Not a bug Type: Feature/Change Request Package:Unknown/Other Function Operating System: Windows XP ready-built packages PHP Version:5.5.1 Block user comment: N Private report: N New Comment: Windows XP support is discontinued with PHP 5.5, for further details read https://github.com/php/php-src/blob/PHP-5.5/UPGRADING Previous Comments: [2013-07-27 07:24:01] dualchannel at centrum dot cz Description: v5.5 executables does not run on Windows XP, specifically, I have tried on XP SP3 x86, with all the latest patches applied and VC11 redistributables installed. I just downloaded the precompiled binaries 'php-5.5.1-Win32-VC11-x86.zip', unpacked the zip-file and tried 'php -h' in a terminal. It shows an error pop-up: "php.exe is not a valid Win32 application." and a message "Access denied." in the terminal. No web server nor a database engine of any kind is running on the machine, just running the precompiled executable with '-h' parameter leads to the described result. Precompiled binaries from 'php-5.3.27-Win32-VC9-x86.zip' run well on my setup (shows a help text, no error pop-up). Frankly, I am not a Windows developer, but after googling a minute I got a faith that this could be easily fixed. This is a fragment of discussion on stackoverflow: Visual Studio 2012 Update 1 has now been released, and adds official support for running apps built with VC++ 2012 on Windows XP. So I propose compiling php v5.5 binaries capable of running on Windows XP systems and putting them in download section alongside currently available ones. I believe that there is still a tremendous number of users runinng Windows XP. Thank you very much in advance. -- Edit this bug report at https://bugs.php.net/bug.php?id=65350&edit=1
Bug #65338 [Fbk]: Enabling both php_opcache and php_wincache AVs on shutdown
Edit report at https://bugs.php.net/bug.php?id=65338&edit=1 ID: 65338 Updated by: a...@php.net Reported by:erics...@php.net Summary:Enabling both php_opcache and php_wincache AVs on shutdown Status: Feedback Type: Bug Package:Reproducible crash Operating System: Windows PHP Version:5.5.1 Assigned To:dmitry Block user comment: N Private report: N New Comment: @Eric ok, so the catch is to use the wincache with disabled opcode cache. Whereby interned strings are neither opcode cache nor any other functionality. The patch would solve it only for newer PHP versions, maybe it should be possible to disable interned strings explicitly in wincache/opcache, maybe per ini? That would solve it also for users with older PHP without TS. @Jan that's obvious now where people start to mix the cache engines :) Previous Comments: [2013-07-27 05:02:11] paj...@php.net Agreed,should be applied in php-src and github repos. [2013-07-27 01:27:59] phpdev at ehrhardt dot nl The problem is so obvious, that I am surprised it did not com to surface earlier. And the patch is elegant: do not assume interned_strings_start is still the same, but free only the memory that you owned at startup. In fact, the patch should be backported to PHP 5.4 as well. I do not have a use case for X86, but I ran into the same problem woth PHP 5.4 X64. I know this is no official version, but as an illustration of the problem it still is useful. Compare these two builds: https://dl.dropboxusercontent.com/u/8954372/php-5.4.17-nts-Win32-VC9-x64.zip https://dl.dropboxusercontent.com/u/8954372/php-5.4.17-nts-Win32-VC9-x64_patched.zip Try the unpatched one first. Put this in your php.ini: extension=php_wincache.dll zend_extension=ext/php_opcache.dll zend_opcache.memory_consumption=128 zend_opcache.interned_strings_buffer=8 zend_opcache.max_accelerated_files=4000 zend_opcache.revalidate_freq=60 zend_opcache.fast_shutdown=1 zend_opcache.enable_cli=1 wincache.ocenabled=0 wincache.fcenabled=0 wincache.ucachesize=768 wincache.enablecli=1 session.savehandler=wincache Then run from the commandline in your php-directory: php-cgi.exe -m php-cgi will crash after showing the loaded modules. Debugging with VC9 gave this result: http://x32.elijst.nl/zendfree.png Quite another breakpoint as in the PHP 5.5 example, but with the same cause: freeing memory you do not own. In the patched build I backported Eric's patch for zend_string.c to PHP 5.4. Result: no crash anymore. A last remark: i do not think the problem is Windows specific. This is exectly the same problem, but with the combination of opcache and apc: http://svn.php.net/viewvc?view=revision&revision=330859 [2013-07-26 21:07:09] me at laurinkeithdavis dot com I can confirm that this patch works as well. https://bugs.php.net/bug.php?id=65247 [2013-07-26 16:48:39] phpdev at ehrhardt dot nl @Anatol: Xinchen ran into the same problem while combining APC usercache with OPcache opcode cache. See http://svn.php.net/viewvc?view=revision&revision=330859 He solved it by disabling interned_string. @Eric: I can confirm your patch works. Tested it as well under X86 as X64. [2013-07-26 16:04:36] erics...@php.net a...@php.net said > What is the catch/sense of using both at the same time? Wincache provides a file cache, session cache, user property cache as well as an opcode cache. Further, it's possible to disable the opcode cache. On PHP5.5, we (Wincache support folks) expect customers to enable the Zend opcache (because it's in 'core', and probably does more optimizing than Wincache does), but continue to use Wincache for file, session and user cache. 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=65338 -- Edit this bug report at https://bugs.php.net/bug.php?id=65338&edit=1
[PHP-BUG] Req #65350 [NEW]: v5.5 packages (compiled by VS 2012) do not run on Windows XP.
From: dualchannel at centrum dot cz Operating system: Windows XP ready-built packages PHP version: 5.5.1 Package: Unknown/Other Function Bug Type: Feature/Change Request Bug description:v5.5 packages (compiled by VS 2012) do not run on Windows XP. Description: v5.5 executables does not run on Windows XP, specifically, I have tried on XP SP3 x86, with all the latest patches applied and VC11 redistributables installed. I just downloaded the precompiled binaries 'php-5.5.1-Win32-VC11-x86.zip', unpacked the zip-file and tried 'php -h' in a terminal. It shows an error pop-up: "php.exe is not a valid Win32 application." and a message "Access denied." in the terminal. No web server nor a database engine of any kind is running on the machine, just running the precompiled executable with '-h' parameter leads to the described result. Precompiled binaries from 'php-5.3.27-Win32-VC9-x86.zip' run well on my setup (shows a help text, no error pop-up). Frankly, I am not a Windows developer, but after googling a minute I got a faith that this could be easily fixed. This is a fragment of discussion on stackoverflow: Visual Studio 2012 Update 1 has now been released, and adds official support for running apps built with VC++ 2012 on Windows XP. So I propose compiling php v5.5 binaries capable of running on Windows XP systems and putting them in download section alongside currently available ones. I believe that there is still a tremendous number of users runinng Windows XP. Thank you very much in advance. -- Edit bug report at https://bugs.php.net/bug.php?id=65350&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65350&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65350&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65350&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65350&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65350&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65350&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65350&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65350&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65350&r=support Expected behavior: https://bugs.php.net/fix.php?id=65350&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65350&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65350&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65350&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65350&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65350&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65350&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65350&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65350&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65350&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65350&r=mysqlcfg
