#46374 [NEW]: Error-control operator does not suppress "undefined index" in set_error_handler
From: phpbugs at sevenlight dot com Operating system: Irrelevant PHP version: 5.3.0alpha2 PHP Bug Type: Scripting Engine problem Bug description: Error-control operator does not suppress "undefined index" in set_error_handler Description: A set_error_handler() callback is receiving an error code of 8 (E_NOTICE) for an undefined index, even though it has been suppressed by the @ operator. As per the documentation, the value of the error should be 0. Tested on 5.2 and 5.3. This is potentially just a documentation problem? I find that the error code could be useful even if it has been suppressed, therefore suggesting that an extra variable being passed to the callback notifying it whether or not the @ operator was used or not would be more useful. Reproduce code: --- Expected result: Error suppressed. Actual result: -- This should not happen (8). Error should have been suppressed: Undefined index: suppress-me -- Edit bug report at http://bugs.php.net/?id=46374&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46374&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46374&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46374&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46374&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46374&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46374&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46374&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46374&r=needscript Try newer version: http://bugs.php.net/fix.php?id=46374&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46374&r=support Expected behavior: http://bugs.php.net/fix.php?id=46374&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46374&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46374&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46374&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46374&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46374&r=dst IIS Stability: http://bugs.php.net/fix.php?id=46374&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46374&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46374&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46374&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46374&r=mysqlcfg
#46373 [Opn->Bgs]: Type-Hinting with namespaces does not work
ID: 46373
User updated by: phpbugs at sevenlight dot com
Reported By: phpbugs at sevenlight dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: OSX 10.5.5
PHP Version: 5.3CVS-2008-10-23 (snap)
New Comment:
Terribly sorry for wasting your time... set_error_handler() script was
hiding the errors... Again, sorry... :)
Previous Comments:
[2008-10-23 22:04:45] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Well, I can't reproduce it.
namespace MyNamespace;
class foo {
public function test(bla::foobar $a) {
}
}
$x = new foo;
#$x->test(new stdclass);
/*
Catchable fatal error: Argument 1 passed to MyNamespace::foo::test()
must be an instance of bla::foobar, instance of stdClass given ...
*/
#$x->test(NULL);
/*
Catchable fatal error: Argument 1 passed to MyNamespace::foo::test()
must be an instance of bla::foobar, null given, called in ...
*/
$reflect = new ReflectionClass(__NAMESPACE__ .'::foo');
$y = $reflect->getMethod('test');
#$y->invoke(new foo, 1);
/*
Catchable fatal error: Argument 1 passed to MyNamespace::foo::test()
must be an instance of bla::foobar, integer given
*/
[2008-10-23 21:46:47] phpbugs at sevenlight dot com
That is not the issue. The issue is that I DO NOT want NULLs to be
accepted, yet they are being accepted (ie. no error be thrown). The
issue is that I want an instance of Class A and if I pass it an instance
of Class B, it is still accepted (Class B is not a child of Class A).
The issue is if I pass ANY value of ANY kind if is accepted. The issue
is if I ask for a non-existant class, no error is thrown at all...
In all of these instances, errors should be thrown, but they are not
being thrown. This is why I am seeking advice as to why this might be
happening, and how I might be able to debug the actual PHP C code to
figure out what is wrong...
-Andrew
[2008-10-23 21:25:14] [EMAIL PROTECTED]
Using $x = new myclass; $x->execute();, i got:
Catchable fatal error: Argument 1 passed to
MyNamespace::MyClass::test() must be an instance of
MyBogusNamespace::MyBogusClass, null given, called ...
If you want accept NULL to be passed, it must be the default value to
the parameter.
public function test(MyBogusNamespace::MyBogusClass $m = NULL)
So, we will have...
Method [ public method test ] {
@@ ... 15 - 22
- Parameters [1] {
Parameter #0 [ MyBogusNamespace::MyBogusClass or NULL $m
= NULL ]
}
}
Thanks.
[2008-10-23 21:06:45] phpbugs at sevenlight dot com
Can nobody provide any assistance?
I realize I cannot provide a small test-case script, but that is
because this exact same script works fine in the smaller test cases. I
am looking for any advice as to how I can help track down the cause of
this bug. If I need to add some debugging code to the PHP source and
recompile, or something else, I'm willing to do this, I just need some
guidance. I've covered the extent of what I can come up with to test
out inside my PHP code itself, and the bug is at the point where I feel
that it would need some modifications to the PHP code for debugging
purposes, but I have no experience in debugging the PHP C code. I can
get around debugging C, but not debugging PHP in C.
I know your job is impossible without a test case, but please give me
some help in getting you a test case. The bug is obviously not simple
enough that a 10 line test case will trigger it (although maybe it can,
but I don't know how to yet).
Thank you,
-Andrew
[2008-10-23 20:54:21] [EMAIL PROTECTED]
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
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/46373
--
Edit this bug report at http://bugs.php.net/?id=46373&edit=1
#46373 [Bgs->Opn]: Type-Hinting with namespaces does not work
ID: 46373
Updated by: [EMAIL PROTECTED]
Reported By: phpbugs at sevenlight dot com
-Status: Bogus
+Status: Open
Bug Type: Scripting Engine problem
Operating System: OSX 10.5.5
PHP Version: 5.3CVS-2008-10-23 (snap)
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Well, I can't reproduce it.
namespace MyNamespace;
class foo {
public function test(bla::foobar $a) {
}
}
$x = new foo;
#$x->test(new stdclass);
/*
Catchable fatal error: Argument 1 passed to MyNamespace::foo::test()
must be an instance of bla::foobar, instance of stdClass given ...
*/
#$x->test(NULL);
/*
Catchable fatal error: Argument 1 passed to MyNamespace::foo::test()
must be an instance of bla::foobar, null given, called in ...
*/
$reflect = new ReflectionClass(__NAMESPACE__ .'::foo');
$y = $reflect->getMethod('test');
#$y->invoke(new foo, 1);
/*
Catchable fatal error: Argument 1 passed to MyNamespace::foo::test()
must be an instance of bla::foobar, integer given
*/
Previous Comments:
[2008-10-23 21:46:47] phpbugs at sevenlight dot com
That is not the issue. The issue is that I DO NOT want NULLs to be
accepted, yet they are being accepted (ie. no error be thrown). The
issue is that I want an instance of Class A and if I pass it an instance
of Class B, it is still accepted (Class B is not a child of Class A).
The issue is if I pass ANY value of ANY kind if is accepted. The issue
is if I ask for a non-existant class, no error is thrown at all...
In all of these instances, errors should be thrown, but they are not
being thrown. This is why I am seeking advice as to why this might be
happening, and how I might be able to debug the actual PHP C code to
figure out what is wrong...
-Andrew
[2008-10-23 21:25:14] [EMAIL PROTECTED]
Using $x = new myclass; $x->execute();, i got:
Catchable fatal error: Argument 1 passed to
MyNamespace::MyClass::test() must be an instance of
MyBogusNamespace::MyBogusClass, null given, called ...
If you want accept NULL to be passed, it must be the default value to
the parameter.
public function test(MyBogusNamespace::MyBogusClass $m = NULL)
So, we will have...
Method [ public method test ] {
@@ ... 15 - 22
- Parameters [1] {
Parameter #0 [ MyBogusNamespace::MyBogusClass or NULL $m
= NULL ]
}
}
Thanks.
[2008-10-23 21:06:45] phpbugs at sevenlight dot com
Can nobody provide any assistance?
I realize I cannot provide a small test-case script, but that is
because this exact same script works fine in the smaller test cases. I
am looking for any advice as to how I can help track down the cause of
this bug. If I need to add some debugging code to the PHP source and
recompile, or something else, I'm willing to do this, I just need some
guidance. I've covered the extent of what I can come up with to test
out inside my PHP code itself, and the bug is at the point where I feel
that it would need some modifications to the PHP code for debugging
purposes, but I have no experience in debugging the PHP C code. I can
get around debugging C, but not debugging PHP in C.
I know your job is impossible without a test case, but please give me
some help in getting you a test case. The bug is obviously not simple
enough that a 10 line test case will trigger it (although maybe it can,
but I don't know how to yet).
Thank you,
-Andrew
[2008-10-23 20:54:21] [EMAIL PROTECTED]
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
[2008-10-23 18:50:07] phpbugs at sevenlight dot com
Description:
Using a type-hint with a namespace does not work. It allows an object
of a different class to be passed, and even allows a bogus namespace to
be used. It will also allow null variables, and will pass through any
value, no matter what class type-hinting you use.
Unfortunately, in my simplest test cases I have not been able to
reproduce it, it is only in my larger project that it causes this
problem.
I really don't know where to start wit
#46373 [Bgs]: Type-Hinting with namespaces does not work
ID: 46373
User updated by: phpbugs at sevenlight dot com
Reported By: phpbugs at sevenlight dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: OSX 10.5.5
PHP Version: 5.3CVS-2008-10-23 (snap)
New Comment:
That is not the issue. The issue is that I DO NOT want NULLs to be
accepted, yet they are being accepted (ie. no error be thrown). The
issue is that I want an instance of Class A and if I pass it an instance
of Class B, it is still accepted (Class B is not a child of Class A).
The issue is if I pass ANY value of ANY kind if is accepted. The issue
is if I ask for a non-existant class, no error is thrown at all...
In all of these instances, errors should be thrown, but they are not
being thrown. This is why I am seeking advice as to why this might be
happening, and how I might be able to debug the actual PHP C code to
figure out what is wrong...
-Andrew
Previous Comments:
[2008-10-23 21:25:14] [EMAIL PROTECTED]
Using $x = new myclass; $x->execute();, i got:
Catchable fatal error: Argument 1 passed to
MyNamespace::MyClass::test() must be an instance of
MyBogusNamespace::MyBogusClass, null given, called ...
If you want accept NULL to be passed, it must be the default value to
the parameter.
public function test(MyBogusNamespace::MyBogusClass $m = NULL)
So, we will have...
Method [ public method test ] {
@@ ... 15 - 22
- Parameters [1] {
Parameter #0 [ MyBogusNamespace::MyBogusClass or NULL $m
= NULL ]
}
}
Thanks.
[2008-10-23 21:06:45] phpbugs at sevenlight dot com
Can nobody provide any assistance?
I realize I cannot provide a small test-case script, but that is
because this exact same script works fine in the smaller test cases. I
am looking for any advice as to how I can help track down the cause of
this bug. If I need to add some debugging code to the PHP source and
recompile, or something else, I'm willing to do this, I just need some
guidance. I've covered the extent of what I can come up with to test
out inside my PHP code itself, and the bug is at the point where I feel
that it would need some modifications to the PHP code for debugging
purposes, but I have no experience in debugging the PHP C code. I can
get around debugging C, but not debugging PHP in C.
I know your job is impossible without a test case, but please give me
some help in getting you a test case. The bug is obviously not simple
enough that a 10 line test case will trigger it (although maybe it can,
but I don't know how to yet).
Thank you,
-Andrew
[2008-10-23 20:54:21] [EMAIL PROTECTED]
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
[2008-10-23 18:50:07] phpbugs at sevenlight dot com
Description:
Using a type-hint with a namespace does not work. It allows an object
of a different class to be passed, and even allows a bogus namespace to
be used. It will also allow null variables, and will pass through any
value, no matter what class type-hinting you use.
Unfortunately, in my simplest test cases I have not been able to
reproduce it, it is only in my larger project that it causes this
problem.
I really don't know where to start with this, and how to duplicate it.
Needless to say, have provided the failing code from my project. The
entire project is several thousand lines of code. And I've really done
my best to track down the problem, even using the 5.3-alpha3-dev.
I'll include the code that causes the problem.
I really don't know what's wrong, and why it is doing it. Any hints as
to what I might be able to do to try to reproduce this in a simpler way
would be nice, but I really don't know where to go from here.
Reproduce code:
---
test(NULL);
return $this->_execute($this->_mc);
}
protected function test(MyBogusNamespace::MyBogusClass $m)
{
$reflect = new ReflectionClass(get_class($this));
$method = $reflect->getMethod('test');
echo $method;
var_export($m);
echo "\n\nClass: " . get_class($m) . " ==
MyBogusNamespace::MyBogusClass\n\n";
}
}
?>
Expected result:
Catchable fatal error: Argument 1 passed to
MyNamespace::MyClass::test() must be an instance of
MyBogusNamespace::MyBogusClass, null given, called in
/srv/www/test/ns/new.php on line 9 and defined in
/srv/www/test/ns/new.php on line 13
Actual result:
--
Method [ protected method test ] {
@@ /srv/spin/spin4/spinnaker/extender/universal/tablelibrary.php 73 -
8
#46360 [Csd->Tbd]: [PATCH] TCP_NODELAY constant for socket_{get,set}_option
ID: 46360
Updated by: [EMAIL PROTECTED]
Reported By: bugs at trick dot vanstaveren dot us
-Status: Closed
+Status: To be documented
Bug Type: Sockets related
Operating System: *
PHP Version: 5.2.6
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
http://news.php.net/php.cvs/53681
Previous Comments:
[2008-10-22 19:00:01] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2008-10-22 11:14:26] [EMAIL PROTECTED]
It exists on Windows, according to
http://msdn.microsoft.com/en-us/library/ms740476(VS.85).aspx
[2008-10-22 04:44:11] bugs at trick dot vanstaveren dot us
Description:
C-level TCP function setsockopt allows users of TCP sockets to set the
TCP_NODELAY flag. This flag disable's the typically default use of
Nagle's Algorithm[1] on a TCP socket.
1: http://en.wikipedia.org/wiki/Nagle%27s_algorithm
Nagle's Algorithm is bad for protocols like the extremely brief one
spoken by PHP/Java Bridge. This patch is inspired by my use of PJB on
FreeBSD which does not automatically set TCP_NODELAY on localhost
connections.
PHP does not expose this constant, although it is valid for the sockets
library as socket_set_option is a straightforward wrapper around
setsockopt.
Here is a trivial patch against PHP 5.2.5 to add the PHP constant
TCP_NODELAY. I have tested this on FreeBSD 7.0 + PHP 5.2.5. Patch is
quite simple so should apply fine against 5.3 / 6 with just a line
offset. Constant is the same on Linux so will work fine there; am not
sure about win32. Happy to test other versions and platforms if
necessary.
--- ext/sockets/sockets.c.orig 2008-10-21 22:53:07.0 +
+++ ext/sockets/sockets.c 2008-10-21 22:53:00.0 +
@@ -509,6 +509,7 @@
REGISTER_LONG_CONSTANT("SO_ERROR", SO_ERROR,
CONST_CS |
CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("SOL_SOCKET",SOL_SOCKET,
CONST_CS |
CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("SOMAXCONN", SOMAXCONN,
CONST_CS |
CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT("TCP_NODELAY", TCP_NODELAY,CONST_CS |
CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("PHP_NORMAL_READ", PHP_NORMAL_READ, CONST_CS |
CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("PHP_BINARY_READ", PHP_BINARY_READ, CONST_CS |
CONST_PERSISTENT);
Cheers,
Patrick van Staveren
--
Edit this bug report at http://bugs.php.net/?id=46360&edit=1
#46373 [Opn->Bgs]: Type-Hinting with namespaces does not work
ID: 46373
Updated by: [EMAIL PROTECTED]
Reported By: phpbugs at sevenlight dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: OSX 10.5.5
PHP Version: 5.3CVS-2008-10-23 (snap)
New Comment:
Using $x = new myclass; $x->execute();, i got:
Catchable fatal error: Argument 1 passed to
MyNamespace::MyClass::test() must be an instance of
MyBogusNamespace::MyBogusClass, null given, called ...
If you want accept NULL to be passed, it must be the default value to
the parameter.
public function test(MyBogusNamespace::MyBogusClass $m = NULL)
So, we will have...
Method [ public method test ] {
@@ ... 15 - 22
- Parameters [1] {
Parameter #0 [ MyBogusNamespace::MyBogusClass or NULL $m
= NULL ]
}
}
Thanks.
Previous Comments:
[2008-10-23 21:06:45] phpbugs at sevenlight dot com
Can nobody provide any assistance?
I realize I cannot provide a small test-case script, but that is
because this exact same script works fine in the smaller test cases. I
am looking for any advice as to how I can help track down the cause of
this bug. If I need to add some debugging code to the PHP source and
recompile, or something else, I'm willing to do this, I just need some
guidance. I've covered the extent of what I can come up with to test
out inside my PHP code itself, and the bug is at the point where I feel
that it would need some modifications to the PHP code for debugging
purposes, but I have no experience in debugging the PHP C code. I can
get around debugging C, but not debugging PHP in C.
I know your job is impossible without a test case, but please give me
some help in getting you a test case. The bug is obviously not simple
enough that a 10 line test case will trigger it (although maybe it can,
but I don't know how to yet).
Thank you,
-Andrew
[2008-10-23 20:54:21] [EMAIL PROTECTED]
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
[2008-10-23 18:50:07] phpbugs at sevenlight dot com
Description:
Using a type-hint with a namespace does not work. It allows an object
of a different class to be passed, and even allows a bogus namespace to
be used. It will also allow null variables, and will pass through any
value, no matter what class type-hinting you use.
Unfortunately, in my simplest test cases I have not been able to
reproduce it, it is only in my larger project that it causes this
problem.
I really don't know where to start with this, and how to duplicate it.
Needless to say, have provided the failing code from my project. The
entire project is several thousand lines of code. And I've really done
my best to track down the problem, even using the 5.3-alpha3-dev.
I'll include the code that causes the problem.
I really don't know what's wrong, and why it is doing it. Any hints as
to what I might be able to do to try to reproduce this in a simpler way
would be nice, but I really don't know where to go from here.
Reproduce code:
---
test(NULL);
return $this->_execute($this->_mc);
}
protected function test(MyBogusNamespace::MyBogusClass $m)
{
$reflect = new ReflectionClass(get_class($this));
$method = $reflect->getMethod('test');
echo $method;
var_export($m);
echo "\n\nClass: " . get_class($m) . " ==
MyBogusNamespace::MyBogusClass\n\n";
}
}
?>
Expected result:
Catchable fatal error: Argument 1 passed to
MyNamespace::MyClass::test() must be an instance of
MyBogusNamespace::MyBogusClass, null given, called in
/srv/www/test/ns/new.php on line 9 and defined in
/srv/www/test/ns/new.php on line 13
Actual result:
--
Method [ protected method test ] {
@@ /srv/spin/spin4/spinnaker/extender/universal/tablelibrary.php 73 -
80
- Parameters [1] {
Parameter #0 [ MyBogusNamespace::MyBogusClass $m ]
}
}
NULL
== MyBogusNamespace::MyBogusClass
--
Edit this bug report at http://bugs.php.net/?id=46373&edit=1
#46373 [Bgs->Opn]: Type-Hinting with namespaces does not work
ID: 46373
Updated by: [EMAIL PROTECTED]
Reported By: phpbugs at sevenlight dot com
-Status: Bogus
+Status: Open
Bug Type: Scripting Engine problem
Operating System: OSX 10.5.5
PHP Version: 5.3CVS-2008-10-23 (snap)
Previous Comments:
[2008-10-23 21:06:45] phpbugs at sevenlight dot com
Can nobody provide any assistance?
I realize I cannot provide a small test-case script, but that is
because this exact same script works fine in the smaller test cases. I
am looking for any advice as to how I can help track down the cause of
this bug. If I need to add some debugging code to the PHP source and
recompile, or something else, I'm willing to do this, I just need some
guidance. I've covered the extent of what I can come up with to test
out inside my PHP code itself, and the bug is at the point where I feel
that it would need some modifications to the PHP code for debugging
purposes, but I have no experience in debugging the PHP C code. I can
get around debugging C, but not debugging PHP in C.
I know your job is impossible without a test case, but please give me
some help in getting you a test case. The bug is obviously not simple
enough that a 10 line test case will trigger it (although maybe it can,
but I don't know how to yet).
Thank you,
-Andrew
[2008-10-23 20:54:21] [EMAIL PROTECTED]
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
[2008-10-23 18:50:07] phpbugs at sevenlight dot com
Description:
Using a type-hint with a namespace does not work. It allows an object
of a different class to be passed, and even allows a bogus namespace to
be used. It will also allow null variables, and will pass through any
value, no matter what class type-hinting you use.
Unfortunately, in my simplest test cases I have not been able to
reproduce it, it is only in my larger project that it causes this
problem.
I really don't know where to start with this, and how to duplicate it.
Needless to say, have provided the failing code from my project. The
entire project is several thousand lines of code. And I've really done
my best to track down the problem, even using the 5.3-alpha3-dev.
I'll include the code that causes the problem.
I really don't know what's wrong, and why it is doing it. Any hints as
to what I might be able to do to try to reproduce this in a simpler way
would be nice, but I really don't know where to go from here.
Reproduce code:
---
test(NULL);
return $this->_execute($this->_mc);
}
protected function test(MyBogusNamespace::MyBogusClass $m)
{
$reflect = new ReflectionClass(get_class($this));
$method = $reflect->getMethod('test');
echo $method;
var_export($m);
echo "\n\nClass: " . get_class($m) . " ==
MyBogusNamespace::MyBogusClass\n\n";
}
}
?>
Expected result:
Catchable fatal error: Argument 1 passed to
MyNamespace::MyClass::test() must be an instance of
MyBogusNamespace::MyBogusClass, null given, called in
/srv/www/test/ns/new.php on line 9 and defined in
/srv/www/test/ns/new.php on line 13
Actual result:
--
Method [ protected method test ] {
@@ /srv/spin/spin4/spinnaker/extender/universal/tablelibrary.php 73 -
80
- Parameters [1] {
Parameter #0 [ MyBogusNamespace::MyBogusClass $m ]
}
}
NULL
== MyBogusNamespace::MyBogusClass
--
Edit this bug report at http://bugs.php.net/?id=46373&edit=1
#46373 [Bgs]: Type-Hinting with namespaces does not work
ID: 46373
User updated by: phpbugs at sevenlight dot com
Reported By: phpbugs at sevenlight dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: OSX 10.5.5
PHP Version: 5.3CVS-2008-10-23 (snap)
New Comment:
Can nobody provide any assistance?
I realize I cannot provide a small test-case script, but that is
because this exact same script works fine in the smaller test cases. I
am looking for any advice as to how I can help track down the cause of
this bug. If I need to add some debugging code to the PHP source and
recompile, or something else, I'm willing to do this, I just need some
guidance. I've covered the extent of what I can come up with to test
out inside my PHP code itself, and the bug is at the point where I feel
that it would need some modifications to the PHP code for debugging
purposes, but I have no experience in debugging the PHP C code. I can
get around debugging C, but not debugging PHP in C.
I know your job is impossible without a test case, but please give me
some help in getting you a test case. The bug is obviously not simple
enough that a 10 line test case will trigger it (although maybe it can,
but I don't know how to yet).
Thank you,
-Andrew
Previous Comments:
[2008-10-23 20:54:21] [EMAIL PROTECTED]
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
[2008-10-23 18:50:07] phpbugs at sevenlight dot com
Description:
Using a type-hint with a namespace does not work. It allows an object
of a different class to be passed, and even allows a bogus namespace to
be used. It will also allow null variables, and will pass through any
value, no matter what class type-hinting you use.
Unfortunately, in my simplest test cases I have not been able to
reproduce it, it is only in my larger project that it causes this
problem.
I really don't know where to start with this, and how to duplicate it.
Needless to say, have provided the failing code from my project. The
entire project is several thousand lines of code. And I've really done
my best to track down the problem, even using the 5.3-alpha3-dev.
I'll include the code that causes the problem.
I really don't know what's wrong, and why it is doing it. Any hints as
to what I might be able to do to try to reproduce this in a simpler way
would be nice, but I really don't know where to go from here.
Reproduce code:
---
test(NULL);
return $this->_execute($this->_mc);
}
protected function test(MyBogusNamespace::MyBogusClass $m)
{
$reflect = new ReflectionClass(get_class($this));
$method = $reflect->getMethod('test');
echo $method;
var_export($m);
echo "\n\nClass: " . get_class($m) . " ==
MyBogusNamespace::MyBogusClass\n\n";
}
}
?>
Expected result:
Catchable fatal error: Argument 1 passed to
MyNamespace::MyClass::test() must be an instance of
MyBogusNamespace::MyBogusClass, null given, called in
/srv/www/test/ns/new.php on line 9 and defined in
/srv/www/test/ns/new.php on line 13
Actual result:
--
Method [ protected method test ] {
@@ /srv/spin/spin4/spinnaker/extender/universal/tablelibrary.php 73 -
80
- Parameters [1] {
Parameter #0 [ MyBogusNamespace::MyBogusClass $m ]
}
}
NULL
== MyBogusNamespace::MyBogusClass
--
Edit this bug report at http://bugs.php.net/?id=46373&edit=1
#42616 [Com]: CLI crashes
ID: 42616 Comment by: isaac_dot_q_dot_dupont at gmail dot com Reported By: ashish_chap at yahoo dot co dot in Status: No Feedback Bug Type: CGI related Operating System: Windows XP PHP Version: 5.2.4 New Comment: I was receiving similar errors, except they were not fatal. Changing the PHP error handling in php.ini to error_reporting = E_ERROR made them go away (since they were non-fatal). Previous Comments: [2008-09-16 22:39:44] andrew at mercuric dot net It only happens, however, when the installer is used. Extracting the zip file works fine. [2008-09-16 21:30:17] andrew at mercuric dot net I also have this problem with both 5.2.6 and the latest snapshot on Windows XP 64-bit. I made sure that everything was deleted before running the snapshot installer. Neither disabling php_sam nor php_threads fixed the crash, though it does eliminate the "fatal error" message. [2008-05-02 23:47:16] uncle_coolj at hotmail dot com Hey, i've tried to disable different modules to find out which one causes the crash. I've found out that the "php_threads.dll" is the problem. if you comment out the module it works... best regards [2007-10-12 20:51:13] robert2s at hotmail dot com I solved this in the following way. In the php.ini file, add a semicolon (;) in front of the line extension=php_sam.dl [2007-09-24 00:19:42] mburke at cordovabay dot com I am having the same problem. The configuration is: Apache 2.2.4 (Win32) PHP 5.2.4 MySQL 5.0.45 All php pages result in error 500 error log shows: PHP Warning: require_once(SAM/php_sam.php): failed to open stream: No such file or directory in sam_factory on line 1 each time a php page is requested. Any help would be appreciated!! 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/42616 -- Edit this bug report at http://bugs.php.net/?id=42616&edit=1
#46373 [Opn->Bgs]: Type-Hinting with namespaces does not work
ID: 46373
Updated by: [EMAIL PROTECTED]
Reported By: phpbugs at sevenlight dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: OSX 10.5.5
PHP Version: 5.3CVS-2008-10-23 (snap)
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
Previous Comments:
[2008-10-23 18:50:07] phpbugs at sevenlight dot com
Description:
Using a type-hint with a namespace does not work. It allows an object
of a different class to be passed, and even allows a bogus namespace to
be used. It will also allow null variables, and will pass through any
value, no matter what class type-hinting you use.
Unfortunately, in my simplest test cases I have not been able to
reproduce it, it is only in my larger project that it causes this
problem.
I really don't know where to start with this, and how to duplicate it.
Needless to say, have provided the failing code from my project. The
entire project is several thousand lines of code. And I've really done
my best to track down the problem, even using the 5.3-alpha3-dev.
I'll include the code that causes the problem.
I really don't know what's wrong, and why it is doing it. Any hints as
to what I might be able to do to try to reproduce this in a simpler way
would be nice, but I really don't know where to go from here.
Reproduce code:
---
test(NULL);
return $this->_execute($this->_mc);
}
protected function test(MyBogusNamespace::MyBogusClass $m)
{
$reflect = new ReflectionClass(get_class($this));
$method = $reflect->getMethod('test');
echo $method;
var_export($m);
echo "\n\nClass: " . get_class($m) . " ==
MyBogusNamespace::MyBogusClass\n\n";
}
}
?>
Expected result:
Catchable fatal error: Argument 1 passed to
MyNamespace::MyClass::test() must be an instance of
MyBogusNamespace::MyBogusClass, null given, called in
/srv/www/test/ns/new.php on line 9 and defined in
/srv/www/test/ns/new.php on line 13
Actual result:
--
Method [ protected method test ] {
@@ /srv/spin/spin4/spinnaker/extender/universal/tablelibrary.php 73 -
80
- Parameters [1] {
Parameter #0 [ MyBogusNamespace::MyBogusClass $m ]
}
}
NULL
== MyBogusNamespace::MyBogusClass
--
Edit this bug report at http://bugs.php.net/?id=46373&edit=1
#44135 [Com]: PDO MySQL does not support CLIENT_FOUND_ROWS
ID: 44135
Comment by: chx1975 at gmail dot com
Reported By: chx1975 at gmail dot com
Status: Assigned
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.2.5
Assigned To: johannes
New Comment:
I renamed it to what MySQL calls it. Please just drop the defines then,
I copied them from mysql_com.h -- sorry, I am a n00b in doing this.
Please also drop any client flags you do not feel useful.
Previous Comments:
[2008-10-23 13:25:24] [EMAIL PROTECTED]
Thanks for the patch, a few comments/questions:
- Why are you renaming the connect_opts variable? Any particular
reason?
- You shouldn't use the numeric values, as they might change, but the
values provided by the client library, this also ensures that only flags
supported by the library are being used.
- I think the SSL flag won't work without specific SSL certs & stuff,
but I have to check that myself
[2008-10-23 01:34:27] chx1975 at gmail dot com
An attempt to fix this can be found at
http://drupal4hu.com/php-44135.patch . I added a number of flags not
just the one I needed.
running
PDO::MYSQL_CLIENT_FOUND_ROWS));
$p->exec('TRUNCATE a');
$p->exec('INSERT INTO a VALUES (1)');
echo $p->exec('UPDATE a SET a = 1 WHERE a = 1');
$p = new PDO('mysql:host=localhost;dbname=test', 'root', '');
echo $p->exec('UPDATE a SET a = 1 WHERE a = 1');
?>
shows a 1 (one row found) and then a 0 (0 updated) so the patch seems
to work.
[2008-02-16 03:29:44] larry at garfieldtech dot com
I can duplicate this problem. The issue appears to be that by
default, MySQL will return the number of affected rows from a
previous UPDATE statement, not the number of matched rows. That
values will differ if the update statement would set a row to its
existing value. With ext/mysql and ext/mysqli, it can be set to
return matched rows instead. PDO does not appear to have a way to
allow that.
[2008-02-16 03:26:34] chx1975 at gmail dot com
Description:
mysql_real_connect supports client flags
http://dev.mysql.com/doc/refman/4.1/en/mysql-real-connect.html most
importantly CLIENT_FOUND_ROWS but PDO provides no way to pass it in.
--
Edit this bug report at http://bugs.php.net/?id=44135&edit=1
#43925 [Asn->Csd]: Incorrect argument counter in prepared statements with pgsql
ID: 43925
Updated by: [EMAIL PROTECTED]
Reported By: pronoia at beibob dot de
-Status: Assigned
+Status: Closed
Bug Type: PDO related
Operating System: FreeBSD 6.3
PHP Version: 5.2.5
Assigned To: felipe
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2008-01-24 00:11:58] pronoia at beibob dot de
Description:
Executing a prepared statement that includes identical named
placeholders among others breaks postgresql's PREPARE command.
PDO->prepare does not translate the number of unique placeholders in
the statement correctly. Looks like it increments the argument number on
the basis of the placeholder's position index instead using an unique
index (see therefor pgsql log entries in the actual result section).
pdo_pgsql
My postgresql version is 8.2.5
Reproduce code:
---
Table Setup
CREATE TABLE nodes
(
id integer NOT NULL PRIMARY KEY
, root integer NOT NULL
, lft integer NOT NULL
, rgt integer NOT NULL
);
INSERT INTO nodes (id, root, lft, rgt) VALUES (1, 1, 1, 6);
INSERT INTO nodes (id, root, lft, rgt) VALUES (2, 1, 2, 3);
INSERT INTO nodes (id, root, lft, rgt) VALUES (3, 1, 4, 5);
// Assumes that $Dbh is pdo object
// Let pgsql log all statements, so we can see the prepared statement
as it is seen by the postgresql server
$Dbh->query("SET log_statement = 'all'");
$Stmt = $Dbh->prepare('SELECT * FROM nodes WHERE (lft > :left OR rgt >
:left) AND root = :rootId');
$Stmt->bindValue('left', 1, PDO::PARAM_INT);
$Stmt->bindValue('rootId', 1, PDO::PARAM_INT);
if (!$Stmt->execute())
print_r($Stmt->errorInfo());
// And a second one to get it clearly
$Stmt = $Dbh->prepare('SELECT * FROM nodes WHERE (lft > :left OR rgt >
:left OR rgt > :left) AND root = :rootId');
$Stmt->bindValue('left', 1, PDO::PARAM_INT);
$Stmt->bindValue('rootId', 1, PDO::PARAM_INT);
if (!$Stmt->execute())
print_r($Stmt->errorInfo());
Expected result:
no error
In the pgsql log:
STATEMENT: SELECT * FROM nodes WHERE (lft > $1 OR rgt > $1) AND root =
$2
STATEMENT: SELECT * FROM nodes WHERE (lft > $1 OR rgt > $1 OR rgt > $1)
AND root = $2
Actual result:
--
Array
(
[0] => 42P18
[1] => 7
[2] => ERROR: could not determine data type of parameter $2
)
Array
(
[0] => 42P18
[1] => 7
[2] => ERROR: could not determine data type of parameter $2
)
And in the pgsql log:
STATEMENT: SELECT * FROM nodes WHERE (lft > $1 OR rgt > $1) AND root =
$3
STATEMENT: SELECT * FROM nodes WHERE (lft > $1 OR rgt > $1 OR rgt > $1)
AND root = $4
--
Edit this bug report at http://bugs.php.net/?id=43925&edit=1
#46373 [NEW]: Type-Hinting with namespaces does not work
From: phpbugs at sevenlight dot com
Operating system: OSX 10.5.5
PHP version: 5.3CVS-2008-10-23 (snap)
PHP Bug Type: Scripting Engine problem
Bug description: Type-Hinting with namespaces does not work
Description:
Using a type-hint with a namespace does not work. It allows an object of
a different class to be passed, and even allows a bogus namespace to be
used. It will also allow null variables, and will pass through any value,
no matter what class type-hinting you use.
Unfortunately, in my simplest test cases I have not been able to reproduce
it, it is only in my larger project that it causes this problem.
I really don't know where to start with this, and how to duplicate it.
Needless to say, have provided the failing code from my project. The
entire project is several thousand lines of code. And I've really done my
best to track down the problem, even using the 5.3-alpha3-dev.
I'll include the code that causes the problem.
I really don't know what's wrong, and why it is doing it. Any hints as to
what I might be able to do to try to reproduce this in a simpler way would
be nice, but I really don't know where to go from here.
Reproduce code:
---
test(NULL);
return $this->_execute($this->_mc);
}
protected function test(MyBogusNamespace::MyBogusClass $m)
{
$reflect = new ReflectionClass(get_class($this));
$method = $reflect->getMethod('test');
echo $method;
var_export($m);
echo "\n\nClass: " . get_class($m) . " ==
MyBogusNamespace::MyBogusClass\n\n";
}
}
?>
Expected result:
Catchable fatal error: Argument 1 passed to MyNamespace::MyClass::test()
must be an instance of MyBogusNamespace::MyBogusClass, null given, called
in /srv/www/test/ns/new.php on line 9 and defined in
/srv/www/test/ns/new.php on line 13
Actual result:
--
Method [ protected method test ] {
@@ /srv/spin/spin4/spinnaker/extender/universal/tablelibrary.php 73 -
80
- Parameters [1] {
Parameter #0 [ MyBogusNamespace::MyBogusClass $m ]
}
}
NULL
== MyBogusNamespace::MyBogusClass
--
Edit bug report at http://bugs.php.net/?id=46373&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46373&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46373&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46373&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46373&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46373&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46373&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46373&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46373&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46373&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46373&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46373&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46373&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46373&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46373&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46373&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46373&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46373&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46373&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46373&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46373&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46373&r=mysqlcfg
#45234 [Opn]: Incorrect Content-Length header
ID: 45234
User updated by: kulakov74 at yandex dot ru
Reported By: kulakov74 at yandex dot ru
Status: Open
Bug Type: Zlib Related
Operating System: Linux
PHP Version: 5.2CVS-2008-06-11 (snap)
New Comment:
The line "phpinfo() output this:" should be ignored.
Previous Comments:
[2008-10-23 13:07:43] kulakov74 at yandex dot ru
I'm very sorry, I cannot go into the trouble of installing PHP, all I
could was check the bug with PHP 5.2.6 where it still was found.
phpinfo() output this:
This is not the latest release definitely.
The test script I used was this:
If the number 24 is changed to 24000 the header is fine (changed
from 24000 to some 5K value), and if it not the header is not correct
(remains 24).
[2008-10-23 12:29:03] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2008-06-11 11:03:49] kulakov74 at yandex dot ru
Description:
Many pointed out to the problem that the Content-Length header may have
incorrect value when using zlib.output_compression. This problem may
have been fixed but not completely. When the compressed data fits within
8K Content-Length is sent by zlib after compression and hence the header
(if present) is updated correctly, but when the compressed data is
larger no Content-Length is sent by zlib and hence the value is not
fixed. 8K is the default buffer size for zlib (mod_deflate) and is not
configurable. Anyway, whatever the size of the buffer is, I think the
initial Content-Length should be removed when zlib cannot determine the
size of the compressed data in advance.
The following bugs are related:
http://bugs.php.net/bug.php?id=28460
http://bugs.php.net/bug.php?id=22143
http://bugs.php.net/bug.php?id=24083
I guess many pages compress to more than 8K.
Reproduce code:
---
$FileToSend="filename.txt";
header("Content-Length: ".filesize($FileToSend));
readfile($FileToSend);
Expected result:
Content-Length header with the right value or removed.
Actual result:
--
Content-Length header with the same value I set. Note that the file
that is sent should COMPRESS to more than 8K in order for this to show.
It may be 25K and the problem will not show up.
--
Edit this bug report at http://bugs.php.net/?id=45234&edit=1
#37575 [NoF->Fbk]: Faulting application w3wp.exe
ID: 37575 Updated by: [EMAIL PROTECTED] Reported By: richardvernooij at yahoo dot com -Status: No Feedback +Status: Feedback Bug Type: IIS related Operating System: Windows 2003 server PHP Version: 5.1.4 -Assigned To: +Assigned To: pajoye New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. I would also suggest to use FastCGI instead (fcgi is available for IIS 6 and 7). Previous Comments: [2008-10-23 14:11:04] roberto at v-servers dot it I forgot to add to my previous comment that this happen using php 5 as ISAPI, I am not sure if it happen also using it as CGI like I have done on the other server so maybe is a bug that happen only when PHP 5 is installed as ISAPI. This should be fixed because ISAPI run much faster than CGI also CGI use much more of the server CPU resources which can be a problem when you have many websites run on php. [2008-10-23 13:46:04] roberto at v-servers dot it Hi, I have the same problem with w3wp.exe crashing after a website run page in php 5.2.6 On this website I have Joomla 1.5 installed, the website work but the web server which is IIS6 on windows 2003 server enterprise report all these errors every time a website with php run. Event Type: Error Event Source: Application Error Event Category: (100) Event ID: 1000 Date: 20/10/2008 Time: 18.01.11 User: N/A Computer: VSS Description: Faulting application w3wp.exe, version 6.0.3790.3959, faulting module w3core.dll, version 6.0.3790.3959, fault address 0x000201b4. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Data: : 41 70 70 6c 69 63 61 74 Applicat 0008: 69 6f 6e 20 46 61 69 6c ion Fail 0010: 75 72 65 20 20 77 33 77 ure w3w 0018: 70 2e 65 78 65 20 36 2e p.exe 6. 0020: 30 2e 33 37 39 30 2e 33 0.3790.3 0028: 39 35 39 20 69 6e 20 77 959 in w 0030: 33 63 6f 72 65 2e 64 6c 3core.dl 0038: 6c 20 36 2e 30 2e 33 37 l 6.0.37 0040: 39 30 2e 33 39 35 39 20 90.3959 0048: 61 74 20 6f 66 66 73 65 at offse 0050: 74 20 30 30 30 32 30 31 t 000201 0058: 62 34 b4 Is there any way to fix this or a PHP version that work without problem on IIS6? I am using php 4 on windows 2000 since 4 years without any problems. [2008-04-15 12:55:52] pranay dot vanjare at zenithinfotech dot com I HAVE WINDOWS 2003 SERVER RC2 WITH 4G.B RAM XEON SYSTEM. I REGULARLY GET ONE ERROR IN W3WP.EXE FILE (REFERANCE MEMORY AT 0x01e7e8fo MEMORY COULD NOT BE READ) CAN U PLEASE HELP ME IN THAT BECAUSE THIS SERVER IS VERY CRITICAL FOR US. [2007-12-28 21:25:47] masssheltie at hotmail dot com Found this posting buried on a development web site. David Wang et al possibly figured out the reason for the problem. >This is a bug in the PHP ISAPI DLL during DLL unload. It is trying to > double-free a piece of memory. When you recycle the Application Pool, > it causes the w3wp.exe to shutdown and unload all ISAPI DLLs, hence > triggering the PHP bug. > > The crash happen regardless of the IIS Application Pool identity. > > This should just be reported to PHP as a bug. You can recreate the problem by accessing any PHP script, and then recycling the applications pool associated with the web page in IIS. The recycling will cause the error, and will log same in the Event Viewer. I've not heard any formal plans to cope with this as of yet. [2007-04-06 06:02:53] chrisjx at gmail dot com Having the very similar problems. Now have Server 2003 sp2 installed still a problem. The variation I'm having is that I get the error perhaps 6 times whenever I re-boot. Then all is well and everything seems to work fine. I went into PHP.INI and commented out the only extension I had, php_mysql.dll, rebooted and the problem no longer occurs. However w/o this extension installed all is kaput... I know, I see the note not to say "this is how I solved it" or "this might help you" and I suppose you might delete this, but I had to try. I've had this problem since I installed 5.1.4 and I doubt it is "bogus". Event Log: Reporting queued error: faulting application w3wp.exe, version 6.0.379
#46370 [Bgs]: translation mixup
ID: 46370 User updated by: nikitin at freshframes dot com Reported By: nikitin at freshframes dot com Status: Bogus Bug Type: Filesystem function related Operating System: debian 4.0 PHP Version: 5.2.6 New Comment: ok, i just figured out the problem, seems i encode the files twice to utf8.. now i removed all encodings and the file is uploaded in latin1. once encoded it compares data like i need with mysql utf8 columns. so, this here is fixed and may be closed. sorry and thanks for your support. Previous Comments: [2008-10-23 13:43:57] nikitin at freshframes dot com i am pretty sure, that i use utf8 in the upload page. my framework is joomla and it uses utf8 when i download the uploaded file the umlauts are corrupted -> utf8 encoded so there is still the question why i need to encode it in php again. [2008-10-23 12:09:30] [EMAIL PROTECTED] If you upload as latin1 it's stored as latin1, set your charsets properly in the upload page and it works as expected. (fyi: file_get_contents doesn't convert anything to anything, it's binary safe) [2008-10-23 11:17:55] nikitin at freshframes dot com Description: i upload a latin1 file to the debian server (move_uploaded_file) this file is stored in utf8 (using utf8 translation in putty shows me correct chars, using latin1 translation shows me the multibyte chars...) then i read the file into a var via file_get_contents and wonder why mb_check_encoding( var, "UTF-8" ) returns false. sending the var via browser to client with utf8 charset produces wrong data, so i probably have latin1 data in my var. now i use utf8_encode( var ) and everything works fine. what do i need to set to get utf8 data from file reads, or why do i need to encode it again? Reproduce code: --- move_uploaded_file( $_FILES['file']['tmp_name'][0], $file ); $data = file_get_contents( $file ); var_dump( array( mb_check_encoding( $data, "UTF-8" ), mb_check_encoding( utf8_encode( $data ), "UTF-8" ) ); Expected result: [ true, true ] Actual result: -- [ false, true ] -- Edit this bug report at http://bugs.php.net/?id=46370&edit=1
#37575 [Com]: Faulting application w3wp.exe
ID: 37575 Comment by: roberto at v-servers dot it Reported By: richardvernooij at yahoo dot com Status: No Feedback Bug Type: IIS related Operating System: Windows 2003 server PHP Version: 5.1.4 New Comment: I forgot to add to my previous comment that this happen using php 5 as ISAPI, I am not sure if it happen also using it as CGI like I have done on the other server so maybe is a bug that happen only when PHP 5 is installed as ISAPI. This should be fixed because ISAPI run much faster than CGI also CGI use much more of the server CPU resources which can be a problem when you have many websites run on php. Previous Comments: [2008-10-23 13:46:04] roberto at v-servers dot it Hi, I have the same problem with w3wp.exe crashing after a website run page in php 5.2.6 On this website I have Joomla 1.5 installed, the website work but the web server which is IIS6 on windows 2003 server enterprise report all these errors every time a website with php run. Event Type: Error Event Source: Application Error Event Category: (100) Event ID: 1000 Date: 20/10/2008 Time: 18.01.11 User: N/A Computer: VSS Description: Faulting application w3wp.exe, version 6.0.3790.3959, faulting module w3core.dll, version 6.0.3790.3959, fault address 0x000201b4. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Data: : 41 70 70 6c 69 63 61 74 Applicat 0008: 69 6f 6e 20 46 61 69 6c ion Fail 0010: 75 72 65 20 20 77 33 77 ure w3w 0018: 70 2e 65 78 65 20 36 2e p.exe 6. 0020: 30 2e 33 37 39 30 2e 33 0.3790.3 0028: 39 35 39 20 69 6e 20 77 959 in w 0030: 33 63 6f 72 65 2e 64 6c 3core.dl 0038: 6c 20 36 2e 30 2e 33 37 l 6.0.37 0040: 39 30 2e 33 39 35 39 20 90.3959 0048: 61 74 20 6f 66 66 73 65 at offse 0050: 74 20 30 30 30 32 30 31 t 000201 0058: 62 34 b4 Is there any way to fix this or a PHP version that work without problem on IIS6? I am using php 4 on windows 2000 since 4 years without any problems. [2008-04-15 12:55:52] pranay dot vanjare at zenithinfotech dot com I HAVE WINDOWS 2003 SERVER RC2 WITH 4G.B RAM XEON SYSTEM. I REGULARLY GET ONE ERROR IN W3WP.EXE FILE (REFERANCE MEMORY AT 0x01e7e8fo MEMORY COULD NOT BE READ) CAN U PLEASE HELP ME IN THAT BECAUSE THIS SERVER IS VERY CRITICAL FOR US. [2007-12-28 21:25:47] masssheltie at hotmail dot com Found this posting buried on a development web site. David Wang et al possibly figured out the reason for the problem. >This is a bug in the PHP ISAPI DLL during DLL unload. It is trying to > double-free a piece of memory. When you recycle the Application Pool, > it causes the w3wp.exe to shutdown and unload all ISAPI DLLs, hence > triggering the PHP bug. > > The crash happen regardless of the IIS Application Pool identity. > > This should just be reported to PHP as a bug. You can recreate the problem by accessing any PHP script, and then recycling the applications pool associated with the web page in IIS. The recycling will cause the error, and will log same in the Event Viewer. I've not heard any formal plans to cope with this as of yet. [2007-04-06 06:02:53] chrisjx at gmail dot com Having the very similar problems. Now have Server 2003 sp2 installed still a problem. The variation I'm having is that I get the error perhaps 6 times whenever I re-boot. Then all is well and everything seems to work fine. I went into PHP.INI and commented out the only extension I had, php_mysql.dll, rebooted and the problem no longer occurs. However w/o this extension installed all is kaput... I know, I see the note not to say "this is how I solved it" or "this might help you" and I suppose you might delete this, but I had to try. I've had this problem since I installed 5.1.4 and I doubt it is "bogus". Event Log: Reporting queued error: faulting application w3wp.exe, version 6.0.3790.3959, faulting module unknown, version 0.0.0.0, fault address 0x01d45c80. [2006-07-26 19:57:26] jeep85 at gmail dot com This error started to appear for me after I upgraded to PHP 5.1.4 Once I downgraded back to PHP 5.1.1 the errors went away. Wasn't sure if that would help isolate the problem. I'm running IIS6 on W2K3 SP1. 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/37575 -- Edit this bug report at http://bugs.php.net/?id=37575&edit=1
#37575 [Com]: Faulting application w3wp.exe
ID: 37575 Comment by: roberto at v-servers dot it Reported By: richardvernooij at yahoo dot com Status: No Feedback Bug Type: IIS related Operating System: Windows 2003 server PHP Version: 5.1.4 New Comment: Hi, I have the same problem with w3wp.exe crashing after a website run page in php 5.2.6 On this website I have Joomla 1.5 installed, the website work but the web server which is IIS6 on windows 2003 server enterprise report all these errors every time a website with php run. Event Type: Error Event Source: Application Error Event Category: (100) Event ID: 1000 Date: 20/10/2008 Time: 18.01.11 User: N/A Computer: VSS Description: Faulting application w3wp.exe, version 6.0.3790.3959, faulting module w3core.dll, version 6.0.3790.3959, fault address 0x000201b4. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Data: : 41 70 70 6c 69 63 61 74 Applicat 0008: 69 6f 6e 20 46 61 69 6c ion Fail 0010: 75 72 65 20 20 77 33 77 ure w3w 0018: 70 2e 65 78 65 20 36 2e p.exe 6. 0020: 30 2e 33 37 39 30 2e 33 0.3790.3 0028: 39 35 39 20 69 6e 20 77 959 in w 0030: 33 63 6f 72 65 2e 64 6c 3core.dl 0038: 6c 20 36 2e 30 2e 33 37 l 6.0.37 0040: 39 30 2e 33 39 35 39 20 90.3959 0048: 61 74 20 6f 66 66 73 65 at offse 0050: 74 20 30 30 30 32 30 31 t 000201 0058: 62 34 b4 Is there any way to fix this or a PHP version that work without problem on IIS6? I am using php 4 on windows 2000 since 4 years without any problems. Previous Comments: [2008-04-15 12:55:52] pranay dot vanjare at zenithinfotech dot com I HAVE WINDOWS 2003 SERVER RC2 WITH 4G.B RAM XEON SYSTEM. I REGULARLY GET ONE ERROR IN W3WP.EXE FILE (REFERANCE MEMORY AT 0x01e7e8fo MEMORY COULD NOT BE READ) CAN U PLEASE HELP ME IN THAT BECAUSE THIS SERVER IS VERY CRITICAL FOR US. [2007-12-28 21:25:47] masssheltie at hotmail dot com Found this posting buried on a development web site. David Wang et al possibly figured out the reason for the problem. >This is a bug in the PHP ISAPI DLL during DLL unload. It is trying to > double-free a piece of memory. When you recycle the Application Pool, > it causes the w3wp.exe to shutdown and unload all ISAPI DLLs, hence > triggering the PHP bug. > > The crash happen regardless of the IIS Application Pool identity. > > This should just be reported to PHP as a bug. You can recreate the problem by accessing any PHP script, and then recycling the applications pool associated with the web page in IIS. The recycling will cause the error, and will log same in the Event Viewer. I've not heard any formal plans to cope with this as of yet. [2007-04-06 06:02:53] chrisjx at gmail dot com Having the very similar problems. Now have Server 2003 sp2 installed still a problem. The variation I'm having is that I get the error perhaps 6 times whenever I re-boot. Then all is well and everything seems to work fine. I went into PHP.INI and commented out the only extension I had, php_mysql.dll, rebooted and the problem no longer occurs. However w/o this extension installed all is kaput... I know, I see the note not to say "this is how I solved it" or "this might help you" and I suppose you might delete this, but I had to try. I've had this problem since I installed 5.1.4 and I doubt it is "bogus". Event Log: Reporting queued error: faulting application w3wp.exe, version 6.0.3790.3959, faulting module unknown, version 0.0.0.0, fault address 0x01d45c80. [2006-07-26 19:57:26] jeep85 at gmail dot com This error started to appear for me after I upgraded to PHP 5.1.4 Once I downgraded back to PHP 5.1.1 the errors went away. Wasn't sure if that would help isolate the problem. I'm running IIS6 on W2K3 SP1. [2006-07-12 09:45:55] ferrante at aracnet dot com I believe this is related to Bug #36853 Worker process crashes after application pool recycle. There are some detailed posts at the bottom of that bug suggesting changing the extensions load order in the php.ini file or disabling DEP for the w3wp.exe process. 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/37575 -- Edit this bug report at http://bugs.php.net/?id=37575&edit=1
#46370 [Bgs]: translation mixup
ID: 46370 User updated by: nikitin at freshframes dot com Reported By: nikitin at freshframes dot com Status: Bogus Bug Type: Filesystem function related Operating System: debian 4.0 PHP Version: 5.2.6 New Comment: i am pretty sure, that i use utf8 in the upload page. my framework is joomla and it uses utf8 when i download the uploaded file the umlauts are corrupted -> utf8 encoded so there is still the question why i need to encode it in php again. Previous Comments: [2008-10-23 12:09:30] [EMAIL PROTECTED] If you upload as latin1 it's stored as latin1, set your charsets properly in the upload page and it works as expected. (fyi: file_get_contents doesn't convert anything to anything, it's binary safe) [2008-10-23 11:17:55] nikitin at freshframes dot com Description: i upload a latin1 file to the debian server (move_uploaded_file) this file is stored in utf8 (using utf8 translation in putty shows me correct chars, using latin1 translation shows me the multibyte chars...) then i read the file into a var via file_get_contents and wonder why mb_check_encoding( var, "UTF-8" ) returns false. sending the var via browser to client with utf8 charset produces wrong data, so i probably have latin1 data in my var. now i use utf8_encode( var ) and everything works fine. what do i need to set to get utf8 data from file reads, or why do i need to encode it again? Reproduce code: --- move_uploaded_file( $_FILES['file']['tmp_name'][0], $file ); $data = file_get_contents( $file ); var_dump( array( mb_check_encoding( $data, "UTF-8" ), mb_check_encoding( utf8_encode( $data ), "UTF-8" ) ); Expected result: [ true, true ] Actual result: -- [ false, true ] -- Edit this bug report at http://bugs.php.net/?id=46370&edit=1
#44135 [Asn]: PDO MySQL does not support CLIENT_FOUND_ROWS
ID: 44135
Updated by: [EMAIL PROTECTED]
Reported By: chx1975 at gmail dot com
Status: Assigned
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.2.5
Assigned To: johannes
New Comment:
Thanks for the patch, a few comments/questions:
- Why are you renaming the connect_opts variable? Any particular
reason?
- You shouldn't use the numeric values, as they might change, but the
values provided by the client library, this also ensures that only flags
supported by the library are being used.
- I think the SSL flag won't work without specific SSL certs & stuff,
but I have to check that myself
Previous Comments:
[2008-10-23 01:34:27] chx1975 at gmail dot com
An attempt to fix this can be found at
http://drupal4hu.com/php-44135.patch . I added a number of flags not
just the one I needed.
running
PDO::MYSQL_CLIENT_FOUND_ROWS));
$p->exec('TRUNCATE a');
$p->exec('INSERT INTO a VALUES (1)');
echo $p->exec('UPDATE a SET a = 1 WHERE a = 1');
$p = new PDO('mysql:host=localhost;dbname=test', 'root', '');
echo $p->exec('UPDATE a SET a = 1 WHERE a = 1');
?>
shows a 1 (one row found) and then a 0 (0 updated) so the patch seems
to work.
[2008-02-16 03:29:44] larry at garfieldtech dot com
I can duplicate this problem. The issue appears to be that by
default, MySQL will return the number of affected rows from a
previous UPDATE statement, not the number of matched rows. That
values will differ if the update statement would set a row to its
existing value. With ext/mysql and ext/mysqli, it can be set to
return matched rows instead. PDO does not appear to have a way to
allow that.
[2008-02-16 03:26:34] chx1975 at gmail dot com
Description:
mysql_real_connect supports client flags
http://dev.mysql.com/doc/refman/4.1/en/mysql-real-connect.html most
importantly CLIENT_FOUND_ROWS but PDO provides no way to pass it in.
--
Edit this bug report at http://bugs.php.net/?id=44135&edit=1
#46326 [Opn]: error_reporting ignored in php-cli.ini
ID: 46326 User updated by: RQuadling at GMail dot com Reported By: RQuadling at GMail dot com Status: Open Bug Type: PHP options/info functions Operating System: Windows XP SP3 PHP Version: 5.3CVS-2008-10-17 (snap) New Comment: Wouldn't surprise me. Previous Comments: [2008-10-22 11:25:29] [EMAIL PROTECTED] So it's most likely Windows only issue. (can't reproduce here..) [2008-10-21 19:09:45] RQuadling at GMail dot com "real"? But no. I'm all windows here. [2008-10-21 09:29:02] [EMAIL PROTECTED] Can you reproduce this with some real OS, line Linux? [2008-10-17 13:25:38] RQuadling at GMail dot com Oh and supplying the INI file via the command line on the 5.3 alpha makes no difference either ... C:\>c:\PHP5\php.exe -c C:\php\PHP5\INI\php-cli.ini z:\phpdetails.php php_sapi_name() = cli phpversion()= 5.3.0alpha3-dev php_ini_loaded_file() = C:\PHP\PHP5\INI\php-cli.ini php_ini_scanned_files() = error_reporting() = 22519 INI error_reporting = error_reporting = E_COMPILE_ERROR|E_RECOVERABLE_ERROR|E_ERROR|E_CORE_ERROR [2008-10-17 12:50:10] RQuadling at GMail dot com Some more examples in playing around with this ... php_sapi_name() = cli phpversion()= 5.3.0alpha3-dev php_ini_loaded_file() = C:\PHP\PHP5\INI\php-cli.ini php_ini_scanned_files() = error_reporting() = 22519 INI error_reporting = error_reporting = E_ALL php_sapi_name() = cli phpversion()= 5.3.0alpha3-dev php_ini_loaded_file() = C:\PHP\PHP5\INI\php-cli.ini php_ini_scanned_files() = error_reporting() = 22519 INI error_reporting = error_reporting = E_ALL & ~E_NOTICE php_sapi_name() = cli phpversion()= 5.3.0alpha3-dev php_ini_loaded_file() = C:\PHP\PHP5\INI\php-cli.ini php_ini_scanned_files() = error_reporting() = 22519 INI error_reporting = error_reporting = E_COMPILE_ERROR|E_RECOVERABLE_ERROR|E_ERROR|E_CORE_ERROR Just to confirm that last one ... If I use V5.2.6 like so ... C:\>c:\PHP5.2.6\php.exe -c C:\php\PHP5\INI\php-cli.ini z:\phpdetails.php The output is ... php_sapi_name() = cli phpversion()= 5.2.6 php_ini_loaded_file() = C:\PHP\PHP5\INI\php-cli.ini php_ini_scanned_files() = error_reporting() = 4177 INI error_reporting = error_reporting = E_COMPILE_ERROR|E_RECOVERABLE_ERROR|E_ERROR|E_CORE_ERROR 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/46326 -- Edit this bug report at http://bugs.php.net/?id=46326&edit=1
#45234 [Fbk->Opn]: Incorrect Content-Length header
ID: 45234
User updated by: kulakov74 at yandex dot ru
Reported By: kulakov74 at yandex dot ru
-Status: Feedback
+Status: Open
Bug Type: Zlib Related
Operating System: Linux
PHP Version: 5.2CVS-2008-06-11 (snap)
New Comment:
I'm very sorry, I cannot go into the trouble of installing PHP, all I
could was check the bug with PHP 5.2.6 where it still was found.
phpinfo() output this:
This is not the latest release definitely.
The test script I used was this:
If the number 24 is changed to 24000 the header is fine (changed
from 24000 to some 5K value), and if it not the header is not correct
(remains 24).
Previous Comments:
[2008-10-23 12:29:03] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2008-06-11 11:03:49] kulakov74 at yandex dot ru
Description:
Many pointed out to the problem that the Content-Length header may have
incorrect value when using zlib.output_compression. This problem may
have been fixed but not completely. When the compressed data fits within
8K Content-Length is sent by zlib after compression and hence the header
(if present) is updated correctly, but when the compressed data is
larger no Content-Length is sent by zlib and hence the value is not
fixed. 8K is the default buffer size for zlib (mod_deflate) and is not
configurable. Anyway, whatever the size of the buffer is, I think the
initial Content-Length should be removed when zlib cannot determine the
size of the compressed data in advance.
The following bugs are related:
http://bugs.php.net/bug.php?id=28460
http://bugs.php.net/bug.php?id=22143
http://bugs.php.net/bug.php?id=24083
I guess many pages compress to more than 8K.
Reproduce code:
---
$FileToSend="filename.txt";
header("Content-Length: ".filesize($FileToSend));
readfile($FileToSend);
Expected result:
Content-Length header with the right value or removed.
Actual result:
--
Content-Length header with the same value I set. Note that the file
that is sent should COMPRESS to more than 8K in order for this to show.
It may be 25K and the problem will not show up.
--
Edit this bug report at http://bugs.php.net/?id=45234&edit=1
#43971 [Opn->Fbk]: imageFTText error with angle = 180
ID: 43971 Updated by: [EMAIL PROTECTED] Reported By: raven7370 at yahoo dot com -Status: Open +Status: Feedback Bug Type: GD related Operating System: Linux Debian PHP Version: 5.2.5 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2008-01-30 17:18:58] raven7370 at yahoo dot com Thanks for trying it. My PHP uses FreeType Version 2.1.7 I think you might be right in that it is a package problem and not a php one.The php i use is not standalone but from lampp (linux version of xampp from apache friends). I will try to get the latest snapshot of 5.2 running separately to see if it works then. Otherwise i will try to get someone from apache friends to test it and see if they can reproduce the problem. [2008-01-29 17:34:23] [EMAIL PROTECTED] I can't reproduce it using php 5.2.5 or CVS. If you use the PHP's package from Debian, I fear that I can't help, they do changes that have nothing to do with any libgd versions (that may change once the politics there is over). Can you try it using snapshots. Which freetype version do you use? [2008-01-29 17:22:29] raven7370 at yahoo dot com in the reproduce code the angle argument should be 180 such as: imagefttext($image, 21, 180, 256, 256, $color, 'ARIALNB.TTF', 'Hello World'); i copied it quickly while i was still testing. [2008-01-29 17:20:42] raven7370 at yahoo dot com Description: When i use imagefttext such with an angle of 180 i get the error: imagefttext() [function.imagefttext]: Problem rendering glyph With an angle of close to 180 (between 179 and 184.6) but not equal to 180 i do not get an error but the text simply won't be drawn. With an angle between 177 to 179 the text will be drawn but stretched vertically. This problem occurs with almost all windows fonts with a few exceptiosn, those being the Chinese ones (SIMSUN.TTF and PMINGLIU.TTF) With: GD Support enabled GD Version bundled (2.0.34 compatible) FreeType Support enabled FreeType Linkage with freetype FreeType Version 2.1.7 Reproduce code: --- $image = imagecreate(512,512); imagecolorallocate($image,0,0,0); $color = imagecolorallocate($image,255,0,0); imagefttext($image, 21, 176.9, 256, 256, $color, 'ARIALNB.TTF', 'Hello World'); imagegif($image); The font mentioned here is from the windows/fonts directory (just copied directly in the same path as the script) Expected result: I expect to see a pictures with hello world written on it upside down. Actual result: -- With an angle of 180 the error "imagefttext() [function.imagefttext]: Problem rendering glyph in ..." is thrown, close to 180 the text is either not drawn or is stretched. -- Edit this bug report at http://bugs.php.net/?id=43971&edit=1
#44193 [Opn->Fbk]: snmp v3 doesn't work
ID: 44193
Updated by: [EMAIL PROTECTED]
Reported By: mavezeau at colubris dot com
-Status: Open
+Status: Feedback
Bug Type: SNMP related
Operating System: Mandriva 2005/linux
PHP Version: 5.2.5
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2008-02-20 21:23:28] mavezeau at colubris dot com
Description:
I try to make a query with snmp v3 and I have an error: "snmp3_walk():
An error occurred" or "snmp3_walk(): No response from 192.168.130.124".
If I execute a query with net-snmp 5.4.1 the query is ok. If I execute
the similar query with php I have those errors.
Reproduce code:
---
AuthNoPriv
net-snmp Query:
snmpwalk -v 3 -l authNoPriv -a MD5 -A jesuisuntest -u test5
192.168.130.124
it Works!
Php snmp
snmp3_walk('192.168.130.124','test5','authNoPriv','MD5','jesuisuntest','','','');
Error !
noAuthNoPriv
net-snmp query:
snmpwalk -v 3 -l noAuthNoPriv -u test 192.168.130.124
it works!
PHP snmp
snmp3_walk('192.168.130.124','test','noAuthNoPriv','','','','','');
error(snmp3_walk(): Invalid authentication protocol)
if use the default
snmp3_walk('192.168.130.124','test','noAuthNoPriv','MD5','','','','');
error(snmp3_walk(): Could not generate key for authentication pass
phrase: MD5)
Expected result:
Similar return value than smnp v2c
Actual result:
--
all method make an error
--
Edit this bug report at http://bugs.php.net/?id=44193&edit=1
#45234 [Opn->Fbk]: Incorrect Content-Length header
ID: 45234
Updated by: [EMAIL PROTECTED]
Reported By: kulakov74 at yandex dot ru
-Status: Open
+Status: Feedback
Bug Type: Zlib Related
Operating System: Linux
PHP Version: 5.2CVS-2008-06-11 (snap)
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2008-06-11 11:03:49] kulakov74 at yandex dot ru
Description:
Many pointed out to the problem that the Content-Length header may have
incorrect value when using zlib.output_compression. This problem may
have been fixed but not completely. When the compressed data fits within
8K Content-Length is sent by zlib after compression and hence the header
(if present) is updated correctly, but when the compressed data is
larger no Content-Length is sent by zlib and hence the value is not
fixed. 8K is the default buffer size for zlib (mod_deflate) and is not
configurable. Anyway, whatever the size of the buffer is, I think the
initial Content-Length should be removed when zlib cannot determine the
size of the compressed data in advance.
The following bugs are related:
http://bugs.php.net/bug.php?id=28460
http://bugs.php.net/bug.php?id=22143
http://bugs.php.net/bug.php?id=24083
I guess many pages compress to more than 8K.
Reproduce code:
---
$FileToSend="filename.txt";
header("Content-Length: ".filesize($FileToSend));
readfile($FileToSend);
Expected result:
Content-Length header with the right value or removed.
Actual result:
--
Content-Length header with the same value I set. Note that the file
that is sent should COMPRESS to more than 8K in order for this to show.
It may be 25K and the problem will not show up.
--
Edit this bug report at http://bugs.php.net/?id=45234&edit=1
#46169 [Opn->Bgs]: destruct in wrong order with static object
ID: 46169
Updated by: [EMAIL PROTECTED]
Reported By: luke at cywh dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 5.2.6
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
Previous Comments:
[2008-09-24 18:36:50] luke at cywh dot com
Just discovered it's not just static objects. If you create an object
within a function in a local variable, it destructs after the function
finishes (like it should). But if you track it in an array in the
primary classes scope, it destructs incorrectly still. Adding the
Registry in the results, you get:
C:Registry
C:class1
C:class2
C:class3
D:Registry
D:class1
D:class2
D:class3
But I would expect this:
C:Registry
C:class1
C:class2
C:class3
D:Registry
D:class3
D:class2
D:class1
or this?:
C:Registry
C:class1
C:class2
C:class3
D:class3
D:class2
D:class1
D:Registry
Grrr... I'm not even sure. There is no consistency. 5.1.6 was "wrong",
but at least it was consistently wrong.
[2008-09-24 18:14:17] luke at cywh dot com
Description:
This is related to a bug that was fixed in version 5.2.0, which you
can read about here:
http://bugs.php.net/bug.php?id=36759
Basically if you were to initiate a class, the destruct order would be
incorrect: "C1,C2,C3,D1,D2,D3". This was corrected in 5.2.0 to be
"C1,C2,C3,D3,D2,C1".
The problem, however, still persists if you create an object inside a
static object. Code to recreate this issue is included in this bug
report.
If you initiate the classes without the Registry singleton, it
destructs properly ($c1 = new class1()...).
Testing this with 5.1.6, the destruct order is incorrect in both
situations (as i'd expect). If you unset the objects in reverse order
as they were created, both work correctly on 5.1.6 and 5.2.6.
So a work-around for either version is to simply track the objects and
unset them. But if you don't do this, the destruct order is still
incorrect if creating your objects through a singleton object.
Reproduce code:
---
class shorten {
public function __construct() { print 'C:' . get_class($this) . ""; }
public function __destruct() { print 'D:' . get_class($this) . ""; }
}
class class1 extends shorten {}
class class2 extends shorten {}
class class3 extends shorten {}
class Registry {
static private $instance = null;
private $registered = array();
static public function instance() {
if(self::$instance == null) self::$instance = new Registry();
return self::$instance;
}
private function __call($name, $arguments) {
if( ! isset($this->registered[$name]) )
$this->registered[$name] =
new $name();
return $this->registered[$name];
}
private function __get($name) {
if( ! isset($this->registered[$name]) )
$this->registered[$name] =
new $name();
return $this->registered[$name];
}
}
Registry::instance()->class1();
Registry::instance()->class2();
Registry::instance()->class3();
Expected result:
C:class1
C:class2
C:class3
D:class3
D:class2
D:class1
Actual result:
--
C:class1
C:class2
C:class3
D:class1
D:class2
D:class3
--
Edit this bug report at http://bugs.php.net/?id=46169&edit=1
#46366 [Opn->Fbk]: bad cwd with / as pathinfo
ID: 46366 Updated by: [EMAIL PROTECTED] Reported By: courtois at nouvo dot com -Status: Open +Status: Feedback Bug Type: CGI related Operating System: windows XP PHP Version: 5.2.6 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2008-10-22 16:07:58] courtois at nouvo dot com Description: when / is passed as pathinfo to a script current working directory is set to the php-cgi.exe directory instead of script directory http://localhost/foo/bar.php gives: cwd===>C:\Program Files\Apache Group\Apache2\htdocs\foo<=== which is ok http://localhost/foo/bar.php/x gives: cwd===>C:\Program Files\Apache Group\Apache2\htdocs\foo<=== which is ok http://localhost/foo/bar.php/ gives: cwd===>C:\Program Files\PHP<=== which is obviously not ok, therefore all includes in scripts fail apache 2 config: ScriptAlias /php/ "C:/Program Files/PHP/" Action application/x-httpd-php "/php/php-cgi.exe" php.ini: cgi.fix_pathinfo=1 Reproduce code: --- ".getcwd()."<==="; ?> -- Edit this bug report at http://bugs.php.net/?id=46366&edit=1
#46370 [Opn->Bgs]: translation mixup
ID: 46370 Updated by: [EMAIL PROTECTED] Reported By: nikitin at freshframes dot com -Status: Open +Status: Bogus Bug Type: Filesystem function related Operating System: debian 4.0 PHP Version: 5.2.6 New Comment: If you upload as latin1 it's stored as latin1, set your charsets properly in the upload page and it works as expected. (fyi: file_get_contents doesn't convert anything to anything, it's binary safe) Previous Comments: [2008-10-23 11:17:55] nikitin at freshframes dot com Description: i upload a latin1 file to the debian server (move_uploaded_file) this file is stored in utf8 (using utf8 translation in putty shows me correct chars, using latin1 translation shows me the multibyte chars...) then i read the file into a var via file_get_contents and wonder why mb_check_encoding( var, "UTF-8" ) returns false. sending the var via browser to client with utf8 charset produces wrong data, so i probably have latin1 data in my var. now i use utf8_encode( var ) and everything works fine. what do i need to set to get utf8 data from file reads, or why do i need to encode it again? Reproduce code: --- move_uploaded_file( $_FILES['file']['tmp_name'][0], $file ); $data = file_get_contents( $file ); var_dump( array( mb_check_encoding( $data, "UTF-8" ), mb_check_encoding( utf8_encode( $data ), "UTF-8" ) ); Expected result: [ true, true ] Actual result: -- [ false, true ] -- Edit this bug report at http://bugs.php.net/?id=46370&edit=1
#46370 [NEW]: translation mixup
From: nikitin at freshframes dot com Operating system: debian 4.0 PHP version: 5.2.6 PHP Bug Type: Filesystem function related Bug description: translation mixup Description: i upload a latin1 file to the debian server (move_uploaded_file) this file is stored in utf8 (using utf8 translation in putty shows me correct chars, using latin1 translation shows me the multibyte chars...) then i read the file into a var via file_get_contents and wonder why mb_check_encoding( var, "UTF-8" ) returns false. sending the var via browser to client with utf8 charset produces wrong data, so i probably have latin1 data in my var. now i use utf8_encode( var ) and everything works fine. what do i need to set to get utf8 data from file reads, or why do i need to encode it again? Reproduce code: --- move_uploaded_file( $_FILES['file']['tmp_name'][0], $file ); $data = file_get_contents( $file ); var_dump( array( mb_check_encoding( $data, "UTF-8" ), mb_check_encoding( utf8_encode( $data ), "UTF-8" ) ); Expected result: [ true, true ] Actual result: -- [ false, true ] -- Edit bug report at http://bugs.php.net/?id=46370&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46370&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46370&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46370&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46370&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=46370&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46370&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=46370&r=needscript Try newer version:http://bugs.php.net/fix.php?id=46370&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46370&r=support Expected behavior:http://bugs.php.net/fix.php?id=46370&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46370&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46370&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46370&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46370&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=46370&r=dst IIS Stability:http://bugs.php.net/fix.php?id=46370&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46370&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46370&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46370&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=46370&r=mysqlcfg
#44135 [Opn->Asn]: PDO MySQL does not support CLIENT_FOUND_ROWS
ID: 44135
Updated by: [EMAIL PROTECTED]
Reported By: chx1975 at gmail dot com
-Status: Open
+Status: Assigned
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.2.5
-Assigned To:
+Assigned To: johannes
Previous Comments:
[2008-10-23 01:34:27] chx1975 at gmail dot com
An attempt to fix this can be found at
http://drupal4hu.com/php-44135.patch . I added a number of flags not
just the one I needed.
running
PDO::MYSQL_CLIENT_FOUND_ROWS));
$p->exec('TRUNCATE a');
$p->exec('INSERT INTO a VALUES (1)');
echo $p->exec('UPDATE a SET a = 1 WHERE a = 1');
$p = new PDO('mysql:host=localhost;dbname=test', 'root', '');
echo $p->exec('UPDATE a SET a = 1 WHERE a = 1');
?>
shows a 1 (one row found) and then a 0 (0 updated) so the patch seems
to work.
[2008-02-16 03:29:44] larry at garfieldtech dot com
I can duplicate this problem. The issue appears to be that by
default, MySQL will return the number of affected rows from a
previous UPDATE statement, not the number of matched rows. That
values will differ if the update statement would set a row to its
existing value. With ext/mysql and ext/mysqli, it can be set to
return matched rows instead. PDO does not appear to have a way to
allow that.
[2008-02-16 03:26:34] chx1975 at gmail dot com
Description:
mysql_real_connect supports client flags
http://dev.mysql.com/doc/refman/4.1/en/mysql-real-connect.html most
importantly CLIENT_FOUND_ROWS but PDO provides no way to pass it in.
--
Edit this bug report at http://bugs.php.net/?id=44135&edit=1
#43306 [Com]: File Download Problem.
ID: 43306
Comment by: arasan at mahiti dot org
Reported By: d dot tas40 at chello dot nl
Status: No Feedback
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.2.5
New Comment:
I've used this code but the download rate is very slow compared to
ordinary download. whether there is any way to overcome this?
Previous Comments:
[2008-09-25 04:51:26] [EMAIL PROTECTED]
Please try without any Content-Length header, your HTTP server is
probably using a chunked transfert encoding. Also try with a
Content-Type like 'application/octet-stream'.
Also check the character_set_* variables in your MySQL connection, the
server may try to convert the query or the results if some variables do
not match (blobs are binary but queries and results are not).
[2008-09-25 02:54:18] alphajet1024 at hotmail dot com
I have the very same problem, but my host server is PHP Version 4.3.11
with Linux OS, i use the following code snippest to recieve the file
from form and upload it to a BLOB field in SQL, the code works fine with
all file extensions, except rar and zip files, they mostly are
corrupted.
upload.php
0)
{
$fileName = $_FILES['userfile']['name'];
$tmpName = $_FILES['userfile']['tmp_name'];
$fileSize = $_FILES['userfile']['size'];
$fileType = $_FILES['userfile']['type'];
$fp = fopen($tmpName, 'r');
$content = fread($fp, filesize($tmpName));
$content = addslashes($content);
fclose($fp);
if(!get_magic_quotes_gpc())
{
$fileName = addslashes($fileName);
}
include('conf.php');
// open database connection
$connection = mysql_connect($host, $user, $pass)
or die ('Unable to connect!');
// select database
mysql_select_db($db)
or die ('Unable to select database!');
$query = "INSERT INTO upload (name, size, type, content ) ".
"VALUES ('$fileName', '$fileSize', '$fileType', '$content')";
mysql_query($query) or die('Error, query failed ' . mysql_error());
?>
download.php
[2008-01-12 17:08:06] webmaster at anpera dot net
I have a similar problem with PHP 5.2.4 / 5.2.5 with Apache2.2 under
Windows 2003.
Downloaded files are missing exactly 15 bytes at the end. ZIP and RAR
files can't be opened correctly after download but definitely are okay
on the server's hard drive.
With
$filesize=filesize($filename)+15;
the downloads are working.
$size = @filesize($filename)+15;
header('Pragma: public');
[...]
header("Content-Length: $size");
$fp = @fopen($filename, 'rb');
[...]
while (!feof($fp)){
echo fread($fp, 8192);
}
fclose($fp);
[...]
flush();
[2007-11-23 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2007-11-15 22:46:55] [EMAIL PROTECTED]
Are you sure there aren't any errors happening there? Check the file
you downloaded using e.g. notepad..
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/43306
--
Edit this bug report at http://bugs.php.net/?id=43306&edit=1
#46212 [Opn->Csd]: SQLite3::exec() with a valid CREATE TABLE fails
ID: 46212 Updated by: [EMAIL PROTECTED] Reported By: kristof dot coomans at telenet dot be -Status: Open +Status: Closed Bug Type: SQLite related Operating System: Windows XP PHP Version: 5.3CVS-2008-10-01 (snap) Assigned To: scottmac Previous Comments: [2008-10-23 07:59:51] kristof dot coomans at telenet dot be Yes, it works again as expected with the last snapshot I downloaded. Thanks! [2008-10-20 23:58:36] [EMAIL PROTECTED] Can you try a 5.3 snapshot from http://windows.php.net/snapshots/ I think this could be optimisation related and recently fixed. [2008-10-01 16:25:40] kristof dot coomans at telenet dot be Yes, the user has permission to read & write to the directory & file. [2008-10-01 15:58:12] [EMAIL PROTECTED] Does the user you're running the script as have permission to write the database file and the directory the script is in? That's usually the reason for this sort of error. [2008-10-01 15:56:11] [EMAIL PROTECTED] This works on Linux and Mac but not Windows. 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/46212 -- Edit this bug report at http://bugs.php.net/?id=46212&edit=1
#46212 [Fbk->Opn]: SQLite3::exec() with a valid CREATE TABLE fails
ID: 46212
User updated by: kristof dot coomans at telenet dot be
Reported By: kristof dot coomans at telenet dot be
-Status: Feedback
+Status: Open
Bug Type: SQLite related
Operating System: Windows XP
PHP Version: 5.3CVS-2008-10-01 (snap)
Assigned To: scottmac
New Comment:
Yes, it works again as expected with the last snapshot I downloaded.
Thanks!
Previous Comments:
[2008-10-20 23:58:36] [EMAIL PROTECTED]
Can you try a 5.3 snapshot from http://windows.php.net/snapshots/
I think this could be optimisation related and recently fixed.
[2008-10-01 16:25:40] kristof dot coomans at telenet dot be
Yes, the user has permission to read & write to the directory & file.
[2008-10-01 15:58:12] [EMAIL PROTECTED]
Does the user you're running the script as have permission to write the
database file and the directory the script is in?
That's usually the reason for this sort of error.
[2008-10-01 15:56:11] [EMAIL PROTECTED]
This works on Linux and Mac but not Windows.
[2008-10-01 15:37:08] kristof dot coomans at telenet dot be
Description:
SQLite3::exec with valid query fails with the error message "SQL logic
error or missing database".
Actually testing with
http://snaps.php.net/win32/php5.3-win32-200809251104.zip since there is
no snapshot for win32 yet for today.
Reproduce code:
---
exec( $sql );
if ( !$succes )
{
print( "Error " . $cn->lastErrorCode() . ": " . $cn->lastErrorMsg()
. PHP_EOL );
}
?>
Expected result:
The script should finish without any warnings.
Executing the sql with the sqlite3 command line client works fine.
Actual result:
--
Error 1: SQL logic error or missing database
--
Edit this bug report at http://bugs.php.net/?id=46212&edit=1
