Bug #48831 [PATCH]: php -i has different output to php --ini
Edit report at http://bugs.php.net/bug.php?id=48831&edit=1
ID: 48831
Patch added by: rquadl...@php.net
Reported by: RQuadling at GMail dot com
Summary: php -i has different output to php --ini
Status: Assigned
Type: Bug
Package: CGI related
Operating System: *
PHP Version: 5.*, 6CVS (2009-07-07)
Assigned To: pajoye
New Comment:
The following patch has been added/updated:
Patch Name: ScanIniDir
Revision: 1271085810
URL:
http://bugs.php.net/patch-display.php?bug=48831&patch=ScanIniDir&revision=1271085810
Previous Comments:
[2009-08-24 12:48:57] RQuadling at GMail dot com
Missed an PHPAPI extern char *php_ini_scanned_path;
[2009-07-07 11:28:46] rquadl...@php.net
Typo: had => has
[2009-07-07 11:24:31] RQuadling at GMail dot com
Description:
If the environment variable PHP_INI_SCAN_DIR is set, then
php -i
outputs the path and any ini files.
If you enter
php --ini
the ini files are correct, but the scan directory is not.
php --ini is only showing the PHP_CONFIG_FILE_SCAN_DIR value rather
than the php_ini_scanned_path (which may be PHP_CONFIG_FILE_SCAN_DIR
if there is no PHP_INI_SCAN_DIR envvar).
Patch below
Index: php_cli.c
===
RCS file: /repository/php-src/sapi/cli/php_cli.c,v
retrieving revision 1.211
diff -u -r1.211 php_cli.c
--- php_cli.c 5 Jun 2009 18:50:10 - 1.211
+++ php_cli.c 7 Jul 2009 11:16:14 -
@@ -1360,7 +1360,7 @@
{
zend_printf("Configuration
File (php.ini) Path: %s\n", PHP_CONFIG_FILE_PATH);
zend_printf("Loaded
Configuration File: %s\n", php_ini_opened_path ?
php_ini_opened_path : "(none)");
- zend_printf("Scan for
additional .ini files in: %s\n", *PHP_CONFIG_FILE_SCAN_DIR ?
PHP_CONFIG_FILE_SCAN_DIR : "(none)");
+ zend_printf("Scan for
additional .ini files in: %s\n", php_ini_scanned_path ?
php_ini_scanned_path : "(none)");
zend_printf("Additional .ini
files parsed: %s\n", php_ini_scanned_files ?
php_ini_scanned_files : "(none)");
break;
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=48831&edit=1
Bug #48781 [Com]: Cyclical garbage collector memory leak
Edit report at http://bugs.php.net/bug.php?id=48781&edit=1
ID: 48781
Comment by: rquadl...@php.net
Reported by: nate at frickenate dot com
Summary: Cyclical garbage collector memory leak
Status: Assigned
Type: Bug
Package: Scripting Engine problem
Operating System: Debian 5.0 kernel 2.6.24-23-xen
PHP Version: 5.3.0
Assigned To: dmitry
New Comment:
The gc cycle seems to miss the last 2 items on this cycle, but picks up
from the
last one for the next cycle, so is only actually dropping 1 item per
cycle.
My cycle goes something like this ...
Create and assign #1 to #4999
Create #5000
Destroy #1 to #4998
Assign #5000
Create and assign #5001 to #
Create #1
Destroy #5000 to #9998 --- Skipped #4999
Assign #1
Create and assign #10001 to #14999
Create #15000
Destroy #1 to #14998 --- Skipped #
etc.
My code changes ...
class User {
protected
$profile, $usercount;
public function __construct ($usercount) {
echo str_pad($this->usercount = $usercount, 5, '0', STR_PAD_LEFT),
':#1',
PHP_EOL;
$this->profile = new UserProfile($this);
}
public function __destruct() {
echo str_pad($this->usercount, 5, '0', STR_PAD_LEFT), ':#3',
PHP_EOL;
}
}
class UserProfile {
private
$user;
public function __construct ($user) {
$this->user = $user;
}
}
for ($userid = 1; ; $userid++) {
$user = new User($userid);
echo str_pad($userid, 5, '0', STR_PAD_LEFT), ':#2', PHP_EOL;
// Same code as provided by Nate.
Previous Comments:
[2010-04-19 09:54:39] dmi...@php.net
Yeah. I confirm the problem. It looks like on each 100,000 iterations
PHP runs GC about 12 times. And on each GC run it looses 2 objects
referenced by $user. I'll try to fix it.
[2010-04-18 02:28:35] j...@php.net
I am unable to duplicate this behaviour using 5.3.2. The code given
below consistently uses 0.65 MB even up to 10 million iterations - I
pasted the output of up to 6 million, with the extended GC reporting
turned on:
profile = new UserProfile($this);
}
public function dispose() {
$this->profile->dispose();
$this->profile = null;
}
}
class UserProfile {
private $user;
public function __construct ($user) {
$this->user = $user;
}
public function dispose() {
$this->user = null;
}
}
for ($userid = 1; ; $userid++) {
if(isset($user)) {
$user->dispose();
}
$user = new User;
if ($userid % 10 == 0)
printf("memory usage after %s users: %s MB.\n",
number_format($userid), number_format(memory_get_usage() / 1024 / 1024,
2));
continue;
}
?>
memory usage after 100,000 users: 0.65 MB.
memory usage after 200,000 users: 0.65 MB.
memory usage after 300,000 users: 0.65 MB.
[snip]
memory usage after 5,700,000 users: 0.65 MB.
memory usage after 5,800,000 users: 0.65 MB.
memory usage after 5,900,000 users: 0.65 MB.
GC Statistics
-
Runs: 0
Collected: 0
Root buffer length: 0
Root buffer peak: 9
PossibleRemove from Marked
RootBuffered buffer grey
--- --
ZVAL16 7 7 0
ZOBJ 7784 1198 1198 0
[2010-01-05 19:31:01] nightstorm at tlen dot pl
I confirm, there is a true memory leak. Consider the following script,
where the references are unmounted manually with an extra dispose()
method:
profile = new UserProfile($this);
}
public function dispose()
{
$this->profile->dispose();
$this->profile = null;
} // end dispose();
}
class UserProfile {
private
$user;
public function __construct ($user) {
$this->user = $user;
}
public function dispose()
{
$this->user = null;
} // end dispose();
}
for ($userid = 1; ; $userid++) {
if(isset($user))
{
$user->dispose();
}
$user = new User;
if ($userid % 10 == 0)
printf("memory usage after %s users: %s MB.\n",
number_format($userid), number_format(memory_get_usage() / 1024 / 1024,
2));
continue;
}
~
In this case the result is still the same (PHP 5.3.1):
memory usage after 100,000 users: 0.61 MB.
memory usage after 200,000 users: 0.61 MB.
memo
Bug #48781 [Com]: Cyclical garbage collector memory leak
Edit report at http://bugs.php.net/bug.php?id=48781&edit=1
ID: 48781
Comment by: rquadl...@php.net
Reported by: nate at frickenate dot com
Summary: Cyclical garbage collector memory leak
Status: Assigned
Type: Bug
Package: Scripting Engine problem
Operating System: Debian 5.0 kernel 2.6.24-23-xen
PHP Version: 5.3.0
Assigned To: dmitry
New Comment:
If the loop is limited to 1 items, using my code to report the
construct/use/destruct, the log ends with ...
11108:#3
11109:#3
0:#3
1:#3
04999:#3
0:#3
1:#3
So, it is completely losing the items, just not cleaning them during the
cycle.
At shutdown, they are cleaned.
Previous Comments:
[2010-04-19 12:27:12] rquadl...@php.net
The gc cycle seems to miss the last 2 items on this cycle, but picks up
from the
last one for the next cycle, so is only actually dropping 1 item per
cycle.
My cycle goes something like this ...
Create and assign #1 to #4999
Create #5000
Destroy #1 to #4998
Assign #5000
Create and assign #5001 to #
Create #1
Destroy #5000 to #9998 --- Skipped #4999
Assign #1
Create and assign #10001 to #14999
Create #15000
Destroy #1 to #14998 --- Skipped #
etc.
My code changes ...
class User {
protected
$profile, $usercount;
public function __construct ($usercount) {
echo str_pad($this->usercount = $usercount, 5, '0', STR_PAD_LEFT),
':#1',
PHP_EOL;
$this->profile = new UserProfile($this);
}
public function __destruct() {
echo str_pad($this->usercount, 5, '0', STR_PAD_LEFT), ':#3',
PHP_EOL;
}
}
class UserProfile {
private
$user;
public function __construct ($user) {
$this->user = $user;
}
}
for ($userid = 1; ; $userid++) {
$user = new User($userid);
echo str_pad($userid, 5, '0', STR_PAD_LEFT), ':#2', PHP_EOL;
// Same code as provided by Nate.
[2010-04-19 09:54:39] dmi...@php.net
Yeah. I confirm the problem. It looks like on each 100,000 iterations
PHP runs GC about 12 times. And on each GC run it looses 2 objects
referenced by $user. I'll try to fix it.
[2010-04-18 02:28:35] j...@php.net
I am unable to duplicate this behaviour using 5.3.2. The code given
below consistently uses 0.65 MB even up to 10 million iterations - I
pasted the output of up to 6 million, with the extended GC reporting
turned on:
profile = new UserProfile($this);
}
public function dispose() {
$this->profile->dispose();
$this->profile = null;
}
}
class UserProfile {
private $user;
public function __construct ($user) {
$this->user = $user;
}
public function dispose() {
$this->user = null;
}
}
for ($userid = 1; ; $userid++) {
if(isset($user)) {
$user->dispose();
}
$user = new User;
if ($userid % 10 == 0)
printf("memory usage after %s users: %s MB.\n",
number_format($userid), number_format(memory_get_usage() / 1024 / 1024,
2));
continue;
}
?>
memory usage after 100,000 users: 0.65 MB.
memory usage after 200,000 users: 0.65 MB.
memory usage after 300,000 users: 0.65 MB.
[snip]
memory usage after 5,700,000 users: 0.65 MB.
memory usage after 5,800,000 users: 0.65 MB.
memory usage after 5,900,000 users: 0.65 MB.
GC Statistics
-
Runs: 0
Collected: 0
Root buffer length: 0
Root buffer peak: 9
PossibleRemove from Marked
RootBuffered buffer grey
--- --
ZVAL16 7 7 0
ZOBJ 7784 1198 1198 0
[2010-01-05 19:31:01] nightstorm at tlen dot pl
I confirm, there is a true memory leak. Consider the following script,
where the references are unmounted manually with an extra dispose()
method:
profile = new UserProfile($this);
}
public function dispose()
{
$this->profile->dispose();
$this->profile = null;
} // end dispose();
}
class UserProfile {
private
$user;
public function __construct ($user) {
$this->user = $user;
}
public function dispose()
{
$this->user = null;
} // end dispose();
}
for ($userid = 1; ; $userid++) {
if(isset($user))
{
Bug #48781 [Com]: Cyclical garbage collector memory leak
Edit report at http://bugs.php.net/bug.php?id=48781&edit=1
ID: 48781
Comment by: rquadl...@php.net
Reported by: nate at frickenate dot com
Summary: Cyclical garbage collector memory leak
Status: Assigned
Type: Bug
Package: Scripting Engine problem
Operating System: Debian 5.0 kernel 2.6.24-23-xen
PHP Version: 5.3.0
Assigned To: dmitry
New Comment:
That should have said ...
"So, it is _NOT_ completely losing the items, just not cleaning them
during the
cycle. At shutdown, they are cleaned."
Previous Comments:
[2010-04-19 12:31:56] rquadl...@php.net
If the loop is limited to 1 items, using my code to report the
construct/use/destruct, the log ends with ...
11108:#3
11109:#3
0:#3
1:#3
04999:#3
0:#3
1:#3
So, it is completely losing the items, just not cleaning them during the
cycle.
At shutdown, they are cleaned.
[2010-04-19 12:27:12] rquadl...@php.net
The gc cycle seems to miss the last 2 items on this cycle, but picks up
from the
last one for the next cycle, so is only actually dropping 1 item per
cycle.
My cycle goes something like this ...
Create and assign #1 to #4999
Create #5000
Destroy #1 to #4998
Assign #5000
Create and assign #5001 to #
Create #1
Destroy #5000 to #9998 --- Skipped #4999
Assign #1
Create and assign #10001 to #14999
Create #15000
Destroy #1 to #14998 --- Skipped #
etc.
My code changes ...
class User {
protected
$profile, $usercount;
public function __construct ($usercount) {
echo str_pad($this->usercount = $usercount, 5, '0', STR_PAD_LEFT),
':#1',
PHP_EOL;
$this->profile = new UserProfile($this);
}
public function __destruct() {
echo str_pad($this->usercount, 5, '0', STR_PAD_LEFT), ':#3',
PHP_EOL;
}
}
class UserProfile {
private
$user;
public function __construct ($user) {
$this->user = $user;
}
}
for ($userid = 1; ; $userid++) {
$user = new User($userid);
echo str_pad($userid, 5, '0', STR_PAD_LEFT), ':#2', PHP_EOL;
// Same code as provided by Nate.
[2010-04-19 09:54:39] dmi...@php.net
Yeah. I confirm the problem. It looks like on each 100,000 iterations
PHP runs GC about 12 times. And on each GC run it looses 2 objects
referenced by $user. I'll try to fix it.
[2010-04-18 02:28:35] j...@php.net
I am unable to duplicate this behaviour using 5.3.2. The code given
below consistently uses 0.65 MB even up to 10 million iterations - I
pasted the output of up to 6 million, with the extended GC reporting
turned on:
profile = new UserProfile($this);
}
public function dispose() {
$this->profile->dispose();
$this->profile = null;
}
}
class UserProfile {
private $user;
public function __construct ($user) {
$this->user = $user;
}
public function dispose() {
$this->user = null;
}
}
for ($userid = 1; ; $userid++) {
if(isset($user)) {
$user->dispose();
}
$user = new User;
if ($userid % 10 == 0)
printf("memory usage after %s users: %s MB.\n",
number_format($userid), number_format(memory_get_usage() / 1024 / 1024,
2));
continue;
}
?>
memory usage after 100,000 users: 0.65 MB.
memory usage after 200,000 users: 0.65 MB.
memory usage after 300,000 users: 0.65 MB.
[snip]
memory usage after 5,700,000 users: 0.65 MB.
memory usage after 5,800,000 users: 0.65 MB.
memory usage after 5,900,000 users: 0.65 MB.
GC Statistics
-
Runs: 0
Collected: 0
Root buffer length: 0
Root buffer peak: 9
PossibleRemove from Marked
RootBuffered buffer grey
--- --
ZVAL16 7 7 0
ZOBJ 7784 1198 1198 0
[2010-01-05 19:31:01] nightstorm at tlen dot pl
I confirm, there is a true memory leak. Consider the following script,
where the references are unmounted manually with an extra dispose()
method:
profile = new UserProfile($this);
}
public function dispose()
{
$this->profile->dispose();
$this->profile = null;
} // end dispose();
}
class UserProfile {
private
[PHP-BUG] Bug #51897 [NEW]: LIBXML_NOWARNING does not suppress warnings when passed to xinclude().
From: rquadling
Operating system: Windows XP SP3
PHP version: 5.3.2
Package: DOM XML related
Bug Type: Bug
Bug description:LIBXML_NOWARNING does not suppress warnings when passed to
xinclude().
Description:
This issue is in relation to http://news.php.net/php.doc/969381854
Trying to standardise the documentation in relation to including class
synopsis,
I'm including constructor and destructor synopsis via an xinclude with an
pointer and a xfallback...
http://docbook.org/ns/docbook)
xpointer(id('class.datetime')/db:refentry/db:refsec...@role='description']/desce
ndant::db:destructorsynopsis[not(@role='procedural')])">
As there is no destructor for datetime, the fallback is used (which is
empty).
All would seem to be well.
The problem is that the xinclude processing generates a warning when using
the
online documentation editor - but not when I run this locally via phpdoc's
configure.
I've been supplied a test script (http://news.php.net/php.doc/969381870)
which
will generate the errors locally.
And so to the bug.
In the example the xinclude() call has no parameters.
Supplying LIBXML_NOWARNING does _NOT_ suppress the warnings.
To run the test script, you will need the doc-base/manual.xml file produced
by
running the doc-base/configure.php script (part of PHPDoc).
Test script:
---
load('doc-base/manual.xml', LIBXML_NOENT);
var_dump($doc->xinclude(LIBXML_NOWARNING));
var_dump($doc->validate());
?>
Expected result:
int(-1)
bool(true)
Actual result:
--
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.datetime')/db:refentry/db:refsec...@role='description']/desce
ndant::db:destructorsynopsis[not(@role='procedural')]) in - on line 4
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.datetimezone')/db:refentry/db:refsec...@role='description']/d
escendant::db:destructorsynopsis[not(@role='procedural')]) in - on line 4
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.dateinterval')/db:refentry/db:refsec...@role='description']/d
escendant::db:destructorsynopsis[not(@role='procedural')]) in - on line 4
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.dateperiod')/db:refentry/db:refsec...@role='description']/des
cendant::db:destructorsynopsis[not(@role='procedural')]) in - on line 4
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.dateperiod')/db:refentry/db:refsec...@role='description']/des
cendant::db:methodsynopsis[not(@role='procedural')]) in - on line 4
int(-1)
bool(true)
--
Edit bug report at http://bugs.php.net/bug.php?id=51897&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51897&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51897&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51897&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51897&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51897&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51897&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51897&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51897&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51897&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51897&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51897&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51897&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51897&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51897&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51897&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51897&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51897&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51897&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51897&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51897&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51897&r=mysqlcfg
[PHP-BUG] Bug #52576 [NEW]: Variable variables can create invalid variables.
From: rquadling
Operating system: Windows XP SP3
PHP version: 5.3.3
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Variable variables can create invalid variables.
Description:
It seems you can create a variable in $GLOBALS that is not accessible as a
normal variable.
I found this because I wanted to use variable variables to populate a
nested
array.
Jim Lucas, in http://news.php.net/php.general/307392, comments that the use
of
eval() may be appropriate in the case.
That aside, the entry that is created in $GLOBALS doesn't follow the rules
for
variable naming in
http://docs.php.net/manual/en/language.variables.basics.php,
namely that '[' and ']' are not valid variable names. I think this should
have t
least produced an E_WARNING.
So, with all of that, I'm not sure if this is a bug or a documentation
problem.
I certainly think it is an edge case.
Regards,
Richard Quadling.
Test script:
---
Array
(
[2] => Array
(
[3] => Inaccessible?
)
)
)
array(3) {
["GLOBALS"]=>
*RECURSION*
["a"]=>
string(10) "b[1][2][3]"
["b"]=>
array(1) {
[1]=>
array(1) {
[2]=>
array(1) {
[3]=>
string(13) "Inaccessible?"
}
}
}
}
Actual result:
--
Notice: Undefined variable: b in - on line 5
array(4) {
["GLOBALS"]=>
*RECURSION*
["a"]=>
string(10) "b[1][2][3]"
["b[1][2][3]"]=>
string(13) "Inaccessible?"
["php_errormsg"]=>
string(21) "Undefined variable: b"
}
--
Edit bug report at http://bugs.php.net/bug.php?id=52576&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52576&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52576&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52576&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52576&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52576&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52576&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52576&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52576&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52576&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52576&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52576&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52576&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52576&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52576&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52576&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52576&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52576&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52576&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52576&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52576&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52576&r=mysqlcfg
Bug #50383 [Com]: Exceptions thrown in __call / __callStatic do not include file and line in trace
Edit report at http://bugs.php.net/bug.php?id=50383&edit=1
ID: 50383
Comment by: rquadl...@php.net
Reported by: RQuadling at GMail dot com
Summary: Exceptions thrown in __call / __callStatic do not
include file and line in trace
Status: Closed
Type: Bug
Package: Scripting Engine problem
Operating System: *
PHP Version: 5.*, 6
Assigned To: felipe
New Comment:
Any chance of the win32 snapshots being turned on again?
Previous Comments:
[2010-03-07 03:17:14] fel...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2010-03-07 03:17:13] fel...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revision&revision=295913
Log: - Fixed bug #50383 (Exceptions thrown in __call / __callStatic do
not include file and line in trace)
[2009-12-04 12:47:57] j...@php.net
Simple test that works in all branches:
ThrowException();
}
try {
thrower();
} catch(Exception $e) {
var_dump($e->getTrace());
}
?>
[2009-12-04 12:15:47] rquadl...@php.net
It seems that __call exhibits the same issue.
Further, for sub-classes which allow cascading of __call/__callStatic,
the stack doesn't show the file/line for those.
Outputs ...
Exception Object
(
[message:protected] => Missing static method
'StaticThrowException'.
[string:Exception:private] =>
[code:protected] => 0
[file:protected] => Z:\myClass.php
[line:protected] => 4
[trace:Exception:private] => Array
(
[0] => Array
(
[file] => Z:\mySubClass.php
[line] => 6
[function] => __callStatic
[class] => myClass
[type] => ::
[args] => Array
(
[0] => StaticThrowException
[1] => Array
(
)
)
)
[1] => Array
(
[function] => __callStatic
[class] => mySubClass
[type] => ::
[args] => Array
(
[0] => StaticThrowException
[1] => Array
(
)
)
)
[2] => Array
(
[file] => Z:\missingstatictrace3.php
[line] => 5
[function] => StaticThrowException
[class] => mySubClass
[type] => ::
[args] => Array
(
)
)
[3] => Array
(
[file] => Z:\missingstatictrace3.php
[line] => 9
[function] => staticThrower
[args] => Array
(
)
)
)
[previous:Exception:private] =>
)
[2009-12-04 11:32:44] RQuadling at GMail dot com
Description:
An exception thrown in a __callStatic() method does not store the file
name or the line number in the trace.
Reproduce code:
---
getTrace());
}
Expected result:
Array
(
[0] => Array
(
[file] => Z:\missingstatictrace.php
[line] => 4
[function] => __callStatic
[class] => myClass
[type] => ::
[args] => Array
(
[0] => ThrowException
[1] => Array
(
)
)
)
[1] => Array
(
[file] => Z:\missingstatictrace.php
[line] => 9
[function] => ThrowException
[class] => myClass
[type] => ::
Bug #50271 [PATCH]: Windows hard coding of CMD / COMMAND.COM rather than envvar(COMSPEC)
Edit report at http://bugs.php.net/bug.php?id=50271&edit=1
ID: 50271
Patch added by: rquadl...@php.net
Reported by: RQuadling at GMail dot com
Summary: Windows hard coding of CMD / COMMAND.COM rather than
envvar(COMSPEC)
Status: Open
Type: Bug
Package: Program Execution
Operating System: win32 only - Windows XP SP3
PHP Version: 5.3SVN-2009-11-23 (SVN)
New Comment:
The following patch has been added/updated:
Patch Name: TSRM_Win32_COMSPEC.patch
Revision: 1269608726
URL:
http://bugs.php.net/patch-display.php?bug=50271&patch=TSRM_Win32_COMSPEC.patch&revision=1269608726
Previous Comments:
[2009-11-23 13:31:13] j...@php.net
FYI: In the future when a bug is clearly windows only, use os prefix
'win32 only -' to preserve my sanity..
[2009-11-23 13:15:31] RQuadling at GMail dot com
Description:
In http://lxr.php.net/source/TSRM/tsrm_win32.c#52, the shell to execute
is hardcoded.
This should be retrieved via GetEnvironmentVariable('COMSPEC', ...);
As such, any program called cmd.exe (or command.com for older, and now
unsupported by PHP, versions of windows) in a directory accessible via
the PATH _before_ the actual location of cmd.exe/command.com will be
loaded for the shell.
The environment variable "COMSPEC" (now known as "ComSpec", but is case
insensitive for Windows) by default includes the path.
Whilst this is not a series bug, it does mean PHP conforms to other
languages and applications that can invoke a console shell via COMSPEC,
rather than using a hard-coded name.
Considering that PHP doesn't support older versions of windows any
longer, the whole test on GetVersion() is also redundant.
--
Edit this bug report at http://bugs.php.net/bug.php?id=50271&edit=1
Bug #50271 [PATCH]: Windows hard coding of CMD / COMMAND.COM rather than envvar(COMSPEC)
Edit report at http://bugs.php.net/bug.php?id=50271&edit=1
ID: 50271
Patch added by: rquadl...@php.net
Reported by: RQuadling at GMail dot com
Summary: Windows hard coding of CMD / COMMAND.COM rather than
envvar(COMSPEC)
Status: Open
Type: Bug
Package: Program Execution
Operating System: win32 only - Windows XP SP3
PHP Version: 5.3SVN-2009-11-23 (SVN)
New Comment:
The following patch has been added/updated:
Patch Name: proc_open_COMSPEC.patch
Revision: 1269610539
URL:
http://bugs.php.net/patch-display.php?bug=50271&patch=proc_open_COMSPEC.patch&revision=1269610539
Previous Comments:
[2010-03-26 14:05:26] rquadl...@php.net
The following patch has been added/updated:
Patch Name: TSRM_Win32_COMSPEC.patch
Revision: 1269608726
URL:
http://bugs.php.net/patch-display.php?bug=50271&patch=TSRM_Win32_COMSPEC.patch&revision=1269608726
[2009-11-23 13:31:13] j...@php.net
FYI: In the future when a bug is clearly windows only, use os prefix
'win32 only -' to preserve my sanity..
[2009-11-23 13:15:31] RQuadling at GMail dot com
Description:
In http://lxr.php.net/source/TSRM/tsrm_win32.c#52, the shell to execute
is hardcoded.
This should be retrieved via GetEnvironmentVariable('COMSPEC', ...);
As such, any program called cmd.exe (or command.com for older, and now
unsupported by PHP, versions of windows) in a directory accessible via
the PATH _before_ the actual location of cmd.exe/command.com will be
loaded for the shell.
The environment variable "COMSPEC" (now known as "ComSpec", but is case
insensitive for Windows) by default includes the path.
Whilst this is not a series bug, it does mean PHP conforms to other
languages and applications that can invoke a console shell via COMSPEC,
rather than using a hard-coded name.
Considering that PHP doesn't support older versions of windows any
longer, the whole test on GetVersion() is also redundant.
--
Edit this bug report at http://bugs.php.net/bug.php?id=50271&edit=1
Bug #53166 [PATCH]: ZipArchive::addFile() is missing parameters in docs
Edit report at http://bugs.php.net/bug.php?id=53166&edit=1 ID: 53166 Patch added by: rquadl...@php.net Reported by:znarkus at gmail dot com Summary:ZipArchive::addFile() is missing parameters in docs Status: Assigned Type: Bug Package:Zip Related PHP Version:5.3.3 Assigned To:pajoye Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: php_zip.c__Reflection__Documentation Revision: 1291730797 URL: http://bugs.php.net/patch-display.php?bug=53166&patch=php_zip.c__Reflection__Documentation&revision=1291730797 Previous Comments: [2010-11-18 12:39:53] rquadl...@php.net New patch against 5.3 and trunk. [2010-10-27 15:52:34] rquadl...@php.net I've added a patch to this bug which I feel fixes the reflection/prototype issues in php_zip.c (branch/5.3) If it could be reviewed and committed, then I can get the documentation in agreement with this. [2010-10-26 18:30:40] paj...@php.net Richard, also please use either the bug tracker or a direct mail, but not both. I will look at these as soon as possible (but t soon). [2010-10-26 18:25:45] phi...@php.net Assigning to Pierre, he should help investigate this. [2010-10-26 18:18:08] rquadl...@php.net There would also be an issue with ZipArchive::setArchiveComment, ZipArchive::getCommentIndex, ZipArchive::getCommentName, ZipArchive::getNameIndex(), ZipArchive::getFromName() and ZipArchive::getFromIndex(). None of these methods documented prototypes tie up with the actual parameters being reflected by the extension. Also, in some cases, the reflection doesn't tie up with the argument parsing in the C code. Whilst, on the surface, this looks like a documentation bug, I think that the underlying code should be fixed and then accurate documentation can be written from that. There are also missing function ZipArchive::addGlob() and ZipArchive::addPattern() are missing. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=53166 -- Edit this bug report at http://bugs.php.net/bug.php?id=53166&edit=1
Bug #53166 [PATCH]: ZipArchive::addFile() is missing parameters in docs
Edit report at http://bugs.php.net/bug.php?id=53166&edit=1 ID: 53166 Patch added by: rquadl...@php.net Reported by:znarkus at gmail dot com Summary:ZipArchive::addFile() is missing parameters in docs Status: Assigned Type: Bug Package:Zip Related PHP Version:5.3.3 Assigned To:pajoye Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: php_zip.c__Reflection__Documentation Revision: 1291730925 URL: http://bugs.php.net/patch-display.php?bug=53166&patch=php_zip.c__Reflection__Documentation&revision=1291730925 Previous Comments: [2010-12-07 15:06:37] rquadl...@php.net The following patch has been added/updated: Patch Name: php_zip.c__Reflection__Documentation Revision: 1291730797 URL: http://bugs.php.net/patch-display.php?bug=53166&patch=php_zip.c__Reflection__Documentation&revision=1291730797 [2010-11-18 12:39:53] rquadl...@php.net New patch against 5.3 and trunk. [2010-10-27 15:52:34] rquadl...@php.net I've added a patch to this bug which I feel fixes the reflection/prototype issues in php_zip.c (branch/5.3) If it could be reviewed and committed, then I can get the documentation in agreement with this. [2010-10-26 18:30:40] paj...@php.net Richard, also please use either the bug tracker or a direct mail, but not both. I will look at these as soon as possible (but t soon). [2010-10-26 18:25:45] phi...@php.net Assigning to Pierre, he should help investigate 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 http://bugs.php.net/bug.php?id=53166 -- Edit this bug report at http://bugs.php.net/bug.php?id=53166&edit=1
[PHP-BUG] Bug #53854 [NEW]: Missing constants for compression type.
From: rquadling Operating system: n/a PHP version: 5.3SVN-2011-01-27 (SVN) Package: Zip Related Bug Type: Bug Bug description:Missing constants for compression type. Description: ext/zip internally uses several constants to identify the nature of the compressed content. Not all of these are exposed, though one of them is documented (ZipArchive::CM_BZIP2). The attached patch for ext/zip/php_zip.c adds the missing constants. Once this is committed, I can update the documentation with the others (LZMA, TERSE, LZ77, WAVPACK and PPMD). -- Edit bug report at http://bugs.php.net/bug.php?id=53854&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53854&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53854&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53854&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53854&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53854&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53854&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53854&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53854&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53854&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53854&r=support Expected behavior: http://bugs.php.net/fix.php?id=53854&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53854&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53854&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53854&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53854&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53854&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53854&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53854&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53854&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53854&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53854&r=mysqlcfg
Bug #53854 [PATCH]: Missing constants for compression type.
Edit report at http://bugs.php.net/bug.php?id=53854&edit=1 ID: 53854 Patch added by: rquadl...@php.net Reported by:rquadl...@php.net Summary:Missing constants for compression type. Status: Open Type: Bug Package:Zip Related Operating System: n/a PHP Version:5.3SVN-2011-01-27 (SVN) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: missing_zip_constants.patch Revision: 1296136529 URL: http://bugs.php.net/patch-display.php?bug=53854&patch=missing_zip_constants.patch&revision=1296136529 Previous Comments: [2011-01-27 14:54:59] rquadl...@php.net Description: ext/zip internally uses several constants to identify the nature of the compressed content. Not all of these are exposed, though one of them is documented (ZipArchive::CM_BZIP2). The attached patch for ext/zip/php_zip.c adds the missing constants. Once this is committed, I can update the documentation with the others (LZMA, TERSE, LZ77, WAVPACK and PPMD). -- Edit this bug report at http://bugs.php.net/bug.php?id=53854&edit=1
[PHP-BUG] Bug #53856 [NEW]: zipArchive::addPattern requires path parameter
From: rquadling
Operating system: Windows XP SP3
PHP version: 5.3.5
Package: Zip Related
Bug Type: Bug
Bug description:zipArchive::addPattern requires path parameter
Description:
php --rf zipArchive::addPattern tells us that the path is optional. This is
confirmed by the parameter parsing.
But, at least on windows, if no path is supplied, with a pattern that will
include
everything, no files are added.
Setting the path to the current directory (for example) will include all
files in
that directory (using the same regex).
Test script:
---
open('./TestAddPattern.zip', ZIPARCHIVE::CREATE)) {
echo
'Add all files with no path param', PHP_EOL,
print_r($zip->addPattern('/.*/'), True), PHP_EOL,
'Number of files : ', $zip->numFiles, PHP_EOL,
'Add all files in current path param', PHP_EOL,
print_r($zip->addPattern('/.*/', '.'), True), PHP_EOL,
'Number of files : ', $zip->numFiles, PHP_EOL;
$zip->close();
}
Expected result:
Add all files with no path param
Array
(
[0] => .\25.BAT
...
[88] => .\upxit.bat
)
Number of files : 89
Add all files in current path param
Array
(
[0] => .\25.BAT
...
[88] => .\upxit.bat
)
Number of files : 178
Actual result:
--
Add all files with no path param
Number of files : 0
Add all files in current path param
Array
(
[0] => .\25.BAT
...
[88] => .\upxit.bat
)
Number of files : 89
--
Edit bug report at http://bugs.php.net/bug.php?id=53856&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53856&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53856&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53856&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53856&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53856&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53856&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53856&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53856&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53856&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53856&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53856&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53856&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53856&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53856&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53856&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53856&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53856&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53856&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53856&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53856&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53856&r=mysqlcfg
[PHP-BUG] Bug #53867 [NEW]: Test failure.
From: rquadling Operating system: Windows XP SP3 PHP version: 5.3SVN-2011-01-28 (SVN) Package: Zip Related Bug Type: Bug Bug description:Test failure. Description: The ext/zip/tests/stream_meta_data.phpt test fails on windows. The issue is in the URI test. zip:///%stest_with_comment.zip#foo I read this as ... stream zip:// root / path %s file#query test_with_comments.zip#foo On Windows the root is incorrect. It will be C: or D: (for example). As the path is picked up using %s, the attached patch should work on non-windows as well as windows. -- Edit bug report at http://bugs.php.net/bug.php?id=53867&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53867&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53867&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53867&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53867&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53867&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53867&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53867&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53867&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53867&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53867&r=support Expected behavior: http://bugs.php.net/fix.php?id=53867&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53867&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53867&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53867&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53867&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53867&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53867&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53867&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53867&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53867&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53867&r=mysqlcfg
Bug #49072 [PATCH]: feof never returns true for damaged file in zip
Edit report at http://bugs.php.net/bug.php?id=49072&edit=1 ID: 49072 Patch added by: rquadl...@php.net Reported by:TorokAlpar at Gmail dot com Summary:feof never returns true for damaged file in zip Status: Closed Type: Bug Package:Zip Related Operating System: Windows Xp, Linux PHP Version:5.3.0 Assigned To:rquadling Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: zip_stream_errors_reported.patch Revision: 1296562807 URL: http://bugs.php.net/patch-display.php?bug=49072&patch=zip_stream_errors_reported.patch&revision=1296562807 Previous Comments: [2011-02-01 13:19:29] rquadl...@php.net The test http://svn.php.net/viewvc/php/php-src/trunk/ext/zip/tests/bug49072.phpt is currently failing. >From what I can tell, the reason for the failure is that the when processing (http://svn.php.net/viewvc/php/php-src/trunk/ext/zip/zip_stream.c?view=annotate#l31), the return type from zip_fread (line 37) is cast to size_t. This is, at the most basic, an unsigned type. So, when comparing (n < 0), this will always be false. And so any errors recording during the zip_fread() call will fail to be passed on. Removing the casting and having n as type int, allows the test to pass and the appropriate error is generated. Patch attached. [2009-08-12 08:36:40] paj...@php.net Fixed in the pecl release 1.10.2 and patch applied to all branches (will be in php 5.2.11 and 5.3.1). [2009-08-11 17:11:02] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=287102 Log: - merge fix for php bug #49072 [2009-08-11 15:12:00] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=287095 Log: - fixed bug #49072, feof never returns true for damaged file in zip [2009-07-27 12:39:19] paj...@php.net Please send me the archive you used to reproduce this problem. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=49072 -- Edit this bug report at http://bugs.php.net/bug.php?id=49072&edit=1
Bug #55710 [PATCH]: win32 and devel directories not created by makefile.
Edit report at https://bugs.php.net/bug.php?id=55710&edit=1
ID: 55710
Patch added by: rquadl...@php.net
Reported by:RQuadling at GMail dot com
Summary:win32 and devel directories not created by makefile.
Status: Open
Type: Bug
Package:*Compile Issues
Operating System: Windows
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: missing_dirs.patch
Revision: 1316176068
URL:
https://bugs.php.net/patch-display.php?bug=55710&patch=missing_dirs.patch&revision=1316176068
Previous Comments:
[2011-09-16 12:27:19] rquadl...@php.net
Seems the ADD_FLAG() fix is all that is needed for the win32 directory.
New patch created.
[2011-09-16 12:11:49] RQuadling at GMail dot com
Description:
The win32 and devel directories are only created during configure.js.
If, after a success nmake, the release directory is deleted, the win32 and
devel
directories are not recreated.
win32 and devel is never added to BUILD_DIRS_SUB (via ADD_FLAGS).
Having added "win32" to the build_dirs array initialization, the win32
directory
will still fail to be created in a particular instance.
The ADD_FLAG routine uses indexOf() to determine if "win32" is already part of
the flags. If an extension containing the characters "win32" already exists
(pecl/win32service for example), then the "win32" check will fail and no
"win32"
will be added to BUILD_DIRS_SUB.
The "devel" directory is only added if !MODE_PHPIZE is true. But putting
ADD_FLAG("BUILD_DIRS_SUB", "devel"); in generate_phpize(); is too late as
generate_makefile(); has already been called.
I don't want to do too much with this as I'm not 100% sure, so the additional
test for "devel" has been added in the attached patch.
The supplied patch deals with these issues.
The end result is just that "win32" and, if appropriate "devel" are added to
BUILD_DIRS_SUB so a nmake will always create them if they are missing.
--
Edit this bug report at https://bugs.php.net/bug.php?id=55710&edit=1
[PHP-BUG] Bug #60312 [NEW]: CSS for example in a warning not aligned correctly.
From: rquadling Operating system: N/A PHP version: Irrelevant Package: Website problem Bug Type: Bug Bug description:CSS for example in a warning not aligned correctly. Description: Looking at http://www.php.net/manual/en/language.types.string.php#example-70, the code block is misaligned with the text. padding-left : 60px; solves this. -- Edit bug report at https://bugs.php.net/bug.php?id=60312&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60312&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60312&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60312&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60312&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60312&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60312&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60312&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60312&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60312&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60312&r=support Expected behavior: https://bugs.php.net/fix.php?id=60312&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60312&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60312&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60312&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60312&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60312&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60312&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60312&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60312&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60312&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60312&r=mysqlcfg
