#40841 [NEW]: #38770/#40543 Not fixed on Solaris 10
From: lovan at lifesci dot ucsb dot edu Operating system: Solaris 10 PHP version: 5.2.1 PHP Bug Type: Compile Failure Bug description: #38770/#40543 Not fixed on Solaris 10 Description: A "gmake install" fails with unpack errors when PHP is compiled as a 64-bit module for Apache 2.2.4 and 2.2.3 running on Solaris 10 (sparc). I've tried three different compilers (GCC 3.4.3 and 4.1.1 and SunPro CC) and get the same result so it seems unlikely to be a compiler problem. The problem does *not* appear in PHP 5.1.6 but is evident in both 5.2.1 and the 20070316 5.2 snapshot. -- Edit bug report at http://bugs.php.net/?id=40841&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40841&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40841&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40841&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40841&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40841&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40841&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40841&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40841&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40841&r=support Expected behavior:http://bugs.php.net/fix.php?id=40841&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40841&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40841&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40841&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40841&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40841&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40841&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40841&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40841&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40841&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40841&r=mysqlcfg
#40813 [Asn]: upload filename
ID: 40813 Updated by: [EMAIL PROTECTED] Reported By: gianluca dot gimigliano at interno dot it Status: Assigned Bug Type: *Web Server problem Operating System: Windows XP PHP Version: 5.2.1 Assigned To: iliaa New Comment: I the meanwhile you can set magic_quotes_gpc=off in your php.ini which will avoid this problem if your code does not depend on the magic_quotes (which it shouldn't anyway), Previous Comments: [2007-03-17 00:42:11] [EMAIL PROTECTED] Ilia, please take a look at this issue. It's your patch causes this behaviour: http://cvs.php.net/viewvc.cgi/php-src/main/rfc1867.c?view=diff&r1=1.168&r2=1.169 The last #ifdef PHP_WIN32 doesn't look right, did it get there by mistake? [2007-03-15 14:19:25] gianluca dot gimigliano at interno dot it With this apache version: Apache Version Apache/2.2.4 (Win32) mod_ssl/2.2.4 OpenSSL/0.9.8d PHP/5.2.2-dev The prolem is the same [2007-03-15 13:02:30] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2007-03-15 09:47:54] gianluca dot gimigliano at interno dot it Description: When you try to upload a file with the character:' in the name, the uploaded file name is read from the ' position. Reproduce code: --- Expected result: If the uploaded file name is: special'ized.doc The correct output is: special'ized.doc Actual result: -- If the uploaded file name is: special'ized.doc The real output is: ized.doc -- Edit this bug report at http://bugs.php.net/?id=40813&edit=1
#40813 [Opn->Asn]: upload filename
ID: 40813 Updated by: [EMAIL PROTECTED] Reported By: gianluca dot gimigliano at interno dot it -Status: Open +Status: Assigned Bug Type: *Web Server problem Operating System: Windows XP PHP Version: 5.2.1 -Assigned To: +Assigned To: iliaa New Comment: Ilia, please take a look at this issue. It's your patch causes this behaviour: http://cvs.php.net/viewvc.cgi/php-src/main/rfc1867.c?view=diff&r1=1.168&r2=1.169 The last #ifdef PHP_WIN32 doesn't look right, did it get there by mistake? Previous Comments: [2007-03-15 14:19:25] gianluca dot gimigliano at interno dot it With this apache version: Apache Version Apache/2.2.4 (Win32) mod_ssl/2.2.4 OpenSSL/0.9.8d PHP/5.2.2-dev The prolem is the same [2007-03-15 13:02:30] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2007-03-15 09:47:54] gianluca dot gimigliano at interno dot it Description: When you try to upload a file with the character:' in the name, the uploaded file name is read from the ' position. Reproduce code: --- Expected result: If the uploaded file name is: special'ized.doc The correct output is: special'ized.doc Actual result: -- If the uploaded file name is: special'ized.doc The real output is: ized.doc -- Edit this bug report at http://bugs.php.net/?id=40813&edit=1
#40840 [Bgs->Opn]: Derived class cant call its private method from the context of its base class
ID: 40840
User updated by: davcha at nordnet dot fr
Reported By: davcha at nordnet dot fr
-Status: Bogus
+Status: Open
Bug Type: Feature/Change Request
Operating System: Windows XP SP2
PHP Version: 5.2.1
New Comment:
How about this :
$f();
}
}
class SubClass extends BaseClass {
private function B(){
echo 'hello, i dont show !';
}
public function C(){
$this->A('B');
}
}
$b = new SubClass();
$b->C('B');
?>
In this case, i'm calling SubClass:B() from SubClass context. At least,
that's how it should work : that's how it works in C, C#, etc...
In PHP 5.2.1 i'm still getting the same fatal error.
Previous Comments:
[2007-03-16 23:58:53] [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
You are calling a method from SubClass out of the BaseClass context.
[2007-03-16 23:25:32] davcha at nordnet dot fr
Description:
A derived class 'SubClass' cannot call a private method declared into
'SubClass' from the context of its parent class 'BaseClass'.
However, even if the private method is called from 'BaseClass', dumping
the variable $this shows the current class type is 'SubClass'.
Reproduce code:
---
$f();
}
}
class SubClass extends BaseClass {
private function B(){
echo 'hello, i dont show !';
}
}
$b = new SubClass();
$b->A('B');
?>
Expected result:
object(SubClass)#1 (0) { } hello, i dont show !
Actual result:
--
object(SubClass)#1 (0) { }
Fatal error: Call to private method SubClass::B() from context
'BaseClass' in C:\httpd\htdocs\pwidgets\test2.php on line 5
--
Edit this bug report at http://bugs.php.net/?id=40840&edit=1
#40840 [Opn->Bgs]: Derived class cant call its private method from the context of its base class
ID: 40840
Updated by: [EMAIL PROTECTED]
Reported By: davcha at nordnet dot fr
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: Windows XP SP2
PHP Version: 5.2.1
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
You are calling a method from SubClass out of the BaseClass context.
Previous Comments:
[2007-03-16 23:25:32] davcha at nordnet dot fr
Description:
A derived class 'SubClass' cannot call a private method declared into
'SubClass' from the context of its parent class 'BaseClass'.
However, even if the private method is called from 'BaseClass', dumping
the variable $this shows the current class type is 'SubClass'.
Reproduce code:
---
$f();
}
}
class SubClass extends BaseClass {
private function B(){
echo 'hello, i dont show !';
}
}
$b = new SubClass();
$b->A('B');
?>
Expected result:
object(SubClass)#1 (0) { } hello, i dont show !
Actual result:
--
object(SubClass)#1 (0) { }
Fatal error: Call to private method SubClass::B() from context
'BaseClass' in C:\httpd\htdocs\pwidgets\test2.php on line 5
--
Edit this bug report at http://bugs.php.net/?id=40840&edit=1
#40840 [NEW]: Derived class cant call its private method from the context of its base class
From: davcha at nordnet dot fr
Operating system: Windows XP SP2
PHP version: 5.2.1
PHP Bug Type: Feature/Change Request
Bug description: Derived class cant call its private method from the context
of its base class
Description:
A derived class 'SubClass' cannot call a private method declared into
'SubClass' from the context of its parent class 'BaseClass'.
However, even if the private method is called from 'BaseClass', dumping
the variable $this shows the current class type is 'SubClass'.
Reproduce code:
---
$f();
}
}
class SubClass extends BaseClass {
private function B(){
echo 'hello, i dont show !';
}
}
$b = new SubClass();
$b->A('B');
?>
Expected result:
object(SubClass)#1 (0) { } hello, i dont show !
Actual result:
--
object(SubClass)#1 (0) { }
Fatal error: Call to private method SubClass::B() from context 'BaseClass'
in C:\httpd\htdocs\pwidgets\test2.php on line 5
--
Edit bug report at http://bugs.php.net/?id=40840&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40840&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40840&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40840&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40840&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40840&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40840&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40840&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40840&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40840&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40840&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40840&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40840&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40840&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40840&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40840&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40840&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40840&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40840&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40840&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40840&r=mysqlcfg
#40735 [Fbk]: stream_select returns 0 for php > 5.1.6
ID: 40735 Updated by: [EMAIL PROTECTED] Reported By: rodricg at sellingsource dot com Status: Feedback Bug Type: Streams related Operating System: x86_64 GNU/Linux PHP Version: 5CVS-2007-03-05 (snap) New Comment: I have a x86(-32) gentoo box with the same gcc version as you and your script works perfectly. anyway if this is a compiler error, you need report it to gentoo guys, that will then investigate to see if it is caused by their patchset or not. Previous Comments: [2007-03-13 19:24:05] [EMAIL PROTECTED] Still works perfectly fine with or without OpenSSL, with and without -O2. I think I'll need an acccount on your machine to reproduce it. [2007-03-13 16:26:40] rodricg at sellingsource dot com The following script reproduces the behavior (for me): http://11434.com/stream_select.sh Changing -O2 to -O1 or removing --with-openssl fixes the problem. gcc version 4.1.2 openssl version 0.9.8d [2007-03-13 11:05:36] [EMAIL PROTECTED] I still have no idea how to replicate it. [2007-03-12 16:54:41] rodricg at sellingsource dot com Same behavior with gcc 4.1.2. I'm chalking this up to gcc optimization and will compile with -O1 for now. [2007-03-06 21:14:57] [EMAIL PROTECTED] Try with GCC 4.1.2. GCC 4.1.1 is known to have some problems. 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/40735 -- Edit this bug report at http://bugs.php.net/?id=40735&edit=1
#40014 [Bgs->Csd]: "try, catch" -- Let's Empower It, Please!!!
ID: 40014
User updated by: marcus3v at hotmail dot com
Reported By: marcus3v at hotmail dot com
-Status: Bogus
+Status: Closed
Bug Type:Feature/Change Request
PHP Version: 6CVS-2007-01-03 (CVS)
New Comment:
[ Changing Status to "Closed", since this is not simply "Bogus" ]
Previous Comments:
[2007-03-16 00:43:06] [EMAIL PROTECTED]
helly's second reply explains everything:
E_ERROR cannot be caught in the userspace and this is not going to be
changed until the engine is not rewritten from scratch (and we don't
have such plans either).
So you have to live with what you got now and it has nothing to do with
try/catch - that's how the things work.
I understand that this is a change request, not a bug report, but we're
not going to change this in the foreseeable future.
[2007-03-16 00:07:34] marcus3v at hotmail dot com
Dear Sirs,
First of all, excuse me for the mood of the previous post.
I will try to explain in a more detailed manner the question.
In the initial post, I said: "[...] enhance the 'try, catch' Statement
so that Code inside 'try' would transparently cause a Fatal Error
[...]". What did I mean by this?
If the Code fragment provided there ( initial post ) were translated to
C, C++, Java, VB.Net -- or VB, through the horrendous yet powerful "On
Error" Statement -- or JavaScript ( perhaps, also Python ), all
translations would have exactly the same output:
# [global] -- causing a Fatal Error...
# [global] -- some handling being executed...
# [global] -- [end]
This make evident that all this Languages have an "effective" Exception
Handling mechanism, that is: they really allow the rise of Fatal Errors
inside the "try" Block ( whose Code is said "protected" ) with no
intrinsic implications for the Code that get executed latter, since
this can freely check the Error condition and take any desired
actions.
In PHP 5, the "try, catch" Statement was supposedly introduced to
provide Exception Handling. But this "try, catch", though homologous to
the existents in other Languages, have a considerably diverse role.
Simply put, it "provides the programmer, for organizational purposes
only, with a Structure where an Exception can explicitly be thrown (
through 'throw' KeyWord ), invoking a qualified 'catch' that follows or
that is in a previous Stack level". In other words, Fatal Errors -- that
is, "implicitly" thrown Exception -- still are "fatal" inside a PHP
"try" Block; they still imply instantaneous Program ( Script )
abortion. Meanwhile, in the Languages with "effective" Exception
Handling, an "'implicitly' thrown Exception" inside a "try" is,
definitely, "non-fatal": it is just "discarded", having its Error data
collected for eventual further utilization.
Summarizing, since PHP does not have "effective" Exception Handling,
it, concerning the above mentioned fragment, outputs:
# [global] -- causing a Fatal Error...
# ( PHP Notice ) undefined Variable: nonObjVar
# ( PHP Fatal Error ) call to a Member Function ( "method()" ) on a
non-Object
Note that did occurred Program abortion: the last message ( "[global]
-- [end]" ) was not printed...
Our friend, [EMAIL PROTECTED], said: "Just register an error handler that
throws an exception". And, after: "Simply provide an error handler that
converts the errors to exceptions and be done". Unfortunately, it
appears that he was not able to grasp the problem. Well, in a PHP
context, the following situations, among others, constitutes Exceptions
( Fatal Errors ), not Errors:
# 1. Call to undefined Function;
# 2. Call to Methods on non-Objects;
So, this situations cannot be handled through "set_error_handler()":
they rise Exceptions, not Errors. It is, though, surprising that they
also can't be handled through "set_exception_handler()", because this
Function is only invoked when an Exception is explicitly thrown (
'throw' KeyWord ) -- that is, it just have an "organizational" role,
just as "try, catch", having been introduced together with this in PHP
5.
Consider the following fragment:
function error($errNiv, $errMsg, $file, $errLn, $errContxt)
{
//## this Function will never get executed
/*@@*/ echo("error() -- msg= '".$errMsg."'");
}
function exception($excObj)
{
//## this Function will never get executed
/*@@*/ echo("exception() -- [ini]");
}
/*##*/ set_error_handler("error");
/*##*/ set_exception_handler("exception");
/*@@*/ echo("[global] -- causing a Fatal Error...");
$var0=teste(); //## "teste()" isn't defined
/*@@*/ echo("[global] -- [end]");
The output is solely the following:
# [global] -- causing a Fatal Error...
# ( PHP Fatal Error ) Call to undefined Function "teste()"
If PHP had Exception Handling, the output should be the following:
# [global] -- causing a Fatal Error...
# exception() -- [ini]
#40806 [Opn->Asn]: session id gets over-written by other server's cookie
ID: 40806 Updated by: [EMAIL PROTECTED] Reported By: john at albin dot net -Status: Open +Status: Assigned Bug Type:Session related PHP Version: 5.2.1 -Assigned To: +Assigned To: iliaa Previous Comments: [2007-03-14 19:11:51] john at albin dot net Description: Here's a not-so-unusual situation: If a user goes to a PHP-based website with enabled sessions at http:// example.com, by default PHP sets a cookie named PHPSESSID for .example.com. If that user then goes to a seperate website at http:// other.example.com, PHP sets a cookie named PHPSESSID for .other.example.com. >From the cookie spec: When sending cookies to a server, all cookies with a more specific path mapping should be sent before cookies with less specific path mappings. For example, a cookie "name1=foo" with a path mapping of "/" should be sent after a cookie "name1=foo2" with a path mapping of "/ bar" if they are both to be sent. Even though both cookies are submitted by the browser back to the other.example.com website, PHP clobbers the value of the more-specific cookie with the less-specific cookie that follows. So there's no way that the PHP code could ever get the correct session id. Reproduce code: --- Go to http://example.com and let PHP set a default session cookie. Go to http://other.example.com and let PHP set a default session cookie. On the other.example.com website run: Expected result: To get the session_id from the .other.example.com cookie. Actual result: -- You get the session_id from the .example.com cookie. -- Edit this bug report at http://bugs.php.net/?id=40806&edit=1
#40809 [Opn->Asn]: Poor perfomance of ".="
ID: 40809
Updated by: [EMAIL PROTECTED]
Reported By: thuejk at gmail dot com
-Status: Open
+Status: Assigned
Bug Type: Performance problem
Operating System: Linux
PHP Version: 5.2.1
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2007-03-14 23:51:42] thuejk at gmail dot com
Description:
In some cases, the ".=" operator can have poor performance.
I have a production PHP program which a problem which I think is caused
by this. Originally a task took 700 seconds to run. Some debug output
found that a simple ".=" on a very long string took far too long.
Tweaking the memory allocator to round up allocations to the nearest
power of 2 decreased the run time to 60 seconds.
My tweak was to insert
uint pow_2 = 4;
while (pow_2 < size) {
pow_2 *= 2;
}
size = pow_2;
into the top of _zend_mm_alloc_int() and _zend_mm_realloc_int()
(I think) ".=" uses the Zend/zend_operators.c:concat_function()
function. This function will reallocate the string with the minimum
length needed for each concatenation. My tweaked memory allocator will
allocate extra space in advance, which means realloc() returns
immediately, which seems to make the difference.
I have attached some code which reproduces the performance problem. I
am actually not sure exactly what happens. The part for creating MM
holes is taken from http://bugs.php.net/bug.php?id=40261 , so this may
be the same bug, but I am not sure.
Run time of attached test case with and without my tweak:
[EMAIL PROTECTED] ~> time /usr/local/php-5.2.1/bin/php evil.php
/usr/local/php-5.2.1/bin/php evil.php 1,04s user 0,01s system 99% cpu
1,047 total
[EMAIL PROTECTED] ~> time /usr/local/php-5.2.1_clean/bin/php evil.php
/usr/local/php-5.2.1_clean/bin/php evil.php 12,30s user 0,02s system
99% cpu 12,323 total
Reproduce code:
---
--
Edit this bug report at http://bugs.php.net/?id=40809&edit=1
#40833 [Opn->Asn]: Crash when using unset() on an ArrayAccess object retrieved via __get()
ID: 40833
Updated by: [EMAIL PROTECTED]
Reported By: daan at parse dot nl
-Status: Open
+Status: Assigned
Bug Type: Reproducible crash
Operating System: Slackware 10.2
PHP Version: 5.2.1
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2007-03-16 11:33:38] daan at parse dot nl
Description:
When trying to trigger the magic offsetUnset() method on a variable
which itself is retrieved via a magic __get() method, some sort of
object/variable corruption occurs.
If the unset() is applied in two operations, it does not crash.
Also, to trigger this crash, the object must be re-assigned via
'resetSelf()'.
Reproduce code:
---
data[$name]) )
return $this->data[$name];
else
return $this->data[$name] = new set($this,
$name);
}
function __set($name, $value)
{
$this->modified[$name] = $value;
}
}
class set implements ArrayAccess
{
private $entity;
private $name;
function __construct($entity, $name)
{
$this->entity = $entity;
$this->name = $name;
}
function offsetUnset($offset)
{
$this->entity->{$this->name} = null;
}
function offsetSet($offset, $value)
{
}
function offsetGet($offset)
{
return 'Bogus';
}
function offsetExists($offset)
{
}
function resetSelf()
{
$this->entity->{$this->name} = $this;
}
}
$entity = new entity();
$entity->whatever->resetSelf();
echo $entity->whatever[0];
//This will crash
unset($entity->whatever[0]);
//This will not crash (comment previous & uncomment this to test
// $test = $entity->whatever; unset($test[0]);
echo $entity->whatever[0];
var_dump($entity);
echo 'All good';
?>
Expected result:
The string 'BogusBogusAllGood'.
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 654)]
0x4065de11 in zend_object_store_get_object (zobject=0x18302664) at
/usr/src/php-5.2.1/Zend/zend_objects_API.c:255
255 return
EG(objects_store).object_buckets[handle].bucket.obj.object;
(gdb) bt
#0 0x4065de11 in zend_object_store_get_object (zobject=0x18302664) at
/usr/src/php-5.2.1/Zend/zend_objects_API.c:255
#1 0x4065b05f in zend_std_get_properties (object=0x810099c) at
/usr/src/php-5.2.1/Zend/zend_object_handlers.c:55
#2 0x405dc642 in php_var_dump (struc=0x8100a9c, level=5) at
/usr/src/php-5.2.1/ext/standard/var.c:140
#3 0x405dc921 in php_array_element_dump (zv=0x8100a9c, num_args=1,
args=0x80f1188 "", hash_key=0xbfffc550) at
/usr/src/php-5.2.1/ext/standard/var.c:64
#4 0x4064e4d0 in zend_hash_apply_with_arguments (ht=0x8100ac4,
apply_func=0x405dc8c0 , num_args=1)
at /usr/src/php-5.2.1/Zend/zend_hash.c:729
#5 0x405dc6cf in php_var_dump (struc=0x80fa794, level=3) at
/usr/src/php-5.2.1/ext/standard/var.c:152
#6 0x405dc870 in php_object_property_dump (zv=0x80fa794, num_args=1,
args=0xbfffc63c "\001", hash_key=0x8) at
/usr/src/php-5.2.1/ext/standard/var.c:96
#7 0x4064e4d0 in zend_hash_apply_with_arguments (ht=0x80fb0b0,
apply_func=0x405dc7c0 , num_args=1)
at /usr/src/php-5.2.1/Zend/zend_hash.c:729
#8 0x405dc6cf in php_var_dump (struc=0x80f0bf0, level=1) at
/usr/src/php-5.2.1/ext/standard/var.c:152
#9 0x405dc9be in zif_var_dump (ht=1, return_value=0x8100e5c,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=0)
at /usr/src/php-5.2.1/ext/standard/var.c:193
#10 0x40660b14 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffc8e0) at
/usr/src/php-5.2.1/Zend/zend_vm_execute.h:200
#11 0x40660249 in execute (op_array=0x80fa554) at
/usr/src/php-5.2.1/Zend/zend_vm_execute.h:92
#12 0x40645274 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/php-5.2.1/Zend/zend.c:1135
#13 0x4060990a in php_execute_script (primary_file=0xbfffebb0) at
/usr/src/php-5.2.1/main/main.c:1784
#14 0x406c7842 in apache_php_module_main (r=0x80cb5bc,
display_source_mode=0) at
/usr/src/php-5.2.1/sapi/apache/sapi_apache.c:53
#15 0x406c82b6 in send_php (r=0x80cb5bc, display_source_mode=0,
filename=0x0) at /usr/src/php-5.2.1/sapi/apache/mod_php5.c:663
#16 0x406c84c6 in send_parsed_php (r=0x80cb5bc) at
/usr/src/php-5.2.1/sapi/apache/mod_php5.c:678
#17 0x08053ff7 in ap_invoke_handler ()
#18 0x08069039 in process_re
#40839 [Opn->Bgs]: Mac OS X compile error
ID: 40839 Updated by: [EMAIL PROTECTED] Reported By: genetiq at gmail dot com -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Mac OS X 10.4.9 PHP Version: 5.2.1 New Comment: This constant is defined in Apache headers. If it's not defined, that's not PHP issue. Previous Comments: [2007-03-16 18:21:13] genetiq at gmail dot com the problem exists in both official 5.2.1 release and recent 5.2dev CVS snapshot. [2007-03-16 18:07:14] genetiq at gmail dot com Description: Cannot compile with apache 2.2.1 - problem in function php_ap2_register_hook actually, before compiler stops with the described error, it issued about 700 string of diferent error messages. Actual result: -- /etc/src/php52dev/sapi/apache2handler/sapi_apache2.c: In function 'php_ap2_register_hook': /etc/src/php52dev/sapi/apache2handler/sapi_apache2.c:656: error: 'APR_HOOK_MIDDLE' undeclared (first use in this function) make: *** [sapi/apache2handler/sapi_apache2.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=40839&edit=1
#40838 [NEW]: Built-in template rule for processing-instruction()|comment() missing
From: korisu at gmail dot com
Operating system: Windows Vista
PHP version: 5.2.1
PHP Bug Type: XSLT related
Bug description: Built-in template rule for processing-instruction()|comment()
missing
Description:
The default (built-in) template for processing instructions and comments
is not implemented in the current version of libxslt. The template should
be as follows:
This is defined in the W3C recommendation
(http://www.w3.org/TR/xslt#built-in-rule).
The files used in the test code can be found here:
http://scott.trenda.net/xml/php-bug-report/test.php (source pasted to
"Reproduce Code" section)
http://scott.trenda.net/xml/php-bug-report/checkerboard.xml
http://scott.trenda.net/xml/php-bug-report/checkerboard.xsl
http://scott.trenda.net/xml/php-bug-report/checkerboard2.xsl
This has been reproduced on Windows Vista, running 5.2.1 through IIS7
(ISAPI), and on Linux running 5.1.2 through Apache 2.0
(http://scott.trenda.net/phpinfo.php).
Reproduce code:
---
Incorrect transformation:
importStyleSheet(DOMDocument::load("checkerboard.xsl"));
echo $xslt->transformToXML(DOMDocument::load("checkerboard.xml"));
?>
Correct transformation (built-in stylesheet explicitly defined in
checkerboard2.xsl)
importStyleSheet(DOMDocument::load("checkerboard2.xsl"));
echo $xslt->transformToXML(DOMDocument::load("checkerboard.xml"));
?>
Expected result:
The first example does not have a template defined for processing
instructions and comments; if you view the source, you will see the
xml-stylesheet processing instruction from the source, and the test
comment following it:
The second example has the template explicitly defined as per the W3C
Recommendation; its source has neither the xml-stylesheet processing
instruction nor the test comment.
Actual result:
--
Incorrect transformation:
table { border: 1px solid gray; border-collapse:
collapse; }
td { width: 40px; height: 40px; }
.cell0 { background-color: black; }
.cell1 { background-color: white; }
Correct transformation (built-in stylesheet explicitly defined in
checkerboard2.xsl)
table { border: 1px solid gray; border-collapse:
collapse; }
td { width: 40px; height: 40px; }
.cell0 { background-color: black; }
.cell1 { background-color: white; }
--
Edit bug report at http://bugs.php.net/?id=40838&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40838&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40838&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40838&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40838&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40838&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40838&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40838&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40838&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40838&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40838&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40838&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40838&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40838&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40838&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40838&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40838&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40838&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40838&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40838&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40838&r=mysqlcfg
#40839 [NEW]: Mac OS X compile error
From: genetiq at gmail dot com Operating system: Mac OS X 10.4.9 PHP version: 5.2.1 PHP Bug Type: Compile Failure Bug description: Mac OS X compile error Description: Cannot compile with apache 2.2.1 - problem in function php_ap2_register_hook actually, before compiler stops with the described error, it issued about 700 string of diferent error messages. Actual result: -- /etc/src/php52dev/sapi/apache2handler/sapi_apache2.c: In function 'php_ap2_register_hook': /etc/src/php52dev/sapi/apache2handler/sapi_apache2.c:656: error: 'APR_HOOK_MIDDLE' undeclared (first use in this function) make: *** [sapi/apache2handler/sapi_apache2.lo] Error 1 -- Edit bug report at http://bugs.php.net/?id=40839&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40839&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40839&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40839&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40839&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40839&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40839&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40839&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40839&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40839&r=support Expected behavior:http://bugs.php.net/fix.php?id=40839&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40839&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40839&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40839&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40839&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40839&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40839&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40839&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40839&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40839&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40839&r=mysqlcfg
#40838 [Bgs]: Built-in template rule for processing-instruction()|comment() missing
ID: 40838
User updated by: korisu at gmail dot com
Reported By: korisu at gmail dot com
Status: Bogus
Bug Type: XSLT related
Operating System: Windows Vista
PHP Version: 5.2.1
New Comment:
... So it is. Forgot that node() will match processing-instruction()
and comment(), and this behavior comes from the element. Thanks!
(and sorry about the bug-file)
Previous Comments:
[2007-03-16 17:29:11] [EMAIL PROTECTED]
it's a libxslt issue, if at all, as you correctly realized by yourself.
Please complain there, if you really think, it's a bug.
But you have a
matcher, which also matches to processing-instruction() and comment()
nodes...
If you change that to everything works like
expected
[2007-03-16 16:58:16] korisu at gmail dot com
Description:
The default (built-in) template for processing instructions and
comments is not implemented in the current version of libxslt. The
template should be as follows:
This is defined in the W3C recommendation
(http://www.w3.org/TR/xslt#built-in-rule).
The files used in the test code can be found here:
http://scott.trenda.net/xml/php-bug-report/test.php (source pasted to
"Reproduce Code" section)
http://scott.trenda.net/xml/php-bug-report/checkerboard.xml
http://scott.trenda.net/xml/php-bug-report/checkerboard.xsl
http://scott.trenda.net/xml/php-bug-report/checkerboard2.xsl
This has been reproduced on Windows Vista, running 5.2.1 through IIS7
(ISAPI), and on Linux running 5.1.2 through Apache 2.0
(http://scott.trenda.net/phpinfo.php).
Reproduce code:
---
Incorrect transformation:
importStyleSheet(DOMDocument::load("checkerboard.xsl"));
echo
$xslt->transformToXML(DOMDocument::load("checkerboard.xml"));
?>
Correct transformation (built-in stylesheet explicitly defined
in checkerboard2.xsl)
importStyleSheet(DOMDocument::load("checkerboard2.xsl"));
echo
$xslt->transformToXML(DOMDocument::load("checkerboard.xml"));
?>
Expected result:
The first example does not have a template defined for processing
instructions and comments; if you view the source, you will see the
xml-stylesheet processing instruction from the source, and the test
comment following it:
The second example has the template explicitly defined as per the W3C
Recommendation; its source has neither the xml-stylesheet processing
instruction nor the test comment.
Actual result:
--
Incorrect transformation:
table { border: 1px solid gray; border-collapse:
collapse; }
td { width: 40px; height: 40px; }
.cell0 { background-color: black; }
.cell1 { background-color: white; }
Correct transformation (built-in stylesheet explicitly defined
in checkerboard2.xsl)
table { border: 1px solid gray; border-collapse:
collapse; }
td { width: 40px; height: 40px; }
.cell0 { background-color: black; }
.cell1 { background-color: white; }
--
Edit this bug report at http://bugs.php.net/?id=40838&edit=1
#40839 [Opn]: Mac OS X compile error
ID: 40839 User updated by: genetiq at gmail dot com Reported By: genetiq at gmail dot com Status: Open Bug Type: Compile Failure Operating System: Mac OS X 10.4.9 PHP Version: 5.2.1 New Comment: the problem exists in both official 5.2.1 release and recent 5.2dev CVS snapshot. Previous Comments: [2007-03-16 18:07:14] genetiq at gmail dot com Description: Cannot compile with apache 2.2.1 - problem in function php_ap2_register_hook actually, before compiler stops with the described error, it issued about 700 string of diferent error messages. Actual result: -- /etc/src/php52dev/sapi/apache2handler/sapi_apache2.c: In function 'php_ap2_register_hook': /etc/src/php52dev/sapi/apache2handler/sapi_apache2.c:656: error: 'APR_HOOK_MIDDLE' undeclared (first use in this function) make: *** [sapi/apache2handler/sapi_apache2.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=40839&edit=1
#40837 [Opn->Bgs]: static and non-static functions can't have the same name
ID: 40837
Updated by: [EMAIL PROTECTED]
Reported By: nick dot telford at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: Irrelevant
PHP Version: 5.2.1
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:
[2007-03-16 16:44:17] nick dot telford at gmail dot com
Description:
When declaring two functions in a class (methods) non-static and static
functions may not use the same names.
While I understand this, this is essentially wrong since static methods
and non-static methods are entirely different.
This also leads me on to another bug/feature suggestion I'm about to
file about not being able to overload static attributes with
__set/__get.
Reproduce code:
---
class Example {
public static function test() {}
public function test() {}
}
$example = new Example();
$example->test();
Example::test();
Expected result:
No errors, all methods called correctly.
Actual result:
--
PHP errors with: Fatal error: Cannot redeclare Example::test()
--
Edit this bug report at http://bugs.php.net/?id=40837&edit=1
#40701 [Fbk->Opn]: no change
ID: 40701 User updated by: michaeldaly at magma dot ca -Summary: Memory allocation error Reported By: michaeldaly at magma dot ca -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Win XP Pro PHP Version: 5.2.2 New Comment: That version has no effect. However, I'm not so sure it's any different than the version I started with - Feb 28 build that included the early Feb memory fix. Previous Comments: [2007-03-14 11:31:32] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip A fix for memory manager was applied to CVS recently, it might solve this issue. [2007-03-13 04:55:55] michaeldaly at magma dot ca With memory_limit = -1 there is no change. [2007-03-12 03:40:34] [EMAIL PROTECTED] Just out of the curiousity: what happens when you disable memory limit altogether? memory_limit=-1 [2007-03-07 16:04:57] michaeldaly at magma dot ca > It _does_ report 8Mb - "PHP Fatal error: Out of memory (allocated > 8388608) (tried to allocate 393216 bytes)". It also reports from 786KB to 9.2MB, so it appears that if the problem is a limit set externally, that limit is floating dynamically. > Yes, please search for "memory_limit" in your scripts,.htacess > and httpd.conf. I searched for "memory" in the entire Apache directory tree and found nothing that resembles a limit. I looked through httpd.conf and httpd_vhosts.conf visually and can find nothing else that looks like a memory restriction. The only limit I can find is in PHP.ini. [2007-03-07 09:13:06] [EMAIL PROTECTED] >PHP does _not_ report 8MB - it reports 512MB as per the php.ini setting. It _does_ report 8Mb - "PHP Fatal error: Out of memory (allocated 8388608) (tried to allocate 393216 bytes)". >This is reported in phpinfo.php. memory_limit can be changed per-virtualhost, per-directory and per-script. Therefore phpinfo() might show you 512Mb, but the real script might use different value. >Is there a way for me to capture some kind of debug information >that can help you? Yes, please search for "memory_limit" in your scripts,.htacess and httpd.conf. 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/40701 -- Edit this bug report at http://bugs.php.net/?id=40701&edit=1
#40838 [Opn->Bgs]: Built-in template rule for processing-instruction()|comment() missing
ID: 40838
Updated by: [EMAIL PROTECTED]
Reported By: korisu at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: XSLT related
Operating System: Windows Vista
PHP Version: 5.2.1
New Comment:
it's a libxslt issue, if at all, as you correctly realized by yourself.
Please complain there, if you really think, it's a bug.
But you have a
matcher, which also matches to processing-instruction() and comment()
nodes...
If you change that to everything works like
expected
Previous Comments:
[2007-03-16 16:58:16] korisu at gmail dot com
Description:
The default (built-in) template for processing instructions and
comments is not implemented in the current version of libxslt. The
template should be as follows:
This is defined in the W3C recommendation
(http://www.w3.org/TR/xslt#built-in-rule).
The files used in the test code can be found here:
http://scott.trenda.net/xml/php-bug-report/test.php (source pasted to
"Reproduce Code" section)
http://scott.trenda.net/xml/php-bug-report/checkerboard.xml
http://scott.trenda.net/xml/php-bug-report/checkerboard.xsl
http://scott.trenda.net/xml/php-bug-report/checkerboard2.xsl
This has been reproduced on Windows Vista, running 5.2.1 through IIS7
(ISAPI), and on Linux running 5.1.2 through Apache 2.0
(http://scott.trenda.net/phpinfo.php).
Reproduce code:
---
Incorrect transformation:
importStyleSheet(DOMDocument::load("checkerboard.xsl"));
echo
$xslt->transformToXML(DOMDocument::load("checkerboard.xml"));
?>
Correct transformation (built-in stylesheet explicitly defined
in checkerboard2.xsl)
importStyleSheet(DOMDocument::load("checkerboard2.xsl"));
echo
$xslt->transformToXML(DOMDocument::load("checkerboard.xml"));
?>
Expected result:
The first example does not have a template defined for processing
instructions and comments; if you view the source, you will see the
xml-stylesheet processing instruction from the source, and the test
comment following it:
The second example has the template explicitly defined as per the W3C
Recommendation; its source has neither the xml-stylesheet processing
instruction nor the test comment.
Actual result:
--
Incorrect transformation:
table { border: 1px solid gray; border-collapse:
collapse; }
td { width: 40px; height: 40px; }
.cell0 { background-color: black; }
.cell1 { background-color: white; }
Correct transformation (built-in stylesheet explicitly defined
in checkerboard2.xsl)
table { border: 1px solid gray; border-collapse:
collapse; }
td { width: 40px; height: 40px; }
.cell0 { background-color: black; }
.cell1 { background-color: white; }
--
Edit this bug report at http://bugs.php.net/?id=40838&edit=1
#40837 [NEW]: static and non-static functions can't have the same name
From: nick dot telford at gmail dot com
Operating system: Irrelevant
PHP version: 5.2.1
PHP Bug Type: Class/Object related
Bug description: static and non-static functions can't have the same name
Description:
When declaring two functions in a class (methods) non-static and static
functions may not use the same names.
While I understand this, this is essentially wrong since static methods
and non-static methods are entirely different.
This also leads me on to another bug/feature suggestion I'm about to file
about not being able to overload static attributes with __set/__get.
Reproduce code:
---
class Example {
public static function test() {}
public function test() {}
}
$example = new Example();
$example->test();
Example::test();
Expected result:
No errors, all methods called correctly.
Actual result:
--
PHP errors with: Fatal error: Cannot redeclare Example::test()
--
Edit bug report at http://bugs.php.net/?id=40837&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40837&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40837&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40837&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40837&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40837&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40837&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40837&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40837&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40837&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40837&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40837&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40837&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40837&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40837&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40837&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40837&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40837&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40837&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40837&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40837&r=mysqlcfg
#40479 [Com]: zend_mm_heap corrupted
ID: 40479
Comment by: rocker_pr at hotmail dot com
Reported By: rrossi at maggioli dot it
Status: No Feedback
Bug Type: Reproducible crash
Operating System: Suse Linux 9.0
PHP Version: 5.2.1
New Comment:
I have the same problem with zend_mm_heap corrupted on the error logs,
when I tried to open one of the pages I programmed it show me some
internal server error and that error message was in the log.
Same version php 5.2.1
I migrated my classes from php 5 to work with php 4, all worked fine
again, but then for experimenting purpose I switched back from php 4 to
php 5, but this time not using the keywords: private, public, constuctor
and destructor. I keep the php 4 compatibility, but running the scripts
on php 5.2.1 and it worked fine.
So i think that maybe there is a problem with the memory management on
the classes or objects, I´m not sure, but that was producing the
problem in my case.
Previous Comments:
[2007-03-12 07:25:14] noah at hd dot se
Fwiw, I experienced the same error with the following code and the
latest PHP.
...
for($i = 0; $i < $foo; $i++) {
...
for($i = 0; $i < $bar; $i++) {
...
}
...
}
...
[2007-03-06 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-02-26 22:14:48] [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.
[2007-02-26 22:10:47] tlongren at gmail dot com
I've tried the latest CVS snapshot and this problem still occurs there.
[2007-02-22 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
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/40479
--
Edit this bug report at http://bugs.php.net/?id=40479&edit=1
#40835 [Opn->Asn]: "Incompatible with prototype" warnings
ID: 40835 Updated by: [EMAIL PROTECTED] Reported By: ian at onlineloop dot com -Status: Open +Status: Assigned Bug Type: Compile Warning Operating System: Solaris 10 PHP Version: 5.2.1 -Assigned To: +Assigned To: tony2001 New Comment: Most of these warnings can be safely ignored (and do not exist if you use less strict compiler). Previous Comments: [2007-03-16 15:34:49] ian at onlineloop dot com OK, so it seems no text file attachments are possible, as such a link to the build history. http://www.meduniwien.ac.at/user/ib/php-5.2.1-solaris10_build.log.gz As for access to a machine, I will try to arrange something in the next couple of weeks. [2007-03-16 15:04:39] [EMAIL PROTECTED] It would be very good to have an access to a machine with Sun Compiler, just for tests. As far as I know at the moment none of developers use Sun Compiler or test the builds using it. [2007-03-16 14:56:42] ian at onlineloop dot com Description: When compiling PHP 5.2.1 on Solaris 10, sparc, with Studio 10 compilers from Sun Microsystems, the build completes, however there are numerous warnings about the prototype declarations not matching their usage in the source code. A number of external libraries, such as libxml2, openssl, openldap, and so on have been compiled from source on the same system with the same compiler. Because of the large number of warnings and the resulting size of the output, a text file will be added to this report containing a complete history of the build, or failing that a link to a url. If further information is needed, please tell me and I will provide it asap. # uname -a SunOS devel 5.10 Generic sun4u sparc SUNW,Sun-Fire-V440 # cc -V cc: Sun C 5.7 2005/01/07 # ld -V ild: Sun Incremental Linker 4.3 2005/01/07 # env | grep FLA LDFLAGS=-L/opt/sfw/lib -L/usr/sfw/lib -L/usr/local/open-ldap/lib -L/usr/lib -L/usr/local/BerkeleyDB/lib -R/opt/sfw/lib -R/usr/sfw/lib -R/usr/local/open-ldap/lib -R/usr/local/BerkeleyDB/lib -R/usr/lib CPPFLAGS=-I/opt/sfw/include -I/usr/sfw/include/openssl -I/usr/local/open-ldap/include -I/usr/local/BerkeleyDB/include/ -I/usr/include CFLAGS=-I/opt/sfw/include -I/usr/sfw/include/openssl -I/usr/local/open-ldap/include -I/usr/local/BerkeleyDB/include -I/usr/include -- Edit this bug report at http://bugs.php.net/?id=40835&edit=1
#40836 [Opn->Asn]: Segfault in ext/dom
ID: 40836
Updated by: [EMAIL PROTECTED]
Reported By: hannes dot magnusson at gmail dot com
-Status: Open
+Status: Assigned
Bug Type: Reproducible crash
Operating System: FreeBSD
PHP Version: 5CVS-2007-03-16 (CVS)
-Assigned To:
+Assigned To: rrichards
Previous Comments:
[2007-03-16 15:28:55] hannes dot magnusson at gmail dot com
Description:
See reproduce code
Reproduce code:
---
preserveWhiteSpace = false;
$xml = '
http://www.w3.org/2005/Atom";>
http://www.w3.org/2005/Atom";>
2007-02-14T00:00:00+01:00
http://www.w3.org/1999/xhtml";>
paragraph
';
$dom->loadXML($xml);
$entry = $dom->getElementsByTagNameNS("http://www.w3.org/2005/Atom";,
"entry")->item(0);
$contentNode =
$entry->getElementsByTagName("content")->item(0)->firstChild;
$dateNode=
$entry->getElementsByTagName("updated")->item(0)->firstChild;
$contentNode->firstChild->insertBefore($dateNode);
Actual result:
--
#0 xmlFreeNodeList (cur=0x5a5a5a5a) at tree.c:3364
3364if (cur->type == XML_NAMESPACE_DECL) {
[New LWP 100095]
(gdb) bt
#0 xmlFreeNodeList (cur=0x5a5a5a5a) at tree.c:3364
#1 0x28562ce5 in xmlFreeNodeList (cur=0x28997b80) at tree.c:3386
#2 0x28562ce5 in xmlFreeNodeList (cur=0x28997c40) at tree.c:3386
#3 0x28562ce5 in xmlFreeNodeList (cur=0x28997c00) at tree.c:3386
#4 0x28562ce5 in xmlFreeNodeList (cur=0x28997bc0) at tree.c:3386
#5 0x28562ce5 in xmlFreeNodeList (cur=0x28997b00) at tree.c:3386
#6 0x28562ce5 in xmlFreeNodeList (cur=0x28997ac0) at tree.c:3386
#7 0x28563485 in xmlFreeDoc (cur=0x28840ac0) at tree.c:1216
#8 0x08082a84 in php_libxml_decrement_doc_ref (object=0x288ce8b0) at
/usr/src/php/5.2/ext/libxml/libxml.c:966
#9 0x080c9f5f in dom_objects_free_storage (object=0x288ce8b0) at
/usr/src/php/5.2/ext/dom/php_dom.c:977
#10 0x082c3308 in zend_objects_store_del_ref_by_handle (handle=1) at
/usr/src/php/5.2/Zend/zend_objects_API.c:206
#11 0x082c31c3 in zend_objects_store_del_ref (zobject=0x288ccbac) at
/usr/src/php/5.2/Zend/zend_objects_API.c:168
#12 0x082a3680 in _zval_dtor_func (zvalue=0x288ccbac,
__zend_filename=0x83b9778 "/usr/src/php/5.2/Zend/zend_variables.h",
__zend_lineno=35) at /usr/src/php/5.2/Zend/zend_variables.c:52
#13 0x08297767 in _zval_dtor (zvalue=0x288ccbac,
__zend_filename=0x83b971c "/usr/src/php/5.2/Zend/zend_execute_API.c",
__zend_lineno=414) at zend_variables.h:35
#14 0x08297920 in _zval_ptr_dtor (zval_ptr=0x288ce488,
__zend_filename=0x83ba784 "/usr/src/php/5.2/Zend/zend_variables.c",
__zend_lineno=175) at /usr/src/php/5.2/Zend/zend_execute_API.c:414
#15 0x082a394f in _zval_ptr_dtor_wrapper (zval_ptr=0x288ce488) at
/usr/src/php/5.2/Zend/zend_variables.c:175
#16 0x082af2ee in zend_hash_apply_deleter (ht=0x83ec710, p=0x288ce47c)
at /usr/src/php/5.2/Zend/zend_hash.c:611
#17 0x082af769 in zend_hash_reverse_apply (ht=0x83ec710,
apply_func=0x82972a4 )
at /usr/src/php/5.2/Zend/zend_hash.c:760
#18 0x08297326 in shutdown_destructors () at
/usr/src/php/5.2/Zend/zend_execute_API.c:211
#19 0x082a4ce2 in zend_call_destructors () at
/usr/src/php/5.2/Zend/zend.c:845
#20 0x0825cce6 in php_request_shutdown (dummy=0x0) at
/usr/src/php/5.2/main/main.c:1280
#21 0x0830c15b in main (argc=2, argv=0xbfbfebec) at
/usr/src/php/5.2/sapi/cli/php_cli.c:1294
gdb) frame 1
#1 0x28562ce5 in xmlFreeNodeList (cur=0x2899a300) at tree.c:3386
3386xmlFreeNodeList(cur->children);
(gdb) p *cur
$1 = {_private = 0x5a5a5a5a, type = 1515870810, name = 0x5a5a5a5a
, children = 0x5a5a5a5a,
last = 0x5a5a5a5a, parent = 0x5a5a5a5a, next = 0x5a5a5a5a, prev =
0x5a5a5a5a, doc = 0x5a5a5a5a, ns = 0x5a5a5a5a,
content = 0x5a5a5a5a , properties =
0x5a5a5a5a, nsDef = 0x5a5a5a5a, psvi = 0x5a5a5a5a,
line = 23130, extra = 23130}
(gdb)
--
Edit this bug report at http://bugs.php.net/?id=40836&edit=1
#36008 [Com]: incorrect round() & number_format() result
ID: 36008 Comment by: me at nospam dot com Reported By: adi at rogers dot com Status: No Feedback Bug Type: Math related Operating System: win32 only PHP Version: 5CVS-2006-06-14 New Comment: I don't have a simpler test case, but in doing more testing, I found that the rounding apparently just doesn't work. When you print out a number that was rounded, it will appear correctly, but when you try to do math functions with other similar numbers (ie 6.08 - 6.08), I will get a remainder of like 2.039283e-16. However, setting the type to each variable as a string made it work correctly. Previous Comments: [2007-01-15 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-01-09 02:56:14] terrychangsharp at gmail dot com I tested the code on PC + FreeBSD 6.1 + Apache 2.2.3 + PHP 5.2.0 and get the same results. Actually, the seemingly coincident numbers $num and $num_same_thing are in fact not the same thing: $num - $num_same_thing yields -1.7763568394003E-015, not zero, so $num is smaller than 14.375 and round($num) is 14.37, not 14.38. Thus this "bug" is more like a floating point error thing, not a real bug. [2007-01-07 04:07:29] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-10-31 00:39:37] adi at rogers dot com Aww well it's too late for me to bug it for Windows Vista as we've entered Release Candidate 2 :( I'll test this again on IIS7 with the final version of Vista... [2006-10-30 13:30:58] dave at koales dot co dot uk I think this is a Windows vs others thing. I have the same rounding error using PHP 5.0.5 on Windows XP SP2. The same problem does not exist on my webhost, who use PHP 4.3.9 and Redhat Linux (need any more detail). The code I used was: echo "Correct VAT = " . round( 0.525, 2 ) . "\r\n"; echo "Wrong VAT = " . round( 3 * ( 17.5 / 100.0 ), 2 ) . "\r\n"; Outputs 0.53 for each on webhost (under Linux) and 0.52 for the second test under Windows (0.53 for the first test). I've also had very bizarre rounding errors with MySQL. The rounding error came and went depending on how the calculation was constructed! 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/36008 -- Edit this bug report at http://bugs.php.net/?id=36008&edit=1
#40835 [Fbk->Opn]: "Incompatible with prototype" warnings
ID: 40835 User updated by: ian at onlineloop dot com Reported By: ian at onlineloop dot com -Status: Feedback +Status: Open Bug Type: Compile Warning Operating System: Solaris 10 PHP Version: 5.2.1 New Comment: OK, so it seems no text file attachments are possible, as such a link to the build history. http://www.meduniwien.ac.at/user/ib/php-5.2.1-solaris10_build.log.gz As for access to a machine, I will try to arrange something in the next couple of weeks. Previous Comments: [2007-03-16 15:04:39] [EMAIL PROTECTED] It would be very good to have an access to a machine with Sun Compiler, just for tests. As far as I know at the moment none of developers use Sun Compiler or test the builds using it. [2007-03-16 14:56:42] ian at onlineloop dot com Description: When compiling PHP 5.2.1 on Solaris 10, sparc, with Studio 10 compilers from Sun Microsystems, the build completes, however there are numerous warnings about the prototype declarations not matching their usage in the source code. A number of external libraries, such as libxml2, openssl, openldap, and so on have been compiled from source on the same system with the same compiler. Because of the large number of warnings and the resulting size of the output, a text file will be added to this report containing a complete history of the build, or failing that a link to a url. If further information is needed, please tell me and I will provide it asap. # uname -a SunOS devel 5.10 Generic sun4u sparc SUNW,Sun-Fire-V440 # cc -V cc: Sun C 5.7 2005/01/07 # ld -V ild: Sun Incremental Linker 4.3 2005/01/07 # env | grep FLA LDFLAGS=-L/opt/sfw/lib -L/usr/sfw/lib -L/usr/local/open-ldap/lib -L/usr/lib -L/usr/local/BerkeleyDB/lib -R/opt/sfw/lib -R/usr/sfw/lib -R/usr/local/open-ldap/lib -R/usr/local/BerkeleyDB/lib -R/usr/lib CPPFLAGS=-I/opt/sfw/include -I/usr/sfw/include/openssl -I/usr/local/open-ldap/include -I/usr/local/BerkeleyDB/include/ -I/usr/include CFLAGS=-I/opt/sfw/include -I/usr/sfw/include/openssl -I/usr/local/open-ldap/include -I/usr/local/BerkeleyDB/include -I/usr/include -- Edit this bug report at http://bugs.php.net/?id=40835&edit=1
#40836 [NEW]: Segfault in ext/dom
From: hannes dot magnusson at gmail dot com
Operating system: FreeBSD
PHP version: 5CVS-2007-03-16 (CVS)
PHP Bug Type: Reproducible crash
Bug description: Segfault in ext/dom
Description:
See reproduce code
Reproduce code:
---
preserveWhiteSpace = false;
$xml = '
http://www.w3.org/2005/Atom";>
http://www.w3.org/2005/Atom";>
2007-02-14T00:00:00+01:00
http://www.w3.org/1999/xhtml";>
paragraph
';
$dom->loadXML($xml);
$entry = $dom->getElementsByTagNameNS("http://www.w3.org/2005/Atom";,
"entry")->item(0);
$contentNode =
$entry->getElementsByTagName("content")->item(0)->firstChild;
$dateNode=
$entry->getElementsByTagName("updated")->item(0)->firstChild;
$contentNode->firstChild->insertBefore($dateNode);
Actual result:
--
#0 xmlFreeNodeList (cur=0x5a5a5a5a) at tree.c:3364
3364if (cur->type == XML_NAMESPACE_DECL) {
[New LWP 100095]
(gdb) bt
#0 xmlFreeNodeList (cur=0x5a5a5a5a) at tree.c:3364
#1 0x28562ce5 in xmlFreeNodeList (cur=0x28997b80) at tree.c:3386
#2 0x28562ce5 in xmlFreeNodeList (cur=0x28997c40) at tree.c:3386
#3 0x28562ce5 in xmlFreeNodeList (cur=0x28997c00) at tree.c:3386
#4 0x28562ce5 in xmlFreeNodeList (cur=0x28997bc0) at tree.c:3386
#5 0x28562ce5 in xmlFreeNodeList (cur=0x28997b00) at tree.c:3386
#6 0x28562ce5 in xmlFreeNodeList (cur=0x28997ac0) at tree.c:3386
#7 0x28563485 in xmlFreeDoc (cur=0x28840ac0) at tree.c:1216
#8 0x08082a84 in php_libxml_decrement_doc_ref (object=0x288ce8b0) at
/usr/src/php/5.2/ext/libxml/libxml.c:966
#9 0x080c9f5f in dom_objects_free_storage (object=0x288ce8b0) at
/usr/src/php/5.2/ext/dom/php_dom.c:977
#10 0x082c3308 in zend_objects_store_del_ref_by_handle (handle=1) at
/usr/src/php/5.2/Zend/zend_objects_API.c:206
#11 0x082c31c3 in zend_objects_store_del_ref (zobject=0x288ccbac) at
/usr/src/php/5.2/Zend/zend_objects_API.c:168
#12 0x082a3680 in _zval_dtor_func (zvalue=0x288ccbac,
__zend_filename=0x83b9778 "/usr/src/php/5.2/Zend/zend_variables.h",
__zend_lineno=35) at /usr/src/php/5.2/Zend/zend_variables.c:52
#13 0x08297767 in _zval_dtor (zvalue=0x288ccbac, __zend_filename=0x83b971c
"/usr/src/php/5.2/Zend/zend_execute_API.c",
__zend_lineno=414) at zend_variables.h:35
#14 0x08297920 in _zval_ptr_dtor (zval_ptr=0x288ce488,
__zend_filename=0x83ba784 "/usr/src/php/5.2/Zend/zend_variables.c",
__zend_lineno=175) at /usr/src/php/5.2/Zend/zend_execute_API.c:414
#15 0x082a394f in _zval_ptr_dtor_wrapper (zval_ptr=0x288ce488) at
/usr/src/php/5.2/Zend/zend_variables.c:175
#16 0x082af2ee in zend_hash_apply_deleter (ht=0x83ec710, p=0x288ce47c) at
/usr/src/php/5.2/Zend/zend_hash.c:611
#17 0x082af769 in zend_hash_reverse_apply (ht=0x83ec710,
apply_func=0x82972a4 )
at /usr/src/php/5.2/Zend/zend_hash.c:760
#18 0x08297326 in shutdown_destructors () at
/usr/src/php/5.2/Zend/zend_execute_API.c:211
#19 0x082a4ce2 in zend_call_destructors () at
/usr/src/php/5.2/Zend/zend.c:845
#20 0x0825cce6 in php_request_shutdown (dummy=0x0) at
/usr/src/php/5.2/main/main.c:1280
#21 0x0830c15b in main (argc=2, argv=0xbfbfebec) at
/usr/src/php/5.2/sapi/cli/php_cli.c:1294
gdb) frame 1
#1 0x28562ce5 in xmlFreeNodeList (cur=0x2899a300) at tree.c:3386
3386xmlFreeNodeList(cur->children);
(gdb) p *cur
$1 = {_private = 0x5a5a5a5a, type = 1515870810, name = 0x5a5a5a5a , children = 0x5a5a5a5a,
last = 0x5a5a5a5a, parent = 0x5a5a5a5a, next = 0x5a5a5a5a, prev =
0x5a5a5a5a, doc = 0x5a5a5a5a, ns = 0x5a5a5a5a,
content = 0x5a5a5a5a , properties =
0x5a5a5a5a, nsDef = 0x5a5a5a5a, psvi = 0x5a5a5a5a,
line = 23130, extra = 23130}
(gdb)
--
Edit bug report at http://bugs.php.net/?id=40836&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40836&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40836&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40836&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40836&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40836&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40836&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40836&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40836&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40836&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40836&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40836&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40836&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40836&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40836&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40836&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40836&r=isapi
Install GNU
#37865 [Com]: The SNMP extension does not support setting multiple OIDs
ID: 37865 Comment by: eqguy2002 at yahoo dot com Reported By: lee dot duncan at intel dot com Status: Open Bug Type: Feature/Change Request Operating System: SUSE, Kernel 2.6.8-24.21-smp PHP Version: 5.1.4 New Comment: Version: 5.2.1 OS: Windows 2003 PHP's snmpset extension does not support setting multiple OIDs at once. Doing so from the command line using snmpset from Net-SNMP works fine. I need to set multiple OIDs at once in order to manage switches Previous Comments: [2006-06-21 00:09:05] lee dot duncan at intel dot com Description: In order to add an entry to many SNMP tables, you need to be able to set multiple OIDs (values) at the same time. The net-snmp "snmpset" command allows this, as do the libnetsnmp APIs, but the SNMP extension to PHP does not support this. I added a new function to ext/snmp.c to support setting multiple values at once, and I'd like to see it added to the PHP SNMP extension for all to use. Reproduce code: --- Just try to set multiple SNMP OIDs (object IDs) with the current API, which is: proto int snmp2_set(string host, string community, string object_id, string type, mixed value [, int timeout [, int retries]]) I added: proto int snmp2_set_arr(string host, string community, array oids, array types, array values [, int timeout [, int retries]]) This way, no current programs break and new programs can use this functionality. Expected result: I'd like to be able to manage things like Marvell switches, which only allow adding a Table entry (e.g. for a new VLAN) if you can set multiple values (OIDs) at the same time. Actual result: -- Right now I can't do this without hacking the PHP SNMP extension. -- Edit this bug report at http://bugs.php.net/?id=37865&edit=1
#40835 [Opn->Fbk]: "Incompatible with prototype" warnings
ID: 40835 Updated by: [EMAIL PROTECTED] Reported By: ian at onlineloop dot com -Status: Open +Status: Feedback Bug Type: Compile Warning Operating System: Solaris 10 PHP Version: 5.2.1 New Comment: It would be very good to have an access to a machine with Sun Compiler, just for tests. As far as I know at the moment none of developers use Sun Compiler or test the builds using it. Previous Comments: [2007-03-16 14:56:42] ian at onlineloop dot com Description: When compiling PHP 5.2.1 on Solaris 10, sparc, with Studio 10 compilers from Sun Microsystems, the build completes, however there are numerous warnings about the prototype declarations not matching their usage in the source code. A number of external libraries, such as libxml2, openssl, openldap, and so on have been compiled from source on the same system with the same compiler. Because of the large number of warnings and the resulting size of the output, a text file will be added to this report containing a complete history of the build, or failing that a link to a url. If further information is needed, please tell me and I will provide it asap. # uname -a SunOS devel 5.10 Generic sun4u sparc SUNW,Sun-Fire-V440 # cc -V cc: Sun C 5.7 2005/01/07 # ld -V ild: Sun Incremental Linker 4.3 2005/01/07 # env | grep FLA LDFLAGS=-L/opt/sfw/lib -L/usr/sfw/lib -L/usr/local/open-ldap/lib -L/usr/lib -L/usr/local/BerkeleyDB/lib -R/opt/sfw/lib -R/usr/sfw/lib -R/usr/local/open-ldap/lib -R/usr/local/BerkeleyDB/lib -R/usr/lib CPPFLAGS=-I/opt/sfw/include -I/usr/sfw/include/openssl -I/usr/local/open-ldap/include -I/usr/local/BerkeleyDB/include/ -I/usr/include CFLAGS=-I/opt/sfw/include -I/usr/sfw/include/openssl -I/usr/local/open-ldap/include -I/usr/local/BerkeleyDB/include -I/usr/include -- Edit this bug report at http://bugs.php.net/?id=40835&edit=1
#40828 [Bgs]: Overloading: "Indirect modification" with "$this->foo[] = $x"
ID: 40828
User updated by: phpbugs at thequod dot de
Reported By: phpbugs at thequod dot de
Status: Bogus
Bug Type: Arrays related
Operating System: Ubuntu Linux
PHP Version: 5CVS-2007-03-15 (CVS)
New Comment:
>>Can't PHP internally do "$this->test = array()"?
>No, it can't do your job for you. You have to do it in the __get()
method.
1. It also won't work with
function &__get($name)
{
echo "__get() called.\n";
$r = array();
return $r;
}
2. It would not make sense to init any unknown/unhandled property
as "array()" anyway
3. Your comment works, if you remove the "(array)" typecast in
&__get() - it will cause "Only variable references should be
returned by reference" otherwise
4. I'm not looking for support, but state that "$this->foo[]" is not
supported in overloading - in contrast what you would expect
Please note that this is different from bug 40823, where _any_
property (which goes through __get()) gets handled as Foo::array!
What I want to work is:
Only handle some members as overloaded properties (e.g. $foo and
$bar), but let all others work as intended - and that
means "$A->foobar[]=" should work, just like "$foobar[]=" does.
Please make sure you really understand what the problem IMHO is
here!
At least this should get closed as "Wont fix" and documented on
http://php.net/manual/en/language.oop5.overloading.php.
See also
http://php.net/manual/en/language.oop5.overloading.php#73512
Previous Comments:
[2007-03-15 19:45:15] [EMAIL PROTECTED]
Please, if you have any other _questions_ - ask them on a support
forum.
[2007-03-15 19:44:25] [EMAIL PROTECTED]
>as Tony stated in http://bugs.php.net/bug.php?id=40823
>(the code in his comment does not work (anymore?)).
The code in my comment works perfectly fine.
>Can't PHP internally do "$this->test = array()"?
No, it can't do your job for you. You have to do it in the __get()
method.
[2007-03-15 19:35:49] phpbugs at thequod dot de
Description:
If a member of an object is not defined and "gets initialized" by
PHP after/during the overloading process, a notice ("Indirect
modification of overloaded property") gets triggered when PHP has to
initialize it as an array type.
It makes no difference, if __get() returns by reference instead (a
ref to a null value), as Tony stated in
http://bugs.php.net/bug.php?id=40823 (the code in his comment does
not work (anymore?)).
Background: we have a base class "Plugin" in our project and it uses
__get() for some properties and returns null otherwise.
Now, if some user-created plugin does
$this->foo[] = 'bar'
it will create this notice - which is quite confusing (if the
derived plugin does not "init" $foo with "var $foo").
Can't PHP internally do "$this->test = array()"?
(This may likely be a dupe of http://bugs.php.net/bug.php?id=39337 -
but that one got quite confusing, so this one here may become
a "reference bogus bug" for this issue at least.)
Reproduce code:
---
test[] = 'foo';
}
}
$A = new A();
?>
Expected result:
__get() called.
Actual result:
--
__get() called.
Notice: Indirect modification of overloaded property A::$test has no
effect in foo.php on line 12
--
Edit this bug report at http://bugs.php.net/?id=40828&edit=1
#40835 [NEW]: "Incompatible with prototype" warnings
From: ian at onlineloop dot com Operating system: Solaris 10 PHP version: 5.2.1 PHP Bug Type: Compile Warning Bug description: "Incompatible with prototype" warnings Description: When compiling PHP 5.2.1 on Solaris 10, sparc, with Studio 10 compilers from Sun Microsystems, the build completes, however there are numerous warnings about the prototype declarations not matching their usage in the source code. A number of external libraries, such as libxml2, openssl, openldap, and so on have been compiled from source on the same system with the same compiler. Because of the large number of warnings and the resulting size of the output, a text file will be added to this report containing a complete history of the build, or failing that a link to a url. If further information is needed, please tell me and I will provide it asap. # uname -a SunOS devel 5.10 Generic sun4u sparc SUNW,Sun-Fire-V440 # cc -V cc: Sun C 5.7 2005/01/07 # ld -V ild: Sun Incremental Linker 4.3 2005/01/07 # env | grep FLA LDFLAGS=-L/opt/sfw/lib -L/usr/sfw/lib -L/usr/local/open-ldap/lib -L/usr/lib -L/usr/local/BerkeleyDB/lib -R/opt/sfw/lib -R/usr/sfw/lib -R/usr/local/open-ldap/lib -R/usr/local/BerkeleyDB/lib -R/usr/lib CPPFLAGS=-I/opt/sfw/include -I/usr/sfw/include/openssl -I/usr/local/open-ldap/include -I/usr/local/BerkeleyDB/include/ -I/usr/include CFLAGS=-I/opt/sfw/include -I/usr/sfw/include/openssl -I/usr/local/open-ldap/include -I/usr/local/BerkeleyDB/include -I/usr/include -- Edit bug report at http://bugs.php.net/?id=40835&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40835&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40835&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40835&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40835&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40835&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40835&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40835&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40835&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40835&r=support Expected behavior:http://bugs.php.net/fix.php?id=40835&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40835&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40835&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40835&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40835&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40835&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40835&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40835&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40835&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40835&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40835&r=mysqlcfg
#40749 [Com]: pack and unpack erroneous behavior on 64bits hosts
ID: 40749
Comment by: martin at netimage dot dk
Reported By: ben at ateor dot com
Status: Open
Bug Type: Unknown/Other Function
Operating System: OpenBSD amd64 and sparc64
PHP Version: 5.2.1
New Comment:
It appears that the sign bit is taken from LSB instead of MSB
> php -r 'print_r( unpack('N',pack('N',127)));'
Array
(
[1] => 127
)
> php -r 'print_r( unpack('N',pack('N',128)));'
Array
(
[1] => -2147483520
)
The last number is 2's complement of -128 for 32 bit integers
Cheers
Previous Comments:
[2007-03-14 20:57:41] pz at mysqlperformanceblog dot com
In any case if you call it bug or a feature this is serious behavior
change for something which a lot of people could be depending on.
It breaks in MySQL 5.2.0 -> 5.2.1 which is minor version upgrade.
[2007-03-09 09:06:47] windeler at mediafinanz dot de
Here is another example of a problem with unpack on 64bit systems. It
worked in 5.1.6, but with 5.2.1 the results are bogus.
The expected value from the file content is 200, but PHP says
-2147483448 when I echo $a['i'].
[2007-03-07 17:12:58] ben at ateor dot com
Description:
This is a follow-up on #40543 (http://bugs.php.net/bug.php?id=40543,
since
that bug is closed, I can't add comments).
Please note : it's not identical to #4053 (other weird behaviors
are demonstrated).
Iliaa,
Not sure why you suggest to use little endian or host conversions
routines,
but in my standpoint if you reverse twice a number's byte ordering
then you should get the original number back (assuming the number
don't
overflows php's internals).
At least, that's the standard behavior for perl and python.
Beside, I can't see why php should handles those endianness
conversions
differently on an i386 (32 bits) and on an x86_64 (64 bits), both
having the same byte order.
The following on a 64bit, little endian host :
x86_64$ uname -mprsv
OpenBSD 4.0 GENERIC#0 amd64 AMD Sempron(tm) Processor 3400+
x86_64$ perl -e 'print unpack("N", pack("N", 41445)) ."\n"'
41445
x86_64$ python
Python 2.4.3 (#1, Sep 6 2006, 20:33:08)
[GCC 3.3.5 (propolice)] on openbsd4
Type "help", "copyright", "credits" or "license" for more information.
>>> from struct import *
>>> unpack('>L', pack('>L', 41445))
(41445L,)
And, indeed :
#include
#include
int main(void)
{
u_int32_t x, y, z; /* 32 bits unsigned longs */
x = 41445;
/* conv host (little) to network (big endian) long : pack("N",
41445) */
y = htonl(x);
/* conv network (big endian) to host (little) long :
unpack("N", ...) */
z = ntohl(y);
printf("Host : %li\nBig : %li\nHost : %li\n", x, y, z);
return 0;
}
x86_64$ gcc conv.c -o conv ; ./conv
Host : 41445
Big : -442433536
Host : 41445
But still (PHP 5.2.2-dev (cli) (built: Feb 27 2007 22:10:11)) :
x86_64$ php -r 'print_r(unpack("N", pack("N", 41445)));'
Array
(
[1] => -2147442203
)
While on a plain old x86 little endian host (PHP 4.4.0), we get
a different result :
i386_32$ uname -mprsv
OpenBSD 3.9 GENERIC#0 i386 Intel(R) Pentium(R) 4 CPU 1.70GHz
("GenuineIntel" 686-class)
i386_32$ php -r 'print_r(unpack("N", pack("N", 41445)));'
Array
(
[1] => 41445
)
Still on the 64 bits little endian host :
x86_64$ php -r '$a = unpack("N", pack("N", 65536));
printf("$a[1]\n");'
65536 # Ok
x86_64$ php -r '$a = unpack("N", pack("N", 65535));
printf("$a[1]\n");'
-2147418113 # Weird
x86_64$ php -r '$a = unpack("N", pack("N", 0x1234)); printf("0x%x\n",
$a[1]);'
0x1234 # Ok
x86_64$ php -r '$a = unpack("L", pack("N", 0x1234)); printf("0x%x\n",
$a[1]);'
0x3412 # Ok
x86_64$ php -r '$a = unpack("L", pack("L", 0x)); printf("0x%x\n",
$a[1]);'
0x # Ok
x86_64$ php -r '$a = unpack("N", pack("N", 0x)); printf("0x%x\n",
$a[1]);'
0x8000 # The doc says "N" gives you "always 32 bit", and we
get
# 8 bytes. No wonder why we overflow.
x86_64$ php -r '$a = unpack("N", pack("N", 0xff )); printf("0x%x\n",
$a[1]);'
0x80ff # Same. Don't tell me 0xff is too large.
And now, all the following tests are on a 64 bits _big endian_ host
(sparc64, running php-5.2.1) :
sparc64$ uname -mprsv
OpenBSD 3.8 GENERIC#607 sparc64 SUNW,UltraSPARC-IIi @ 440 MHz, version
0 FPU
sparc64$ php -r '$a = unpack("N", pack("N", 0x)); printf("0x%x\n",
$a[1]);'
0x # Ok
# The same, but prefixing to the argument :
sparc64$ php -r '$a = unpack("N", pack("N", 0x));
printf("0x%x\n", $a[1]);'
0x8000
# Weird (and with "N", we stayed on the host byte order this time).
# Shouldn't 0x == 0x, even on big endian ? Apparently, yes
:
sparc64$ php -r 'printf("0x%x\n", 0x);'
0x
# Also, look at this :
sparc64$ php -r '
#40261 [Com]: Extremely slow data handling due to memory fragmentation
ID: 40261
Comment by: bloire at citytoo dot com
Reported By: thuejk at gmail dot com
Status: Assigned
Bug Type: Performance problem
Operating System: All
PHP Version: 5.2.0
Assigned To: dmitry
New Comment:
Real example ($a_output is a reference with 3000 results from mysql)
The probleme processing with memory is after these differents
solutions
Time for processing Solution 1 or 2 is not verry different.
The real probleme is after Solution 1 or 2 for all other processing
with memory !
$a_input[idlg] = $a_context[idlg];
node::select_node_no_finalsite($a_input,$a_output);
foreach ($a_output as $i => $a_row) {
/*
//Solution 1 : KO because verry verry verry SLOW
$a_data[a_formulaire][listenode2][$i][idn] = $a_row[idn];
$a_data[a_formulaire][listenode2][$i][traduction_idn] =
$a_row[traduction_idn];
$a_data[a_formulaire][listenode2][$i][traduction_idcat]=
$a_row[traduction_idcat];
$a_data[a_formulaire][listenode2][$i][idte_idn] = $a_row[idte_idn];
$a_data[a_formulaire][listenode2][$i][idte_idcat]=
$a_row[idte_idcat];
$a_data[a_formulaire][listenode2][$i][idcat] =
$a_row[idcat];
$a_data[a_formulaire][listenode2][$i][name] = $a_row[name];
$a_data[a_formulaire][listenode2][$i][idsite] =
$a_row[idsite];
*/
//Solution 2 : OK :-) 15 milliseconds
$a_data[a_formulaire][listenode2] = $a_row;
}
//Times here depends choice at top lines !!!
//Times is 6518 milliseconds if solution 1 KO :-(
//Times is 16 milliseconds if solution is 2 OK
$instance_time=new time;
$instance_time->execute("test","start");
for($i=0;$i<5;$i++){
$a .= "k";
}
//print $a;
$instance_time->execute("test","stop");
print $instance_time->show();
Verry stange behavior for only 5 concats !!!
It's not normal because no probleme before php < 5.2
Previous Comments:
[2007-03-16 13:35:53] bloire at citytoo dot com
My version is 5.2.1 the lastest with mandake limited edition 2005 and
fedora core 4
The probleme exist always with php 5.2.1 !!! The latest release
!
Probleme looks like :
function test(&$b){
//sql Query...
//$a_result_mysql
//No problem with performance with php 5.2.1 (6 secondes)
foreach($a_result_mysql as $i=> $a_row) {
$b[artist][item][$i] = $a_row;
}
//Very very very very very very very very very slow with php 5.2 (180
secondes)
//normal with php < 5.2 (10 secondes)
foreach($a_result_mysql as $i=> $a_row) {
$b[artist][item][$i][name] = $a_row[name];
$b[artist][item][$i][firstname] = $a_row[firstname];
$b[artist][item][$i][address] = $a_row[address];
$b[artist][item][$i][zip] = $a_row[name];
$b[artist][item][$i][color] = $a_row[color];
}
}
test($b);
[2007-03-16 13:02:56] bloire at citytoo dot com
I have exactly the same probleme with foreach with big rows from mysql
and reaffection for each field for each row
After that, all processing is verry verry verry VERRY slow. It's
HORRIBLE. It's verry strange because I didn"t have this probleme with
php < 5.2
I hope that will be repair because now, I'm not trusting with php 5.2
Thank you for all
[2007-03-16 12:09:04] thuejk at gmail dot com
I think I am hitting this in practice, or something like it.
I have a function call
And I can see that for some reason, the time between "returning" and
"returned" is 60 seconds! This only happens the first time this
function is called, for some reason. Installing php 5.1.6 it returns
instantaneously.
I liked thet PHP 5.1 memory allocator better :(. The PHP 5.1 memory
allocator was also 1/4 the size of the PHP 5.2 memory allocator.
[2007-01-30 14:53:40] thuejk at gmail dot com
The latest PHP snapshot does fix my example, and probably makes my
production code work.
This will probably fix the problem in far most cases. But it is
possible to construct an example which still have the problematic
behavior. One example is below.
[2007-01-30 14:03:32] [EMAIL PROTECTED]
Please try PHP_5_2 snapshot. It already uses litle bit different
"best-fit" implementation and this script takes reasonable time (near
the same as 5.1).
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://bug
#40261 [Com]: Extremely slow data handling due to memory fragmentation
ID: 40261
Comment by: bloire at citytoo dot com
Reported By: thuejk at gmail dot com
Status: Assigned
Bug Type: Performance problem
Operating System: All
PHP Version: 5.2.0
Assigned To: dmitry
New Comment:
My version is 5.2.1 the lastest with mandake limited edition 2005 and
fedora core 4
The probleme exist always with php 5.2.1 !!! The latest release
!
Probleme looks like :
function test(&$b){
//sql Query...
//$a_result_mysql
//No problem with performance with php 5.2.1 (6 secondes)
foreach($a_result_mysql as $i=> $a_row) {
$b[artist][item][$i] = $a_row;
}
//Very very very very very very very very very slow with php 5.2 (180
secondes)
//normal with php < 5.2 (10 secondes)
foreach($a_result_mysql as $i=> $a_row) {
$b[artist][item][$i][name] = $a_row[name];
$b[artist][item][$i][firstname] = $a_row[firstname];
$b[artist][item][$i][address] = $a_row[address];
$b[artist][item][$i][zip] = $a_row[name];
$b[artist][item][$i][color] = $a_row[color];
}
}
test($b);
Previous Comments:
[2007-03-16 13:02:56] bloire at citytoo dot com
I have exactly the same probleme with foreach with big rows from mysql
and reaffection for each field for each row
After that, all processing is verry verry verry VERRY slow. It's
HORRIBLE. It's verry strange because I didn"t have this probleme with
php < 5.2
I hope that will be repair because now, I'm not trusting with php 5.2
Thank you for all
[2007-03-16 12:09:04] thuejk at gmail dot com
I think I am hitting this in practice, or something like it.
I have a function call
And I can see that for some reason, the time between "returning" and
"returned" is 60 seconds! This only happens the first time this
function is called, for some reason. Installing php 5.1.6 it returns
instantaneously.
I liked thet PHP 5.1 memory allocator better :(. The PHP 5.1 memory
allocator was also 1/4 the size of the PHP 5.2 memory allocator.
[2007-01-30 14:53:40] thuejk at gmail dot com
The latest PHP snapshot does fix my example, and probably makes my
production code work.
This will probably fix the problem in far most cases. But it is
possible to construct an example which still have the problematic
behavior. One example is below.
[2007-01-30 14:03:32] [EMAIL PROTECTED]
Please try PHP_5_2 snapshot. It already uses litle bit different
"best-fit" implementation and this script takes reasonable time (near
the same as 5.1).
[2007-01-29 13:24:47] thuejk at gmail dot com
I added a few printf's and found out that the $num generated "holes" in
the memory are 384 big.
Zend has a special system for small allocations, but that only works
for holes below ZEND_MM_SMALL_SIZE=280.
The $num allocations at the end, which cause the problems, and 40 or 88
long.
Note that these numbers are from a 64-bit machine, which of course has
8-byte pointers, and so a larger MM overhead. (The bug does also occur
on 32bit machines)
One temporary solution could be to raise
#define ZEND_MM_NUM_BUCKETS 32
from which ZEND_MM_SMALL_SIZE is defined, so that ZEND_MM_SMALL_SIZE is
made twice or perhaps 4 times as big. (I got a segfault when I tried
that, haven't looked into why)
A better solution would be to organize the free blocks in a balanced
tree, instead of a linear list which has to be traversed.
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/40261
--
Edit this bug report at http://bugs.php.net/?id=40261&edit=1
#40261 [Com]: Extremely slow data handling due to memory fragmentation
ID: 40261
Comment by: bloire at citytoo dot com
Reported By: thuejk at gmail dot com
Status: Assigned
Bug Type: Performance problem
Operating System: All
PHP Version: 5.2.0
Assigned To: dmitry
New Comment:
I have exactly the same probleme with foreach with big rows from mysql
and reaffection for each field for each row
After that, all processing is verry verry verry VERRY slow. It's
HORRIBLE. It's verry strange because I didn"t have this probleme with
php < 5.2
I hope that will be repair because now, I'm not trusting with php 5.2
Thank you for all
Previous Comments:
[2007-03-16 12:09:04] thuejk at gmail dot com
I think I am hitting this in practice, or something like it.
I have a function call
And I can see that for some reason, the time between "returning" and
"returned" is 60 seconds! This only happens the first time this
function is called, for some reason. Installing php 5.1.6 it returns
instantaneously.
I liked thet PHP 5.1 memory allocator better :(. The PHP 5.1 memory
allocator was also 1/4 the size of the PHP 5.2 memory allocator.
[2007-01-30 14:53:40] thuejk at gmail dot com
The latest PHP snapshot does fix my example, and probably makes my
production code work.
This will probably fix the problem in far most cases. But it is
possible to construct an example which still have the problematic
behavior. One example is below.
[2007-01-30 14:03:32] [EMAIL PROTECTED]
Please try PHP_5_2 snapshot. It already uses litle bit different
"best-fit" implementation and this script takes reasonable time (near
the same as 5.1).
[2007-01-29 13:24:47] thuejk at gmail dot com
I added a few printf's and found out that the $num generated "holes" in
the memory are 384 big.
Zend has a special system for small allocations, but that only works
for holes below ZEND_MM_SMALL_SIZE=280.
The $num allocations at the end, which cause the problems, and 40 or 88
long.
Note that these numbers are from a 64-bit machine, which of course has
8-byte pointers, and so a larger MM overhead. (The bug does also occur
on 32bit machines)
One temporary solution could be to raise
#define ZEND_MM_NUM_BUCKETS 32
from which ZEND_MM_SMALL_SIZE is defined, so that ZEND_MM_SMALL_SIZE is
made twice or perhaps 4 times as big. (I got a segfault when I tried
that, haven't looked into why)
A better solution would be to organize the free blocks in a balanced
tree, instead of a linear list which has to be traversed.
[2007-01-29 01:42:28] thuejk at gmail dot com
Ok, after a good deal of work I actually tracked down the problem to
fragmentation in your memory management.
This understanding enabled me to construct a simpler test case. Note
that the problem is unrelated to database function, and this new
testcase does not require any database.
free_buckets[0];
* for (p = end->next_free_block; p != end; p = p->next_free_block) {
*size_t s = ZEND_MM_FREE_BLOCK_SIZE(p);
*if (s > true_size) {
* if (s < best_size) {// better fit
*best_fit = p;
*best_size = s;
* }
*} else if (s == true_size) {
* // Found "big" free block of exactly the same size
* best_fit = p;
* goto zend_mm_finished_searching_for_block;
*}
* }
*/
$c = Array();
for ($i=0; $i<$num; $i++) {
$c[$i] = 1;
}
?>
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/40261
--
Edit this bug report at http://bugs.php.net/?id=40261&edit=1
#40261 [Asn]: Extremely slow data handling due to memory fragmentation
ID: 40261
User updated by: thuejk at gmail dot com
Reported By: thuejk at gmail dot com
Status: Assigned
Bug Type: Performance problem
Operating System: All
PHP Version: 5.2.0
Assigned To: dmitry
New Comment:
I think I am hitting this in practice, or something like it.
I have a function call
And I can see that for some reason, the time between "returning" and
"returned" is 60 seconds! This only happens the first time this
function is called, for some reason. Installing php 5.1.6 it returns
instantaneously.
I liked thet PHP 5.1 memory allocator better :(. The PHP 5.1 memory
allocator was also 1/4 the size of the PHP 5.2 memory allocator.
Previous Comments:
[2007-01-30 14:53:40] thuejk at gmail dot com
The latest PHP snapshot does fix my example, and probably makes my
production code work.
This will probably fix the problem in far most cases. But it is
possible to construct an example which still have the problematic
behavior. One example is below.
[2007-01-30 14:03:32] [EMAIL PROTECTED]
Please try PHP_5_2 snapshot. It already uses litle bit different
"best-fit" implementation and this script takes reasonable time (near
the same as 5.1).
[2007-01-29 13:24:47] thuejk at gmail dot com
I added a few printf's and found out that the $num generated "holes" in
the memory are 384 big.
Zend has a special system for small allocations, but that only works
for holes below ZEND_MM_SMALL_SIZE=280.
The $num allocations at the end, which cause the problems, and 40 or 88
long.
Note that these numbers are from a 64-bit machine, which of course has
8-byte pointers, and so a larger MM overhead. (The bug does also occur
on 32bit machines)
One temporary solution could be to raise
#define ZEND_MM_NUM_BUCKETS 32
from which ZEND_MM_SMALL_SIZE is defined, so that ZEND_MM_SMALL_SIZE is
made twice or perhaps 4 times as big. (I got a segfault when I tried
that, haven't looked into why)
A better solution would be to organize the free blocks in a balanced
tree, instead of a linear list which has to be traversed.
[2007-01-29 01:42:28] thuejk at gmail dot com
Ok, after a good deal of work I actually tracked down the problem to
fragmentation in your memory management.
This understanding enabled me to construct a simpler test case. Note
that the problem is unrelated to database function, and this new
testcase does not require any database.
free_buckets[0];
* for (p = end->next_free_block; p != end; p = p->next_free_block) {
*size_t s = ZEND_MM_FREE_BLOCK_SIZE(p);
*if (s > true_size) {
* if (s < best_size) {// better fit
*best_fit = p;
*best_size = s;
* }
*} else if (s == true_size) {
* // Found "big" free block of exactly the same size
* best_fit = p;
* goto zend_mm_finished_searching_for_block;
*}
* }
*/
$c = Array();
for ($i=0; $i<$num; $i++) {
$c[$i] = 1;
}
?>
[2007-01-28 01:52:37] thuejk at gmail dot com
On second though, black boxes are not good for testing. A simpler timer
added...
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/40261
--
Edit this bug report at http://bugs.php.net/?id=40261&edit=1
#40833 [NEW]: Crash when using unset() on an ArrayAccess object retrieved via __get()
From: daan at parse dot nl
Operating system: Slackware 10.2
PHP version: 5.2.1
PHP Bug Type: Reproducible crash
Bug description: Crash when using unset() on an ArrayAccess object retrieved
via __get()
Description:
When trying to trigger the magic offsetUnset() method on a variable which
itself is retrieved via a magic __get() method, some sort of
object/variable corruption occurs.
If the unset() is applied in two operations, it does not crash.
Also, to trigger this crash, the object must be re-assigned via
'resetSelf()'.
Reproduce code:
---
data[$name]) )
return $this->data[$name];
else
return $this->data[$name] = new set($this,
$name);
}
function __set($name, $value)
{
$this->modified[$name] = $value;
}
}
class set implements ArrayAccess
{
private $entity;
private $name;
function __construct($entity, $name)
{
$this->entity = $entity;
$this->name = $name;
}
function offsetUnset($offset)
{
$this->entity->{$this->name} = null;
}
function offsetSet($offset, $value)
{
}
function offsetGet($offset)
{
return 'Bogus';
}
function offsetExists($offset)
{
}
function resetSelf()
{
$this->entity->{$this->name} = $this;
}
}
$entity = new entity();
$entity->whatever->resetSelf();
echo $entity->whatever[0];
//This will crash
unset($entity->whatever[0]);
//This will not crash (comment previous & uncomment this to test
// $test = $entity->whatever; unset($test[0]);
echo $entity->whatever[0];
var_dump($entity);
echo 'All good';
?>
Expected result:
The string 'BogusBogusAllGood'.
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 654)]
0x4065de11 in zend_object_store_get_object (zobject=0x18302664) at
/usr/src/php-5.2.1/Zend/zend_objects_API.c:255
255 return
EG(objects_store).object_buckets[handle].bucket.obj.object;
(gdb) bt
#0 0x4065de11 in zend_object_store_get_object (zobject=0x18302664) at
/usr/src/php-5.2.1/Zend/zend_objects_API.c:255
#1 0x4065b05f in zend_std_get_properties (object=0x810099c) at
/usr/src/php-5.2.1/Zend/zend_object_handlers.c:55
#2 0x405dc642 in php_var_dump (struc=0x8100a9c, level=5) at
/usr/src/php-5.2.1/ext/standard/var.c:140
#3 0x405dc921 in php_array_element_dump (zv=0x8100a9c, num_args=1,
args=0x80f1188 "", hash_key=0xbfffc550) at
/usr/src/php-5.2.1/ext/standard/var.c:64
#4 0x4064e4d0 in zend_hash_apply_with_arguments (ht=0x8100ac4,
apply_func=0x405dc8c0 , num_args=1)
at /usr/src/php-5.2.1/Zend/zend_hash.c:729
#5 0x405dc6cf in php_var_dump (struc=0x80fa794, level=3) at
/usr/src/php-5.2.1/ext/standard/var.c:152
#6 0x405dc870 in php_object_property_dump (zv=0x80fa794, num_args=1,
args=0xbfffc63c "\001", hash_key=0x8) at
/usr/src/php-5.2.1/ext/standard/var.c:96
#7 0x4064e4d0 in zend_hash_apply_with_arguments (ht=0x80fb0b0,
apply_func=0x405dc7c0 , num_args=1)
at /usr/src/php-5.2.1/Zend/zend_hash.c:729
#8 0x405dc6cf in php_var_dump (struc=0x80f0bf0, level=1) at
/usr/src/php-5.2.1/ext/standard/var.c:152
#9 0x405dc9be in zif_var_dump (ht=1, return_value=0x8100e5c,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=0)
at /usr/src/php-5.2.1/ext/standard/var.c:193
#10 0x40660b14 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffc8e0) at
/usr/src/php-5.2.1/Zend/zend_vm_execute.h:200
#11 0x40660249 in execute (op_array=0x80fa554) at
/usr/src/php-5.2.1/Zend/zend_vm_execute.h:92
#12 0x40645274 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /usr/src/php-5.2.1/Zend/zend.c:1135
#13 0x4060990a in php_execute_script (primary_file=0xbfffebb0) at
/usr/src/php-5.2.1/main/main.c:1784
#14 0x406c7842 in apache_php_module_main (r=0x80cb5bc,
display_source_mode=0) at /usr/src/php-5.2.1/sapi/apache/sapi_apache.c:53
#15 0x406c82b6 in send_php (r=0x80cb5bc, display_source_mode=0,
filename=0x0) at /usr/src/php-5.2.1/sapi/apache/mod_php5.c:663
#16 0x406c84c6 in send_parsed_php (r=0x80cb5bc) at
/usr/src/php-5.2.1/sapi/apache/mod_php5.c:678
#17 0x08053ff7 in ap_invoke_handler ()
#18 0x08069039 in process_request_internal ()
#19 0x08069098 in ap_process_request ()
#20 0x080600ba in child_main ()
#21 0x08060262 in make_child ()
#22 0x080603c8 in startup_children ()
#23 0x08060a88 in standalone_main ()
#24 0x080612a6
#26739 [Com]: __call() doesn't work for static methods
ID: 26739 Comment by: ecentinela at gmail dot com Reported By: demiurg at terra dot es Status: Open Bug Type: Feature/Change Request Operating System: * PHP Version: 5.0.0 New Comment: Have been resolved this issue? There is some workaround? Thanks Previous Comments: [2003-12-29 08:07:21] [EMAIL PROTECTED] __call() doesn't offer anything to distinguish between static and dynamic calls. So we'd need a new magic function say __static_call(). For 5.0.0 we have a feature freeze already, so this might take a while. [2003-12-29 07:50:16] demiurg at terra dot es Description: Hello, I'm not sure whether it is a bug or a feature, so I just point this out and you decide. __class() method works like OK for objects, but completely fails when calling a class method (see Reproduce Code). P.S. Before sending this report, I did a search on "__call" and have found 11 bugs, none of which describes the issue. Thanks! Reproduce code: --- test(1, 2, 3); a::test(3, 2, 1); ?> Expected result: Called test(1, 2, 3) Called test(3, 2, 1) Actual result: -- Called test(1, 2, 3) Fatal error: Call to undefined method a::test() in a.php on line 12 -- Edit this bug report at http://bugs.php.net/?id=26739&edit=1
