#43834 [Fbk->Opn]: zend_mm_shutdown - Apache Crash
ID: 43834
User updated by: jaco at jump dot co dot za
Reported By: jaco at jump dot co dot za
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: Windows 2003
PHP Version: 5.2CVS-2008-01-14 (snap)
New Comment:
I am unable to privide any code to re-produce this proplem. The best I
could figure out up to know is that the get_browser() function together
with the browscap.ini on windows on a busy website is not a good idea.
The bug does not appear every time, but after I removed all
get_browser() code from the site, the server did not crash again. We get
about 500,000 page impressions per day, and the error occured about
10-15 times a day.
Previous Comments:
[2008-01-28 23:37:39] [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.
[2008-01-14 07:10:29] jaco at jump dot co dot za
I got this in the user.dmp file:
In user.dmp the assembly instruction at php5ts!_zend_mm_free_int+139 in
C:\WINDOWS\system32\php5ts.dll from The PHP Group has caused an access
violation exception (0xC005) when trying to read from memory
location 0x697a6f59 on thread 7
[2008-01-14 06:45:43] jaco at jump dot co dot za
I finally got the symbol files to work, and the stack trace looks a bit
different now:
function: php5ts!_zend_mm_free_int
006aac9b 33c9 xor ecx,ecx
006aac9d 8b4718 mov eax,[edi+0x18]
006aaca0 85c0 testeax,eax
006aaca2 0f95c1 setne cl
006aaca5 8d448f14 lea eax,[edi+ecx*4+0x14]
006aaca9 8b4c8f14 mov ecx,[edi+ecx*4+0x14]
006aacad 85c9 testecx,ecx
006aacaf 75e6 jnz
php5ts!_zend_mm_free_int+0x117 (006aac97)
006aacb1 c702 mov dword ptr [edx],0x0
006aacb7 eb6f jmp
php5ts!_zend_mm_free_int+0x1a8 (006aad28)
FAULT ->006aacb9 395f0c cmp [edi+0xc],ebx
ds:0023:000c=
006aacbc 7505 jnz
php5ts!_zend_mm_free_int+0x143 (006aacc3)
006aacbe 395908 cmp [ecx+0x8],ebx
006aacc1 7410 jz
php5ts!_zend_mm_free_int+0x153 (006aacd3)
006aacc3 68cc629500 push0x9562cc
006aacc8 e883f6 callphp5ts!zend_mm_panic
(006aa350)
006aaccd 8b4dfc mov ecx,[ebp-0x4]
006aacd0 83c404 add esp,0x4
006aacd3 894f0c mov [edi+0xc],ecx
006aacd6 897908 mov [ecx+0x8],edi
006aacd9 8b03 mov eax,[ebx]
*> Stack Back Trace <*
ChildEBP RetAddr Args to Child
0236fae0 006abce9 080dab18 0002 00755f17
php5ts!_zend_mm_free_int+0x139 (CONV: cdecl)
0236faec 00755f17 01253a20 0b936cac 00735f13 php5ts!_efree+0x39 (FPO:
[1,0,0]) (CONV: cdecl)
0236faf8 00735f13 01253a78 0b936d20 0073a117
php5ts!_zval_dtor_func+0x27 (FPO: [1,0,1]) (CONV: cdecl)
0236fb04 0073a117 0b936cac 0b937348 0b927c00 php5ts!_zval_ptr_dtor+0x23
(FPO: [1,0,1]) (CONV: cdecl)
0236fb1c 00755f49 0b927c60 0b937354 00735f13
php5ts!zend_hash_destroy+0x27 (FPO: [EBP 0x0b927a40] [1,0,4]) (CONV:
cdecl)
0236fb28 00735f13 0b927c00 0b937420 0073a1a3
php5ts!_zval_dtor_func+0x59 (FPO: [1,0,1]) (CONV: cdecl)
0236fb34 0073a1a3 0b937354 0b925718 0236fc10 php5ts!_zval_ptr_dtor+0x23
(FPO: [1,0,1]) (CONV: cdecl)
0236fb4c 006bce7b 0b927a40 0b91f89e
php5ts!zend_hash_clean+0x23 (FPO: [EBP 0x0236fbb4] [1,0,4]) (CONV:
cdecl)
0236fb94 006bc465 0236fbb4 080d98a0 006bc3e5
php5ts!zend_do_fcall_common_helper_SPEC+0xa0b (FPO: [EBP 0x0236fb98]
[2,12,4]) (CONV: cdecl)
0236fba0 006bc3e5 0236fbb4 080d98a0 080d98a0
php5ts!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER+0x15 (FPO: [2,0,0]) (CONV:
cdecl)
0236fc28 0075b9fd 0008 080d98a0 php5ts!execute+0x1c5 (FPO:
[EBP 0x0b920598] [2,16,3]) (CONV: cdecl)
0236fc58 006abca9 7c827d0b 0040 06f4
php5ts!php_execute_script+0x20d (CONV: cdecl)
0236fc5c 7c827d0b 0040 06f4 php5ts!_emalloc+0x39 (FPO:
[1,0,0]) (CONV: cdecl)
WARNING: Stack unwind information not available. Following frames may
be wrong.
0236fc6c 77e61d43 08112da8 0236fcb8
ntdll!NtWaitForSingleObject+0xc
kernel32!WaitFo
#43990 [NEW]: session_start() - failed: Permission denied (13)
From: antonprk at mail dot ru Operating system: Linux PHP version: 4.4.8 PHP Bug Type: Session related Bug description: session_start() - failed: Permission denied (13) Description: In PHP 4.4.4, 4.4.7, 4.4.8, on a server more than 200 users at which periodically arise the specified error. In php.ini add an option the name of a file of session. 2008-01-31 05:33:36 Warning(2): Unknown(): open(/tmp/sess_842bfb761b488cb7c0df711a162f6b56, O_RDWR) failed: Permission denied (13) in /home/USER_ONE/lib/session.inc (/eng.php) on line 24 [EMAIL PROTECTED] [/tmp]# ls -l --full-time sess_842bfb761b488cb7c0df711a162f6b56 -rw--- 1 USER_TWO USER_TWO 46 2008-01-31 05:33:26.0 +0300 sess_842bfb761b488cb7c0df711a162f6b56 Two different users try to use one file of session. Reproduce code: --- USER_ONE USER_TWO Expected result: Creation of not existing file of session was expected. Actual result: -- Attempt of creation of already existing file of session. -- Edit bug report at http://bugs.php.net/?id=43990&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43990&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43990&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43990&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43990&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43990&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43990&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43990&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43990&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43990&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43990&r=support Expected behavior:http://bugs.php.net/fix.php?id=43990&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43990&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43990&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43990&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43990&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43990&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43990&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43990&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43990&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43990&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43990&r=mysqlcfg
#43989 [NEW]: bad php.net link
From: bill at texascrazy dot com Operating system: PHP version: 5.2.5 PHP Bug Type: *General Issues Bug description: bad php.net link Description: The php.net website has a bad link on this page: http://us3.php.net/manual/en/tutorial.firstpage.php See the PHP editor link -- Edit bug report at http://bugs.php.net/?id=43989&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43989&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43989&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43989&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43989&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43989&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43989&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43989&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43989&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43989&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43989&r=support Expected behavior:http://bugs.php.net/fix.php?id=43989&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43989&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43989&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43989&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43989&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43989&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43989&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43989&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43989&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43989&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43989&r=mysqlcfg
#43988 [NEW]: Problems with foreach'ing on arrays with referenced element
From: claim at interia dot pl Operating system: Linux 2.6.23 PHP version: 5.2.5 PHP Bug Type: Unknown/Other Function Bug description: Problems with foreach'ing on arrays with referenced element Description: The problem is that when you reference an array element (say, n) and then use the same name (as the reference) as the current element value alias inside foreach, two things happen: 1. inside the foreach body the n element is replaced with the n-1 element; 2. and after the foreach run the n element is replaced with the last array element. Reproduce code: --- Expected result: Array ( [0] => 0 [1] => 1 [2] => 2 [3] => 3 ) el: 0 el: 1 el: 2 el: 3 Array ( [0] => 0 [1] => 1 [2] => 2 [3] => 3 ) Actual result: -- Array ( [0] => 0 [1] => 1 [2] => 2 [3] => 3 ) el: 0 el: 1 el: 1 el: 3 Array ( [0] => 0 [1] => 1 [2] => 3 [3] => 3 ) -- Edit bug report at http://bugs.php.net/?id=43988&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43988&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43988&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43988&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43988&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43988&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43988&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43988&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43988&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43988&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43988&r=support Expected behavior:http://bugs.php.net/fix.php?id=43988&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43988&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43988&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43988&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43988&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43988&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43988&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43988&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43988&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43988&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43988&r=mysqlcfg
#43987 [NEW]: parse error when second instanceof operand is function call
From: ms419 at freezone dot co dot uk
Operating system: Debian
PHP version: 5.2.5
PHP Bug Type: Class/Object related
Bug description: parse error when second instanceof operand is function call
Description:
PHP raises a parse error when the second operand of an instanceof operator
is a function call. In my case, the function call,
$relatedTable->getPhpName(), returns the class name as a string, which I
want to determine whether $obj is an instance of.
Reproduce code:
---
if (!$obj instanceof $relatedTable->getPhpName())
{
if
(!isset($this->object_references[$relatedTable->getPhpName().'_'.$value]))
{
throw new sfException(sprintf('The object "%s" from
class "%s" is not defined in your data file.', $value,
$relatedTable->getPhpName()));
}
$value =
$this->object_references[$relatedTable->getPhpName().'_'.$value]->getPrimaryKey();
}
Expected result:
The instanceof operator should determine whether $obj is an instance of
the class name returned by $relatedTable->getPhpName()
Actual result:
--
Parse error: syntax error, unexpected '(' in
/home/jablko/public_html/qubit/lib/vendor/symfony/lib/plugins/sfPropelPlugin/lib/propel/sfPropelData.class.php
on line 133
Line 133 is the first line of the reproduce code: if (!$obj instanceof
$relatedTable->getPhpName())
This also raises a parse error: if (!$obj instanceof $relatedPhpName =
$relatedTable->getPhpName())
Parse error: syntax error, unexpected '=' in
/home/jablko/public_html/qubit/lib/vendor/symfony/lib/plugins/sfPropelPlugin/lib/propel/sfPropelData.class.php
on line 133
However the following works:
$relatedPhpName = $relatedTable->getPhpName();
if (!$obj instanceof $relatedPhpName)
{
if
(!isset($this->object_references[$relatedTable->getPhpName().'_'.$value]))
{
throw new sfException(sprintf('The object "%s" from
class "%s" is not defined in your data file.', $value,
$relatedTable->getPhpName()));
}
$value =
$this->object_references[$relatedTable->getPhpName().'_'.$value]->getPrimaryKey();
}
--
Edit bug report at http://bugs.php.net/?id=43987&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43987&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43987&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43987&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43987&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43987&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43987&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43987&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43987&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43987&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43987&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43987&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43987&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43987&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43987&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43987&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43987&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43987&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43987&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43987&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43987&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43987&r=mysqlcfg
#43341 [Com]: no libphp5.so or php cli binary created
ID: 43341 Comment by: geoffrey dot hughes at otago dot ac dot nz Reported By: jay3ld at yahoo dot com Status: Open Bug Type: Compile Failure Operating System: Mac os X 10.5 Leopard PHP Version: 5.3CVS-2007-11-20 (snap) New Comment: I've sort of fixed my issue. The libphp5.so was being installed but for some reason when I used apachectl to restart the webserver it wasn't actually doing anything. Had to use the Sharing prefpane. As to the php cli binary, it is being installed but for some reason it is being installed as php.dSYM. I've added a symbolic link of php that points to php.dSYM so when I update in future I won't have this hassle. I'd still love to know why leopard is installing the php cli as php.dSYM though. Previous Comments: [2008-01-30 20:55:57] geoffrey dot hughes at otago dot ac dot nz I notice that after running make, I have a php binary in ./sapi/cli and I have a libphp5.so in ./libs/ but it doesn't seem to install them when I run "make install" Copying them manually to their correct locations works. [2008-01-25 08:08:06] coder1 at gmail dot com I can reproduce the problem on CentOS 5.1. I took the configuration that came with a default install and re-compiled with 5.25. No php5lib.so is created or installed. [2007-12-07 20:40:14] b dot mcpherson at csuohio dot edu I'm having the same issue on AIX 5.3 64-bit PPC. Build complete. Don't forget to run 'make test'. # make test echo '\ \ Build complete. Don't forget to run 'make test'. ERROR: Cannot run tests without CLI sapi. # make install echo '\ \ Installing PHP SAPI module: nsapi cp: libs/libphp5.so: No such file or directory make: 1254-004 The error code from the last command is 1. Stop. The main directory has a libphp5.la file -rw-r--r-- 1 root system 2234 Dec 07 16:28 libphp5.la # cd libs # ls -l total 16704 -rw-r--r-- 1 root system 8547783 Dec 07 16:28 libphp5.a -rw-r--r-- 1 root system 2235 Dec 07 16:28 libphp5.la The libphp5.la file in the libs directory is not the same size. [2007-12-05 18:16:45] jesse dot charbneau at cengagelearning dot com Hello, I wanted to provide an update to my earlier post. I have performed the exact same steps on Suse 10 Enterprise. PHP built and installed without issue, and I was able to install a module via pecl. Does anyone know if this is correctable for Suse 9? [2007-12-05 16:31:21] jesse dot charbneau at cengagelearning dot com Hello, I have experienced this issue on multiple Suse Enterprise (v9.0 - v9.3) systems. This is to be used with Apache 2.2.6. Apache was configured, compiled and installed with: ./configure --enable-so --enable-rewrite --prefix=/opt/apache-2.2.6 --with-included-apr make make install (as root) I have tried multiple releases in the 5.2.x series (5.2.5, 5.2.4, 5.2.2) and have not been able to successfully get any of them to install the php-cli. I have been able to get it to install the module for apache, and so phpinfo() works and returns the correct page, but the requirements for this project need the cli (DAST). Here is the configure statement I am using with php: ./configure --with-libdir=lib64 --with-apxs2=/opt/apache-2.2.6/bin/apxs --prefix=/opt/apache-2.2.6 --with-mysql=/usr --with-mysqli=/usr/bin/mysql_config --with-gd --with-openssl=/usr --enable-soap --enable-sockets --with-xmlrpc --with-xsl --with-curl --with-zlib --with-pear make (works fine) make install (as root) returns: -- Installing PHP SAPI module: apache2handler /opt/apache-2.2.6/build/instdso.sh SH_LIBTOOL='/opt/apache-2.2.6/build/libtool' libphp5.la /opt/apache-2.2.6/modules /opt/apache-2.2.6/build/libtool --mode=install cp libphp5.la /opt/apache-2.2.6/modules/ libtool: install: error: cannot install `libphp5.la' to a directory not ending in /usr/src/packages/jess_temp/php-5.2.2/libs apxs:Error: Command failed with rc=65536 . make: *** [install-sapi] Error 1 -- Is this something with the release? Or should I be looking to update Suse or something? I am going to try compiling it on a Suse 10 box and see what turns up. Thanks, Jess 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/43341 -- Edit this bug report at http://bugs.php.net/?id=43341&edit=1
#43958 [Opn]: Reproduces on 5.3 nightly, 5.2.5 and 5.2.1 (live link)
ID: 43958 Updated by: [EMAIL PROTECTED] Reported By: sv4php at fmethod dot com Status: Open Bug Type: *General Issues Operating System: Windows XP PHP Version: 5.2.5 New Comment: My suggestion: http://ecl.zoone.com.br/etc/patches/bug43958.diff Previous Comments: [2008-01-29 11:30:43] kissifrot at gmail dot com Reproduces with PHP 5.2.5 on Windows Vista too PHP Version 5.2.5; Windows NT 6.0 build 6000; Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies This happens with require function too [2008-01-29 08:50:45] jck_true at hotmail dot com PHP Version 5.2.3 Build date: May 31 2007 09:36:39 Windows XP Profesional SP2 Reproduced [2008-01-29 08:18:42] sv4php at fmethod dot com Hi, I reproduced this on a 5.3 nightly just now (on XP), on 5.2.5 (on XP), and here's a live link to a 5.2.1 (on Linux, CentOS): http://www.fmethod.com/include_fail.php This is the same exact example, but I added phpversion() call. Note for the archives: I'll remove this link in few days. [2008-01-29 07:54:56] [EMAIL PROTECTED] I can not reproduce this btw [2008-01-29 07:51:03] sv4php at fmethod dot com Hi Derick, no, it's 5.2.5 stable official Win32 binary build, 100% (just made sure again). PHP Version 5.2.5; Windows NT SV 5.1 build 2600; Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies Also I believe I tested this with earlier 5.x builds and it was like that again, but I'm lazy to check again. Let me know if I have to, I can do that. Also notice there's no namespace used or defined in the example (and the namespace is not "php", but my class name, which makes no sense to me). 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/43958 -- Edit this bug report at http://bugs.php.net/?id=43958&edit=1
#42841 [Opn->Csd]: oci_new_cursor PHP crash
ID: 42841
Updated by: [EMAIL PROTECTED]
Reported By: pr0head at gmail dot com
-Status: Open
+Status: Closed
Bug Type: OCI8 related
Operating System: Linux version 2.6.20-gentoo-r8
PHP Version: 5.2.4
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2008-01-30 18:49:02] [EMAIL PROTECTED]
This was a latent bug exposed when statement caching was fixed.
The temporary workaround is to set oci8.statement_cache_size=0
The real solution (thanks to Sree) is to add a missing case for
cursors to the out-bind callback:
diff -u oci8_statement.c.orig oci8_statement.c
--- oci8_statement.c.orig 2008-01-30 10:37:32.0 -0800
+++ oci8_statement.c2008-01-30 10:21:31.0 -0800
@@ -1174,6 +1174,14 @@
}
if (Z_TYPE_P(val) == IS_RESOURCE) {
+ /* Processing for ref-cursor out binds */
+ if (phpbind->statement != NULL) {
+ *bufpp = phpbind->statement;
+ *alenpp = &phpbind->dummy_len;
+ *piecep = OCI_ONE_PIECE;
+ *rcodepp = &phpbind->retcode;
+ *indpp = &phpbind->indicator;
+ }
retval = OCI_CONTINUE;
} else if (Z_TYPE_P(val) == IS_OBJECT) {
if (!phpbind->descriptor) {
[2008-01-09 19:40:42] [EMAIL PROTECTED]
The original testcase (with the parameter only as OUT) does not crash
with OCI8 1.3.0 Beta from PECL.
[2007-12-14 18:53:08] michael dot virnstein at brodos dot de
This fix only works for out parameters, not for return values from
functions. I can't change thosea.
I also filed the bug (Bug #43449), haven't found the other two.
[2007-12-11 20:39:37] [EMAIL PROTECTED]
I reproduced the crash. The problem appears to be the same as reported
in http://bugs.php.net/bug.php?id=43340. If you change the PL/SQL
package definition so out_1 is an "IN OUT" parameter, there is no crash.
[2007-11-20 09:46:48] pr0head at gmail dot com
This script working normally if not reopen cursor.
Bad result:
$sql = "BEGIN sp_vadik_1( :cursor ); END;";
$stmt = oci_parse( $connection, $sql );
$cursor = oci_new_cursor( $connection );
oci_bind_by_name( $stmt, ":cursor", $cursor, -1, OCI_B_CURSOR );
oci_execute( $stmt, OCI_DEFAULT );
oci_execute( $cursor );
oci_free_statement( $stmt );
oci_free_statement( $cursor );
$sql = "BEGIN sp_vadik_1( :cursor ); END;";
$stmt = oci_parse( $connection, $sql );
$cursor = oci_new_cursor( $connection );
oci_bind_by_name( $stmt, ":cursor", $cursor, -1, OCI_B_CURSOR );
oci_execute( $stmt, OCI_DEFAULT );
oci_execute( $cursor );
oci_free_statement( $stmt );
oci_free_statement( $cursor );
Good result:
$sql = "BEGIN sp_vadik_1( :cursor ); END;";
$stmt = oci_parse( $connection, $sql );
$cursor = oci_new_cursor( $connection );
oci_bind_by_name( $stmt, ":cursor", $cursor, -1, OCI_B_CURSOR );
oci_execute( $stmt, OCI_DEFAULT );
oci_execute( $cursor );
oci_free_statement( $stmt );
$sql = "BEGIN sp_vadik_1( :cursor ); END;";
$stmt = oci_parse( $connection, $sql );
oci_bind_by_name( $stmt, ":cursor", $cursor, -1, OCI_B_CURSOR );
oci_execute( $stmt, OCI_DEFAULT );
oci_execute( $cursor );
oci_free_statement( $stmt );
oci_free_statement( $cursor );
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/42841
--
Edit this bug report at http://bugs.php.net/?id=42841&edit=1
#43861 [Opn]: suhosin patch detects heap overflow on mssql_free_result()
ID: 43861 Updated by: [EMAIL PROTECTED] Reported By: skennedy at vcn dot com Status: Open Bug Type: MSSQL related Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: Ok, there we go. Looks like there is an off-by-one in there. But looking at the PHP code, it seems ok. int res_length = dbdatlen(mssql_ptr->link,offset); ... res_buf = (unsigned char *) emalloc(res_length+1); res_length = dbconvert(NULL,coltype(offset),dbdata(mssql_ptr->link,offset), res_length, SQLCHAR,res_buf,-1); res_buf[res_length] = '\0'; So, we aren't going beyond the buffer, it is somewhere in the dbconvert() code writing to res_buf that is off. Passing in a larger buffer would fix it, but it would be good to understand why dbdatlen() isn't returning the right length. Is it an encoding issue? One assumes single-byte encoding and the other multi-byte or something? Looping in Frank to have a look. Previous Comments: [2008-01-30 21:23:02] skennedy at vcn dot com Okay, here is that: http://www.bandwidthbuilders.com/valgrind-output-nozendalloc.txt [2008-01-30 21:08:27] [EMAIL PROTECTED] Sometimes the Zend memory manager hides stuff as well. Could you please try disabling that by setting the "USE_ZEND_ALLOC" environment variable to 0? (Something like "export USE_ZEND_ALLOC=0" should do that). And then re-try to make a valgrind trace. Thanks! [2008-01-30 18:38:10] skennedy at vcn dot com That valgrind output *is* without the Suhosin patch. I was saying that I first compiled PHP w/ Suhosin patch to make sure it errors-out with the heap overflow as it does on my FreeBSD box and it did. Then I compiled PHP again this time w/out Suhosin and ran the valgrind which is the output you see in the link. [2008-01-30 17:56:21] [EMAIL PROTECTED] Again, that valgrind output does not show an overflow. Either the problem is being masked by the suhosin patch, or it is a false positive. Trying removing the suhosin patch and do the valgrind check again. [2008-01-30 17:21:28] skennedy at vcn dot com Rasmus, I tested if this same heap overflow would occur on my Linux box (Debian 4.0) by compiling my own very basic PHP 5.2.5 (./configure --with-mssql) w/ Sushosin patch. The result: same exact error as on FreeBSD. The original valgrind output I submitted was from the PHP installed via a Debian package. So I recompiled my PHP again this time without Sushosin patch and ran valgrind again. Updated output: http://www.bandwidthbuilders.com/valgrind-output.txt Let me know if you need me to do anything else. Thanks. 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/43861 -- Edit this bug report at http://bugs.php.net/?id=43861&edit=1
#43861 [Fbk->Opn]: suhosin patch detects heap overflow on mssql_free_result()
ID: 43861 User updated by: skennedy at vcn dot com Reported By: skennedy at vcn dot com -Status: Feedback +Status: Open Bug Type: MSSQL related Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: Okay, here is that: http://www.bandwidthbuilders.com/valgrind-output-nozendalloc.txt Previous Comments: [2008-01-30 21:08:27] [EMAIL PROTECTED] Sometimes the Zend memory manager hides stuff as well. Could you please try disabling that by setting the "USE_ZEND_ALLOC" environment variable to 0? (Something like "export USE_ZEND_ALLOC=0" should do that). And then re-try to make a valgrind trace. Thanks! [2008-01-30 18:38:10] skennedy at vcn dot com That valgrind output *is* without the Suhosin patch. I was saying that I first compiled PHP w/ Suhosin patch to make sure it errors-out with the heap overflow as it does on my FreeBSD box and it did. Then I compiled PHP again this time w/out Suhosin and ran the valgrind which is the output you see in the link. [2008-01-30 17:56:21] [EMAIL PROTECTED] Again, that valgrind output does not show an overflow. Either the problem is being masked by the suhosin patch, or it is a false positive. Trying removing the suhosin patch and do the valgrind check again. [2008-01-30 17:21:28] skennedy at vcn dot com Rasmus, I tested if this same heap overflow would occur on my Linux box (Debian 4.0) by compiling my own very basic PHP 5.2.5 (./configure --with-mssql) w/ Sushosin patch. The result: same exact error as on FreeBSD. The original valgrind output I submitted was from the PHP installed via a Debian package. So I recompiled my PHP again this time without Sushosin patch and ran valgrind again. Updated output: http://www.bandwidthbuilders.com/valgrind-output.txt Let me know if you need me to do anything else. Thanks. [2008-01-30 01:09:03] [EMAIL PROTECTED] I know that Valgrind output looks scary, but that is actually a clean run. The dlopen/dlclose stuff is normal. Are you seeing the same warning on this setup? 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/43861 -- Edit this bug report at http://bugs.php.net/?id=43861&edit=1
#43861 [Opn->Fbk]: suhosin patch detects heap overflow on mssql_free_result()
ID: 43861 Updated by: [EMAIL PROTECTED] Reported By: skennedy at vcn dot com -Status: Open +Status: Feedback Bug Type: MSSQL related Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: Sometimes the Zend memory manager hides stuff as well. Could you please try disabling that by setting the "USE_ZEND_ALLOC" environment variable to 0? (Something like "export USE_ZEND_ALLOC=0" should do that). And then re-try to make a valgrind trace. Thanks! Previous Comments: [2008-01-30 18:38:10] skennedy at vcn dot com That valgrind output *is* without the Suhosin patch. I was saying that I first compiled PHP w/ Suhosin patch to make sure it errors-out with the heap overflow as it does on my FreeBSD box and it did. Then I compiled PHP again this time w/out Suhosin and ran the valgrind which is the output you see in the link. [2008-01-30 17:56:21] [EMAIL PROTECTED] Again, that valgrind output does not show an overflow. Either the problem is being masked by the suhosin patch, or it is a false positive. Trying removing the suhosin patch and do the valgrind check again. [2008-01-30 17:21:28] skennedy at vcn dot com Rasmus, I tested if this same heap overflow would occur on my Linux box (Debian 4.0) by compiling my own very basic PHP 5.2.5 (./configure --with-mssql) w/ Sushosin patch. The result: same exact error as on FreeBSD. The original valgrind output I submitted was from the PHP installed via a Debian package. So I recompiled my PHP again this time without Sushosin patch and ran valgrind again. Updated output: http://www.bandwidthbuilders.com/valgrind-output.txt Let me know if you need me to do anything else. Thanks. [2008-01-30 01:09:03] [EMAIL PROTECTED] I know that Valgrind output looks scary, but that is actually a clean run. The dlopen/dlclose stuff is normal. Are you seeing the same warning on this setup? [2008-01-30 00:09:25] skennedy at vcn dot com http://www.bandwidthbuilders.com/valgrind-output.txt 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/43861 -- Edit this bug report at http://bugs.php.net/?id=43861&edit=1
#43984 [Opn->Bgs]: Extra parentheses prevent implicit variable initialisation when passing by ref
ID: 43984 Updated by: [EMAIL PROTECTED] Reported By: robin_fernandes at uk dot ibm dot com -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows PHP Version: 5.2.5 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. You're passing an expression "($b)" as a variable. An expression is not a variable. For this to work, you need to pass a variable only "$b". Previous Comments: [2008-01-30 18:01:27] robin_fernandes at uk dot ibm dot com Note that if the variable is defined, it is correctly passed by reference whether or not the parens are present: Prints: Pass defined variable by ref with parentheses: string(7) "changed" [2008-01-30 18:00:49] robin_fernandes at uk dot ibm dot com Description: Passing an undefined variable by reference causes that variable to be implicitly defined. However, this is not the case if the argument is inside parentheses. This is reproducible on php5.2.5 as well as php5.3 and php6 snaps. Reproduce code: --- Expected result: Pass undefined variable by ref: string(7) "changed" Pass undefined variable by ref with parentheses: string(7) "changed" Actual result: -- Pass undefined variable by ref: string(7) "changed" Pass undefined variable by ref with parentheses: Notice: Undefined variable: b in %s on line 11 Strict Standards: Only variables should be passed by reference in %s on line 11 Notice: Undefined variable: b in %s on line 12 NULL -- Edit this bug report at http://bugs.php.net/?id=43984&edit=1
#43341 [Com]: no libphp5.so or php cli binary created
ID: 43341 Comment by: geoffrey dot hughes at otago dot ac dot nz Reported By: jay3ld at yahoo dot com Status: Open Bug Type: Compile Failure Operating System: Mac os X 10.5 Leopard PHP Version: 5.3CVS-2007-11-20 (snap) New Comment: I notice that after running make, I have a php binary in ./sapi/cli and I have a libphp5.so in ./libs/ but it doesn't seem to install them when I run "make install" Copying them manually to their correct locations works. Previous Comments: [2008-01-25 08:08:06] coder1 at gmail dot com I can reproduce the problem on CentOS 5.1. I took the configuration that came with a default install and re-compiled with 5.25. No php5lib.so is created or installed. [2007-12-07 20:40:14] b dot mcpherson at csuohio dot edu I'm having the same issue on AIX 5.3 64-bit PPC. Build complete. Don't forget to run 'make test'. # make test echo '\ \ Build complete. Don't forget to run 'make test'. ERROR: Cannot run tests without CLI sapi. # make install echo '\ \ Installing PHP SAPI module: nsapi cp: libs/libphp5.so: No such file or directory make: 1254-004 The error code from the last command is 1. Stop. The main directory has a libphp5.la file -rw-r--r-- 1 root system 2234 Dec 07 16:28 libphp5.la # cd libs # ls -l total 16704 -rw-r--r-- 1 root system 8547783 Dec 07 16:28 libphp5.a -rw-r--r-- 1 root system 2235 Dec 07 16:28 libphp5.la The libphp5.la file in the libs directory is not the same size. [2007-12-05 18:16:45] jesse dot charbneau at cengagelearning dot com Hello, I wanted to provide an update to my earlier post. I have performed the exact same steps on Suse 10 Enterprise. PHP built and installed without issue, and I was able to install a module via pecl. Does anyone know if this is correctable for Suse 9? [2007-12-05 16:31:21] jesse dot charbneau at cengagelearning dot com Hello, I have experienced this issue on multiple Suse Enterprise (v9.0 - v9.3) systems. This is to be used with Apache 2.2.6. Apache was configured, compiled and installed with: ./configure --enable-so --enable-rewrite --prefix=/opt/apache-2.2.6 --with-included-apr make make install (as root) I have tried multiple releases in the 5.2.x series (5.2.5, 5.2.4, 5.2.2) and have not been able to successfully get any of them to install the php-cli. I have been able to get it to install the module for apache, and so phpinfo() works and returns the correct page, but the requirements for this project need the cli (DAST). Here is the configure statement I am using with php: ./configure --with-libdir=lib64 --with-apxs2=/opt/apache-2.2.6/bin/apxs --prefix=/opt/apache-2.2.6 --with-mysql=/usr --with-mysqli=/usr/bin/mysql_config --with-gd --with-openssl=/usr --enable-soap --enable-sockets --with-xmlrpc --with-xsl --with-curl --with-zlib --with-pear make (works fine) make install (as root) returns: -- Installing PHP SAPI module: apache2handler /opt/apache-2.2.6/build/instdso.sh SH_LIBTOOL='/opt/apache-2.2.6/build/libtool' libphp5.la /opt/apache-2.2.6/modules /opt/apache-2.2.6/build/libtool --mode=install cp libphp5.la /opt/apache-2.2.6/modules/ libtool: install: error: cannot install `libphp5.la' to a directory not ending in /usr/src/packages/jess_temp/php-5.2.2/libs apxs:Error: Command failed with rc=65536 . make: *** [install-sapi] Error 1 -- Is this something with the release? Or should I be looking to update Suse or something? I am going to try compiling it on a Suse 10 box and see what turns up. Thanks, Jess [2007-11-30 02:24:43] jay3ld at yahoo dot com I can say for fact I am no longer using the built in apache 2.0 or php. I have custom built apache 2.2 and it even shows under my phpinfo.php page I am using apache 2.2.6 (It is how I pulled this information up originally). I renamed the apachectl file in /usr/sbin to apachectl.old and made symlink to the new one in my /home directory so startup commands still use apachectl correctly. My httpd.conf specifically points at php directories as I run php 5.2 and php 6.0 at the moment and wanted to add 5.3 as another option to ensure my sites will operate in the future correctly when and if I upgrade to 5.3 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/43341 -- Edit this bug report at http://bugs.php.net/?id=43341&edit=1
#43487 [Com]: Wrong conversion of float to string
ID: 43487 Comment by: oeriksson at mandriva dot com Reported By: jm at wo dot cz Status: Open Bug Type: Strings related Operating System: Linux PHP Version: 5.2.5 New Comment: I think I found the problem. On Mandriva Linux Cooker we are using: gcc (GCC) 4.2.2 20071128 (prerelease) (4.2.2-2mdv2008.1) glibc-2.7-1mdv2008.1 If I change the optimization from -O2 to -O0 (-O+zero) the bug goes away on x86_32. Previous Comments: [2008-01-28 21:30:37] jm at wo dot cz The CVS snapshot makes no difference, still getting the same incorrect strings. [EMAIL PROTECTED] ~]$ php -n -r '$f=array(1E-4, 1E-5, 1E-6, 1E-7, 1E-8); foreach ($f as $fval) echo $fval, "\n";' 0.0001 1.0E-5 :.0E-7 :.0E-8 1.0E-8 [EMAIL PROTECTED] ~]$ php -v PHP 5.2.6-dev (cli) (built: Jan 28 2008 16:13:46) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies Previous poster suggested a CPU-related issue. I have encountered this issue on the following CPUs: vendor_id : AuthenticAMD cpu family : 15 model : 5 model name : AMD Opteron(tm) Processor 248 stepping: 8 cpu MHz : 2205.074 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 1.80GHz stepping: 6 cpu MHz : 1800.000 vendor_id : AuthenticAMD cpu family : 15 model : 37 model name : AMD Opteron(tm) Processor 252 stepping: 1 cpu MHz : 2606.078 [2008-01-28 07:59:48] oeriksson at mandriva dot com I get the same problem, but it seems related to what CPU is used. http://qa.mandriva.com/show_bug.cgi?id=37171 $ uname -a Linux foo.nux.se 2.6.24-server-0.rc8.2mdv #1 SMP Wed Jan 23 17:15:33 UTC 2008 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz GNU/Linux $ php -r "var_dump(11.1/111);" float(0.0:) $ uname -a Linux oe.nux.tld 2.6.24-desktop-0.rc8.2mdv #1 SMP Wed Jan 23 18:12:45 CET 2008 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ GNU/Linux $ php -r "var_dump(11.1/111);" float(0.1) It works with 5.1.6 though. [2008-01-26 01:12:23] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2008-01-16 09:20:36] lmalgras at tennaxia dot com I have the same problem with PHP 5.2.4 on Linux Reproduce code: --- php -n -r '$f=array(1E-4, 1E-5, 1E-6, 1E-7, 1E-8); foreach($f as $fval) echo $fval, "\n";' Expected result: 0.0001 1.0E-5 1.0E-6 1.0E-7 1.0E-8 Actual result: -- 0.0001 1.0E-5 :.0E-7 :.0E-8 1.0E-8 I have test this code on several configurations with the following results : PHP 5.2.0 (Linux) : Actual result PHP 5.2.2 (Linux) : Actual result PHP 5.2.3 (Windows): Actual result [2007-12-06 23:59:16] jm at wo dot cz Obviously, I meant to say, the problem is with TWO numbers only: 1E-6 and 1E-7. J. 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/43487 -- Edit this bug report at http://bugs.php.net/?id=43487&edit=1
#43231 [Bgs->Opn]: array-based callback syntax is overly E_STRICT
ID: 43231 Updated by: [EMAIL PROTECTED] Reported By: chuck at horde dot org -Status: Bogus +Status: Open Bug Type: Scripting Engine problem Operating System: * PHP Version: 5.2.* Assigned To: helly New Comment: I'm sorry, I don't understand. Of course it is an E_STRICT error. But why is it an error if E_STRICT is turned off? Previous Comments: [2008-01-30 19:20:47] [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 This is indeed the correct behavior. You do not pass in a valid callback. If you call hello() directly you get an E_STRICT. Now call_user_func[_array]() tries to bind this function and cannot because it is not a valid one. It used to work in 5.2 for BC sakes, because I overlooked this in 5.0. When I first noticed this issue in 5.1, we couldn't change it in 5.1 and we also decided to not change this in 5.2. [2008-01-17 06:11:28] [EMAIL PROTECTED] Ping? [2007-11-25 20:08:47] [EMAIL PROTECTED] Just a reminder on this, since you said you already had the patch? [2007-11-14 08:03:15] [EMAIL PROTECTED] And this is HEAD issue too, that's where I simply MFH'd the stuff that broke this. :) [2007-11-10 10:32:31] [EMAIL PROTECTED] I already have a patch for that, will commit that once I'll boot the other system 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/43231 -- Edit this bug report at http://bugs.php.net/?id=43231&edit=1
#43231 [Asn->Bgs]: array-based callback syntax is overly E_STRICT
ID: 43231
Updated by: [EMAIL PROTECTED]
Reported By: chuck at horde dot org
-Status: Assigned
+Status: Bogus
Bug Type: Scripting Engine problem
-Operating System: MacOS 10.4
+Operating System: *
-PHP Version: 5.3CVS-2007-11-10 (CVS)
+PHP Version: 5.2.*
-Assigned To: colder
+Assigned To: helly
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
This is indeed the correct behavior. You do not pass in a valid
callback. If you call hello() directly you get an E_STRICT. Now
call_user_func[_array]() tries to bind this function and cannot because
it is not a valid one. It used to work in 5.2 for BC sakes, because I
overlooked this in 5.0. When I first noticed this issue in 5.1, we
couldn't change it in 5.1 and we also decided to not change this in 5.2.
Previous Comments:
[2008-01-17 06:11:28] [EMAIL PROTECTED]
Ping?
[2007-11-25 20:08:47] [EMAIL PROTECTED]
Just a reminder on this, since you said you already had the patch?
[2007-11-14 08:03:15] [EMAIL PROTECTED]
And this is HEAD issue too, that's where I simply MFH'd the stuff that
broke this. :)
[2007-11-10 10:32:31] [EMAIL PROTECTED]
I already have a patch for that, will commit that once I'll boot the
other system
[2007-11-10 03:20:27] chuck at horde dot org
Description:
The callback syntax of array('classname', 'methodname') for making
static method calls is now enforcing E_STRICT even if E_STRICT is not
on. So methods that are not explicitly declared static can't be used
this way even with E_STRICT off. Putting static in front of the function
makes it work, but of course results in a parse error when the code is
run under PHP 4.
Reproduce code:
---
http://bugs.php.net/?id=43231&edit=1
#43985 [Opn->Bgs]: soap error: Object of class stdClass could not be converted to string
ID: 43985
User updated by: c00lways at gmail dot com
Reported By: c00lways at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: SOAP related
Operating System: Red Hat 3.4.5-2 / CentOS
PHP Version: 5.2.5
New Comment:
sorry
i didn't realised the new php 5.2 doesn't accept object conversion to
string if it doesn't have tostring...
my problem..
:(
Previous Comments:
[2008-01-30 18:36:50] c00lways at gmail dot com
Description:
when i use soap to open a complex wsdl...
and then pass in a stdclass object to be send as parameter...
came out crash:
Catchable fatal error: Object of class stdClass could not be converted
to string in ...
this crash is not captured by try / catch
Reproduce code:
---
$client = new
SoapClient("http://demo.touricoholidays.com/ws/AmendmentServices.asmx?WSDL";,
Array(
"trace" => 1,
"exceptions" => 1,
"encoding" => "ISO-8859-1"
)
);
$tcost = new stdClass();
//adding this below gives similar problem...
//$tcost->CostAmendObj = new stdClass();
//$tcost->CostAmendObj->IsOnlyAvailable = "true";
try {
//this statement causes the error...
echo "Result: " . $client->costamend( $tcost );
} catch ( Exception $e )
{
var_dump( $e->getMessage() );
}
Expected result:
soap response xml
Actual result:
--
Catchable fatal error: Object of class stdClass could not be converted
to string in ...
--
Edit this bug report at http://bugs.php.net/?id=43985&edit=1
#43861 [Opn]: suhosin patch detects heap overflow on mssql_free_result()
ID: 43861 User updated by: skennedy at vcn dot com Reported By: skennedy at vcn dot com Status: Open Bug Type: MSSQL related Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: That valgrind output *is* without the Suhosin patch. I was saying that I first compiled PHP w/ Suhosin patch to make sure it errors-out with the heap overflow as it does on my FreeBSD box and it did. Then I compiled PHP again this time w/out Suhosin and ran the valgrind which is the output you see in the link. Previous Comments: [2008-01-30 17:56:21] [EMAIL PROTECTED] Again, that valgrind output does not show an overflow. Either the problem is being masked by the suhosin patch, or it is a false positive. Trying removing the suhosin patch and do the valgrind check again. [2008-01-30 17:21:28] skennedy at vcn dot com Rasmus, I tested if this same heap overflow would occur on my Linux box (Debian 4.0) by compiling my own very basic PHP 5.2.5 (./configure --with-mssql) w/ Sushosin patch. The result: same exact error as on FreeBSD. The original valgrind output I submitted was from the PHP installed via a Debian package. So I recompiled my PHP again this time without Sushosin patch and ran valgrind again. Updated output: http://www.bandwidthbuilders.com/valgrind-output.txt Let me know if you need me to do anything else. Thanks. [2008-01-30 01:09:03] [EMAIL PROTECTED] I know that Valgrind output looks scary, but that is actually a clean run. The dlopen/dlclose stuff is normal. Are you seeing the same warning on this setup? [2008-01-30 00:09:25] skennedy at vcn dot com http://www.bandwidthbuilders.com/valgrind-output.txt [2008-01-28 23:35:12] [EMAIL PROTECTED] Would be nice if you try it on some Linux machine. 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/43861 -- Edit this bug report at http://bugs.php.net/?id=43861&edit=1
#43985 [NEW]: soap error: Object of class stdClass could not be converted to string
From: c00lways at gmail dot com
Operating system: Red Hat 3.4.5-2 / CentOS
PHP version: 5.2.5
PHP Bug Type: SOAP related
Bug description: soap error: Object of class stdClass could not be converted
to string
Description:
when i use soap to open a complex wsdl...
and then pass in a stdclass object to be send as parameter...
came out crash:
Catchable fatal error: Object of class stdClass could not be converted to
string in ...
this crash is not captured by try / catch
Reproduce code:
---
$client = new
SoapClient("http://demo.touricoholidays.com/ws/AmendmentServices.asmx?WSDL";,
Array(
"trace" => 1,
"exceptions" => 1,
"encoding" => "ISO-8859-1"
)
);
$tcost = new stdClass();
//adding this below gives similar problem...
//$tcost->CostAmendObj = new stdClass();
//$tcost->CostAmendObj->IsOnlyAvailable = "true";
try {
//this statement causes the error...
echo "Result: " . $client->costamend( $tcost );
} catch ( Exception $e )
{
var_dump( $e->getMessage() );
}
Expected result:
soap response xml
Actual result:
--
Catchable fatal error: Object of class stdClass could not be converted to
string in ...
--
Edit bug report at http://bugs.php.net/?id=43985&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43985&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43985&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43985&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43985&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43985&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43985&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43985&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43985&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43985&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43985&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43985&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43985&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43985&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43985&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43985&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43985&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43985&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43985&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43985&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43985&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43985&r=mysqlcfg
#43449 [Opn->Bgs]: Segmentation Fault when calling PL/SQL-function wich returns ref cursor
ID: 43449 Updated by: [EMAIL PROTECTED] Reported By: michael dot virnstein at brodos dot de -Status: Open +Status: Bogus Bug Type: OCI8 related Operating System: Linux PHP Version: 5.2.5 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. + | This turns out to be a duplicate of | http://bugs.php.net/bug.php?id=42841 See that bug for the workaround | and code fix. Previous Comments: [2008-01-19 12:20:53] jdolecek at NetBSD dot org I experience the same problem (PHP crash after executing PL/SQL function returning ref cursor via oci8 extension) with PHP 5.2.5 (cli) on Windows. [2008-01-09 19:25:18] [EMAIL PROTECTED] I can reproduce it with PHP 5.2.5 but there is no crash using OCI8 1.3.0 Beta (from PECL). [2007-12-05 16:25:51] michael dot virnstein at brodos dot de This was the backtrace of another php-script, that's causing the same error. Here's the backtrace of the script containing the reporduce code: #0 0xb6aec13d in kghmkfree () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #1 0xb6af31df in kghaddex () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #2 0xb6af5096 in kghgex () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #3 0xb6af7a5a in kghfnd () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #4 0xb6af7f99 in kghprmalo () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #5 0xb6afa12c in kghalp () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #6 0xb6b03c48 in kghmrk () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #7 0xb66dba9f in kpuhhmrk () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #8 0xb66e209c in kpurclr () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #9 0xb6a76de7 in kpcxc2r () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #10 0xb6acc4d4 in ttcrs2c () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #11 0xb6adae97 in ttcacr () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #12 0xb6a695e2 in ttcdrv () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #13 0xb694fec5 in nioqwa () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #14 0xb67bdd97 in upirtrc () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #15 0xb6733a36 in kpurcsc () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #16 0xb66ea057 in kpuexecv8 () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #17 0xb66eb40a in kpuexec () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #18 0xb67c2902 in OCIStmtExecute () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #19 0xb76adac8 in php_oci_statement_execute (statement=0xb5fa4880, mode=0) at /usr/local/src/php-5.2.5/ext/oci8/oci8_statement.c:442 #20 0xb76b7be9 in zif_oci_execute (ht=2, return_value=0xb5fa9470, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /usr/local/src/php-5.2.5/ext/oci8/oci8_interface.c:1302 #21 0xb792d4cc in zend_do_fcall_common_helper_SPEC (execute_data=0xbf7fd6b4) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:200 #22 0xb7932d96 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xbf7fd6b4) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:1681 #23 0xb792d02d in execute (op_array=0x8308038) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #24 0xb792d646 in zend_do_fcall_common_helper_SPEC (execute_data=0xbf7fd894) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:234 #25 0xb792e119 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf7fd894) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:322 #26 0xb792d02d in execute (op_array=0xb5fa458c) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #27 0xb790829f in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/src/php-5.2.5/Zend/zend.c:1134 #28 0xb78b6947 in php_execute_script (primary_file=0xbf7ffbd4) at /usr/local/src/php-5.2.5/main/main.c:2004 #29 0xb7981b0b in php_handler (r=0x82fde30) at /usr/local/src/php-5.2.5/sapi/apache2handler/sapi_apache2.c:631 #30 0x0807adf9 in ap_run_handler () #31 0x0807df57 in ap_invoke_handler () #32 0x080c6088 in ap_process_request () #33 0x080c338b in ap_process_http_connection () #34 0x08081d09 in ap_run_process_connection () #35 0x080df640 in child_main () #36 0x080df8a8 in make_child () #37 0x080e0645 in ap_mpm_run () #38 0x08068bce in main () [2007-12-05 14:16:03] michael dot virnstein at brodos dot de here's the backtrace: #0 0xb674607d in kpurclr (
#42841 [Opn]: oci_new_cursor PHP crash
ID: 42841
Updated by: [EMAIL PROTECTED]
Reported By: pr0head at gmail dot com
Status: Open
Bug Type: OCI8 related
Operating System: Linux version 2.6.20-gentoo-r8
PHP Version: 5.2.4
New Comment:
This was a latent bug exposed when statement caching was fixed.
The temporary workaround is to set oci8.statement_cache_size=0
The real solution (thanks to Sree) is to add a missing case for
cursors to the out-bind callback:
diff -u oci8_statement.c.orig oci8_statement.c
--- oci8_statement.c.orig 2008-01-30 10:37:32.0 -0800
+++ oci8_statement.c2008-01-30 10:21:31.0 -0800
@@ -1174,6 +1174,14 @@
}
if (Z_TYPE_P(val) == IS_RESOURCE) {
+ /* Processing for ref-cursor out binds */
+ if (phpbind->statement != NULL) {
+ *bufpp = phpbind->statement;
+ *alenpp = &phpbind->dummy_len;
+ *piecep = OCI_ONE_PIECE;
+ *rcodepp = &phpbind->retcode;
+ *indpp = &phpbind->indicator;
+ }
retval = OCI_CONTINUE;
} else if (Z_TYPE_P(val) == IS_OBJECT) {
if (!phpbind->descriptor) {
Previous Comments:
[2008-01-09 19:40:42] [EMAIL PROTECTED]
The original testcase (with the parameter only as OUT) does not crash
with OCI8 1.3.0 Beta from PECL.
[2007-12-14 18:53:08] michael dot virnstein at brodos dot de
This fix only works for out parameters, not for return values from
functions. I can't change thosea.
I also filed the bug (Bug #43449), haven't found the other two.
[2007-12-11 20:39:37] [EMAIL PROTECTED]
I reproduced the crash. The problem appears to be the same as reported
in http://bugs.php.net/bug.php?id=43340. If you change the PL/SQL
package definition so out_1 is an "IN OUT" parameter, there is no crash.
[2007-11-20 09:46:48] pr0head at gmail dot com
This script working normally if not reopen cursor.
Bad result:
$sql = "BEGIN sp_vadik_1( :cursor ); END;";
$stmt = oci_parse( $connection, $sql );
$cursor = oci_new_cursor( $connection );
oci_bind_by_name( $stmt, ":cursor", $cursor, -1, OCI_B_CURSOR );
oci_execute( $stmt, OCI_DEFAULT );
oci_execute( $cursor );
oci_free_statement( $stmt );
oci_free_statement( $cursor );
$sql = "BEGIN sp_vadik_1( :cursor ); END;";
$stmt = oci_parse( $connection, $sql );
$cursor = oci_new_cursor( $connection );
oci_bind_by_name( $stmt, ":cursor", $cursor, -1, OCI_B_CURSOR );
oci_execute( $stmt, OCI_DEFAULT );
oci_execute( $cursor );
oci_free_statement( $stmt );
oci_free_statement( $cursor );
Good result:
$sql = "BEGIN sp_vadik_1( :cursor ); END;";
$stmt = oci_parse( $connection, $sql );
$cursor = oci_new_cursor( $connection );
oci_bind_by_name( $stmt, ":cursor", $cursor, -1, OCI_B_CURSOR );
oci_execute( $stmt, OCI_DEFAULT );
oci_execute( $cursor );
oci_free_statement( $stmt );
$sql = "BEGIN sp_vadik_1( :cursor ); END;";
$stmt = oci_parse( $connection, $sql );
oci_bind_by_name( $stmt, ":cursor", $cursor, -1, OCI_B_CURSOR );
oci_execute( $stmt, OCI_DEFAULT );
oci_execute( $cursor );
oci_free_statement( $stmt );
oci_free_statement( $cursor );
[2007-11-20 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".
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/42841
--
Edit this bug report at http://bugs.php.net/?id=42841&edit=1
#43981 [Opn->Csd]: gmp_div_r does not preserve the sign of 1st argument
ID: 43981 Updated by: [EMAIL PROTECTED] Reported By: ikr at xiag dot ch -Status: Open +Status: Closed Bug Type: Math related Operating System: Linux 2.6.22.13-0.3-default SMP PHP Version: 5.2.5 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2008-01-30 07:07:22] ikr at xiag dot ch Description: PHP manual at http://ch2.php.net/manual/en/function.gmp-div-r.php claims for gmp_div_r: - resource gmp_div_r ( resource $n , resource $d [, int $round ] ) Calculates remainder of the integer division of n by d . The remainder has the sign of the n argument, if not zero. - However, print(gmp_strval(gmp_div_r(-5, 100)) . "\n"); Will result in "5", not "-5". Reproduce code: --- Expected result: -5 Actual result: -- 5 -- Edit this bug report at http://bugs.php.net/?id=43981&edit=1
#42805 [Com]: gzuncompress data error
ID: 42805
Comment by: legolas558 at users dot sourceforge dot net
Reported By: dwlnetnl at users dot sourceforge dot net
Status: No Feedback
Bug Type: Zlib Related
Operating System: Mac OS X 10.4.10 Intel
PHP Version: 5.2.4
New Comment:
Same problem here, with PHP5.
Zlib compiled version: 1.2.1.1
Zilb linked version: 1.2.3
On my local host I have both versions 1.2.3 and it works fine
Previous Comments:
[2007-10-09 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-10-01 10:47:06] [EMAIL PROTECTED]
Your example script works just fine for me.
Exactly what PHP version are you using? And with what zlib version do
you link PHP with?
[2007-10-01 00:54:25] dwlnetnl at users dot sourceforge dot net
Description:
When I uncompress some gzcompress()'d data I get an data error. It's
Qcodo form data.
Reproduce code:
---
$gz_base64 =
'eNrtW1tvG7kVzk8RBuhLgbXusj3uFpBlp3Fry3KkJEBfDGqGlhhTpJakfNnA/e09vAw5M5a0MrraBNt5CRyeQ/Lj4bl8pDjX8XEcnSE5n3Ik0ihuNeNvMm724ujdX99RqQYUSTlECyyjk+v4KI5uLolUp/wpinsto9oxqlKJgZRGOzqR8WEcUdCbgh78DwaN3mUdT5HE7whTH/kjqJK4qRVa2SCXaIrpey4+4l9WROBUd9dT/EXWiKyJXGvreFOfT4wBYKMEgAsjdU0fPv16ofBirJ4p1svSExh4oVWrfvMdYJJTlNwPOOUiOhnqkQ69gIsUiy0iN42MwahDrsZYRWu0vpBUzd0Aa0yaa59S9p4zMCWFNU3jxonfLye5UIiSxMv8ErTMbaUZ7ijf6foBC0oY9t06+W5j8it2vY7zvcZKkHvMV8p3K4g/sbQ0ag6MwHmjeQ/4gMlsrlxrM2v15nnxc0DrGFOcKMLZFU8zE48Jm1l7BxP/Ez2gcSLIUhnv1Oa6TQBA3TnpwVffHtxD9oVAz9EJipvt+BsB/Nc6WLyjRLF1kUY2i7Zt5q8/1Sy22jXDtZ+iwlo+I7rC5S216tpNhwU76Zn+IfhqWRAUPRisouNoR3hglX6aCmwj9RUsawanoQcbIYZp9PuCbe0KFqAM4E+BNmHtZgr7gtreFapGAm6YbELacfJ9Ae3sChSmfE9ciKzB2bbifcHs7goT0tMlT5AO701QD4PKvuD2do56yGDXYoYYkdsw61qYV9sX7sM3RNgIC7nZyN1MYV9Qj96QuUaCf4XZtmQup7EvsMe7gj3W1AOKTAr1aBPco5zOvgA3G2/ICxO03JYXtHhvOJtviTSDZHt20JGWV9sb8NYbDPxJYrHFwFq8H5wv34vMtrMFnBG5pJpQTQ3nd/QT+jjBhqG/N+k129ZsLM1JZl/s1xoJTkXXS5QQ9Vze5H6SABv7F3YCd15akKcBWkkswYdI6mLB!
TeX59GAFuVu8tqvfl3OGphSnfl+8wcPJqWAdQDlB0wtY3JM+vzXCYDDbhHM6Ic4XW3kndwDPhSitGmb6TCSZUuwh7HYYMJSr2ci2puc7qQU9xXdg4rIZtaR/p7AoOIMOIgb/rMxRQhbA6dmQYCaHF89m2nfuKH/c5LGgMuKSZAmqoHIczJWFrU8Wl/hOlQ8HV/wBI2egoiMNwM8Epxf2SBxHSScKo0ESAEdbFA5u0DZCAjPlerqdamfCwZzQ1Mn8AagRf3t5ndCGJW/R7p7zo25RYkxYcE4QXbMRmuHXrgfnOXJHwmDOk0DyRaDlEou8QqOwlXa2K6zmPHWGt03GQr0QFlLxRV9BCE9XCrulDguXEVbH5KWc3CU7sFXfOEw4JuqsDzg4S+aI6WWZNnty1N570/+KnmynKG7nLlpgLgs4qxQtMHXh9uV24Ib0toD5vyCiLhLO/FYaipTiO7SieYoEqucPsOXmrgNWd2MHs20WSAjVcFZ2fUprKnlf6jw8F6GQIM6wyfR66S8vuvaE8e36wQdhWSESfQEx1h7PMVYuEFuNXNIMG5ZJfRGw48or2LMJFgvCkPLx4sYArQt5Snlyf07xwixOy1888iWD5KXspRAMfGPLcHxo63lIcmiWbRS0peTBbIu3ypndgHJZA/lUzx39BqBmoUzplHXOFFhZL9k5uzfJBD+pcmKa4AXMq1yAtnxM9VeK20gwMQ45wI/nVzZCaRpynbftmeDLCRIz7Ctd2M8PXJBfwQER7VMye53rwm3NZywUSTbpOaDgqzrbSefTspSDgpbGtFGrW9Ay9AiWVVYLKfFCasV/c4bf6+qUKbR9Hv2kk85HLIESbJgz6F7yx9/QbR2GbKXVPiCWUnwGxTYJ0eQWoa9Kc0pXhJHFarFVBT0FlR/mBtO6WZpdNd8qXfr+BPxwWNHCH4sWDisymJHBZkUGvxcZdIl+V9pT+IVi74wo7B8wHutj/zeEp1kR!
norw/EGEp5MnPNTEWcV4KsZTMZ69MZ5WxXgqxrOB8fg7no82lirKU1GeivL8zpSnm6c8wg
ZaxXkqzlNxnr1xnnbFeSrOs57ztD2yixmD6AgA9BO/cnUrKQdIa5RDmGp41hkLT8lDfELO0DpjhdTKPPluZQu40e3mQbh2w5IHGkLmbjEFjNULFF8AR2gF7xcA/Sj8/i3iTNaN3NOc7JfSKO41i29zLLvSCQa24m9kMatJkfwc1f+TPlKGFaN1uSQp4bfygdUhYbD7+uPjYx3KHexUnSzAl6VWYQyL22bnYEbuotqjzlE/R81OVJubJGb/RhT+GFEMC65pRAcHB1H979EWdraOjkLEyCViG8vqfqjbj/USvmINFWuoWMP/xBq6fzrW0KhYwx/xWiY72xaKd3b8Xr/G3K6f8vQZilk2V7tbVhjMcXKvfbjoW6VygCidPC+zejjkrPQ0yt3P+LoPpKDTaIcriLKBylSoHQI+oasUpxuYUy/7Bs5+T/RLwlNuviYKvu2+NOKzGRZ5ke+E9TurvKSdSZZcFgT+u6XE2matLP9Nk5atXc5WbheuuUYCPxC+kjqvY6nsZ1Z6K8yIwQNcynSj6yFHyD7R7EE2qetnzbLuGdWYKEuaXvOqpb6Nu00FutPsSheMA7WkB8v5MtrGB46zMjMEOpdLdfr7jZf/AluLSsY='
$gz = base64_decode($gz_base64);
echo gzuncompress($gz);
Expected result:
O:9:"Dashboard":21:{s:16:"
Actual result:
--
PHP Warning: gzuncompress(): data error
--
Edit this bug report at http://bugs.php.net/?id=42805&edit=1
#43231 [Opn->Asn]: array-based callback syntax is overly E_STRICT
ID: 43231
Updated by: [EMAIL PROTECTED]
Reported By: chuck at horde dot org
-Status: Open
+Status: Assigned
Bug Type: Scripting Engine problem
Operating System: MacOS 10.4
PHP Version: 5.3CVS-2007-11-10 (CVS)
-Assigned To:
+Assigned To: colder
Previous Comments:
[2008-01-17 06:11:28] [EMAIL PROTECTED]
Ping?
[2007-11-25 20:08:47] [EMAIL PROTECTED]
Just a reminder on this, since you said you already had the patch?
[2007-11-14 08:03:15] [EMAIL PROTECTED]
And this is HEAD issue too, that's where I simply MFH'd the stuff that
broke this. :)
[2007-11-10 10:32:31] [EMAIL PROTECTED]
I already have a patch for that, will commit that once I'll boot the
other system
[2007-11-10 03:20:27] chuck at horde dot org
Description:
The callback syntax of array('classname', 'methodname') for making
static method calls is now enforcing E_STRICT even if E_STRICT is not
on. So methods that are not explicitly declared static can't be used
this way even with E_STRICT off. Putting static in front of the function
makes it work, but of course results in a parse error when the code is
run under PHP 4.
Reproduce code:
---
http://bugs.php.net/?id=43231&edit=1
#43984 [Opn]: Extra parentheses prevent implicit variable initialisation when passing by ref
ID: 43984 User updated by: robin_fernandes at uk dot ibm dot com Reported By: robin_fernandes at uk dot ibm dot com Status: Open Bug Type: Scripting Engine problem Operating System: Windows PHP Version: 5.2.5 New Comment: Note that if the variable is defined, it is correctly passed by reference whether or not the parens are present: Prints: Pass defined variable by ref with parentheses: string(7) "changed" Previous Comments: [2008-01-30 18:00:49] robin_fernandes at uk dot ibm dot com Description: Passing an undefined variable by reference causes that variable to be implicitly defined. However, this is not the case if the argument is inside parentheses. This is reproducible on php5.2.5 as well as php5.3 and php6 snaps. Reproduce code: --- Expected result: Pass undefined variable by ref: string(7) "changed" Pass undefined variable by ref with parentheses: string(7) "changed" Actual result: -- Pass undefined variable by ref: string(7) "changed" Pass undefined variable by ref with parentheses: Notice: Undefined variable: b in %s on line 11 Strict Standards: Only variables should be passed by reference in %s on line 11 Notice: Undefined variable: b in %s on line 12 NULL -- Edit this bug report at http://bugs.php.net/?id=43984&edit=1
#43984 [NEW]: Extra parentheses prevent implicit variable initialisation when passing by ref
From: robin_fernandes at uk dot ibm dot com Operating system: Windows PHP version: 5.2.5 PHP Bug Type: Scripting Engine problem Bug description: Extra parentheses prevent implicit variable initialisation when passing by ref Description: Passing an undefined variable by reference causes that variable to be implicitly defined. However, this is not the case if the argument is inside parentheses. This is reproducible on php5.2.5 as well as php5.3 and php6 snaps. Reproduce code: --- Expected result: Pass undefined variable by ref: string(7) "changed" Pass undefined variable by ref with parentheses: string(7) "changed" Actual result: -- Pass undefined variable by ref: string(7) "changed" Pass undefined variable by ref with parentheses: Notice: Undefined variable: b in %s on line 11 Strict Standards: Only variables should be passed by reference in %s on line 11 Notice: Undefined variable: b in %s on line 12 NULL -- Edit bug report at http://bugs.php.net/?id=43984&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43984&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43984&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43984&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43984&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43984&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43984&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43984&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43984&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43984&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43984&r=support Expected behavior:http://bugs.php.net/fix.php?id=43984&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43984&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43984&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43984&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43984&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43984&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43984&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43984&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43984&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43984&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43984&r=mysqlcfg
#43861 [Opn]: suhosin patch detects heap overflow on mssql_free_result()
ID: 43861 Updated by: [EMAIL PROTECTED] Reported By: skennedy at vcn dot com Status: Open Bug Type: MSSQL related Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: Again, that valgrind output does not show an overflow. Either the problem is being masked by the suhosin patch, or it is a false positive. Trying removing the suhosin patch and do the valgrind check again. Previous Comments: [2008-01-30 17:21:28] skennedy at vcn dot com Rasmus, I tested if this same heap overflow would occur on my Linux box (Debian 4.0) by compiling my own very basic PHP 5.2.5 (./configure --with-mssql) w/ Sushosin patch. The result: same exact error as on FreeBSD. The original valgrind output I submitted was from the PHP installed via a Debian package. So I recompiled my PHP again this time without Sushosin patch and ran valgrind again. Updated output: http://www.bandwidthbuilders.com/valgrind-output.txt Let me know if you need me to do anything else. Thanks. [2008-01-30 01:09:03] [EMAIL PROTECTED] I know that Valgrind output looks scary, but that is actually a clean run. The dlopen/dlclose stuff is normal. Are you seeing the same warning on this setup? [2008-01-30 00:09:25] skennedy at vcn dot com http://www.bandwidthbuilders.com/valgrind-output.txt [2008-01-28 23:35:12] [EMAIL PROTECTED] Would be nice if you try it on some Linux machine. [2008-01-28 21:51:54] skennedy at vcn dot com Apparently amd64/FreeBSD cannot run valgrind. I get this when trying to install it: ===> valgrind-352_7 is only for i386, while you are running amd64.*** Error code 1 Is there anything else that's amd64/FreeBSD friendly I can use? 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/43861 -- Edit this bug report at http://bugs.php.net/?id=43861&edit=1
#43861 [Opn]: suhosin patch detects heap overflow on mssql_free_result()
ID: 43861 User updated by: skennedy at vcn dot com Reported By: skennedy at vcn dot com Status: Open Bug Type: MSSQL related Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: Rasmus, I tested if this same heap overflow would occur on my Linux box (Debian 4.0) by compiling my own very basic PHP 5.2.5 (./configure --with-mssql) w/ Sushosin patch. The result: same exact error as on FreeBSD. The original valgrind output I submitted was from the PHP installed via a Debian package. So I recompiled my PHP again this time without Sushosin patch and ran valgrind again. Updated output: http://www.bandwidthbuilders.com/valgrind-output.txt Let me know if you need me to do anything else. Thanks. Previous Comments: [2008-01-30 01:09:03] [EMAIL PROTECTED] I know that Valgrind output looks scary, but that is actually a clean run. The dlopen/dlclose stuff is normal. Are you seeing the same warning on this setup? [2008-01-30 00:09:25] skennedy at vcn dot com http://www.bandwidthbuilders.com/valgrind-output.txt [2008-01-28 23:35:12] [EMAIL PROTECTED] Would be nice if you try it on some Linux machine. [2008-01-28 21:51:54] skennedy at vcn dot com Apparently amd64/FreeBSD cannot run valgrind. I get this when trying to install it: ===> valgrind-352_7 is only for i386, while you are running amd64.*** Error code 1 Is there anything else that's amd64/FreeBSD friendly I can use? [2008-01-27 16:46:42] [EMAIL PROTECTED] Can you please to run the script through valgrind without suhosin extension enabled. 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/43861 -- Edit this bug report at http://bugs.php.net/?id=43861&edit=1
#43971 [Fbk->Opn]: imageFTText error with angle = 180
ID: 43971 User updated by: raven7370 at yahoo dot com Reported By: raven7370 at yahoo dot com -Status: Feedback +Status: Open Bug Type: GD related Operating System: Linux Debian PHP Version: 5.2.5 New Comment: Thanks for trying it. My PHP uses FreeType Version 2.1.7 I think you might be right in that it is a package problem and not a php one.The php i use is not standalone but from lampp (linux version of xampp from apache friends). I will try to get the latest snapshot of 5.2 running separately to see if it works then. Otherwise i will try to get someone from apache friends to test it and see if they can reproduce the problem. Previous Comments: [2008-01-29 17:34:23] [EMAIL PROTECTED] I can't reproduce it using php 5.2.5 or CVS. If you use the PHP's package from Debian, I fear that I can't help, they do changes that have nothing to do with any libgd versions (that may change once the politics there is over). Can you try it using snapshots. Which freetype version do you use? [2008-01-29 17:22:29] raven7370 at yahoo dot com in the reproduce code the angle argument should be 180 such as: imagefttext($image, 21, 180, 256, 256, $color, 'ARIALNB.TTF', 'Hello World'); i copied it quickly while i was still testing. [2008-01-29 17:20:42] raven7370 at yahoo dot com Description: When i use imagefttext such with an angle of 180 i get the error: imagefttext() [function.imagefttext]: Problem rendering glyph With an angle of close to 180 (between 179 and 184.6) but not equal to 180 i do not get an error but the text simply won't be drawn. With an angle between 177 to 179 the text will be drawn but stretched vertically. This problem occurs with almost all windows fonts with a few exceptiosn, those being the Chinese ones (SIMSUN.TTF and PMINGLIU.TTF) With: GD Support enabled GD Version bundled (2.0.34 compatible) FreeType Support enabled FreeType Linkage with freetype FreeType Version 2.1.7 Reproduce code: --- $image = imagecreate(512,512); imagecolorallocate($image,0,0,0); $color = imagecolorallocate($image,255,0,0); imagefttext($image, 21, 176.9, 256, 256, $color, 'ARIALNB.TTF', 'Hello World'); imagegif($image); The font mentioned here is from the windows/fonts directory (just copied directly in the same path as the script) Expected result: I expect to see a pictures with hello world written on it upside down. Actual result: -- With an angle of 180 the error "imagefttext() [function.imagefttext]: Problem rendering glyph in ..." is thrown, close to 180 the text is either not drawn or is stretched. -- Edit this bug report at http://bugs.php.net/?id=43971&edit=1
#43941 [Csd]: json_encode silently cuts non-UTF8 strings
ID: 43941
Updated by: [EMAIL PROTECTED]
Reported By: stas at zend dot com
Status: Closed
Bug Type: JSON related
Operating System: *
PHP Version: 5.3CVS-2008-01-25 (CVS)
New Comment:
I sent this on to json.org as well, and it is now fixed there.
Previous Comments:
[2008-01-30 03:22:14] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2008-01-25 22:19:43] stas at zend dot com
Description:
Right now, if json_encode sees wrong UTF-8 data, it just cuts the
string in the middle, no error returned, no message produced.
I think it's not a good idea to just silently cut the data. In fact, I
think it is a bug caused by this code in ext/json/utf8_to_utf16.c:
if (c < 0) {
return UTF8_END ? the_index : UTF8_ERROR;
}
which inherited this bug from code published on json.org. It should
be:
if (c < 0) {
return (c == UTF8_END) ? the_index : UTF8_ERROR;
}
Reproduce code:
---
var_dump(json_encode("ab\xE0"));
var_dump(json_encode("ab\xE0\""));
Expected result:
Some error message
Actual result:
--
Just:
""ab""
""ab""
--
Edit this bug report at http://bugs.php.net/?id=43941&edit=1
#43841 [Opn->Asn]: mb_strrpos offset is byte count for negative values
ID: 43841 Updated by: [EMAIL PROTECTED] Reported By: josmessa at uk dot ibm dot com -Status: Open +Status: Assigned Bug Type: mbstring related Operating System: Windows XP PHP Version: 5.2CVS-2008-01-14 (snap) -Assigned To: +Assigned To: hirokawa New Comment: assigning to maintainer Previous Comments: [2008-01-14 16:38:46] josmessa at uk dot ibm dot com Description: The offset argument appears to do a byte count for negative values of offset. In the example below, $string_ascii is 21 characters long and $string_mb is 21 characters (53 bytes) long. In both cases the needle appears twice, first at position 9 and secondly at position 20. When the offset is -24, beyond the character length of the string, it finds $needle at position 9, when $needle would be expected to be found when offest is -12 (i.e. behave the same as the ASCII example). It's also worth noting that strrpos returns a notice when the offset is outside the boundary of the string whereas mb_strrpos does not. This may be linked to this bug: http://bugs.php.net/43840. Reproduce code: --- Expected result: -- Offset is -25 -- Multibyte String: Notice: mb_strrpos(): Offset is greater than the length of haystack string in ...\mb_strrpos.php on line 9 bool(false) ASCII String: mb_strrpos: Notice: mb_strrpos(): Offset is greater than the length of haystack string in ...\mb_strrpos.php on line 14 bool(false) strrpos: Notice: strrpos(): Offset is greater than the length of haystack string in ...\mb_strrpos.php on line 14 bool(false) -- Offset is -24 -- Multibyte String: Notice: mb_strrpos(): Offset is greater than the length of haystack string in ...\mb_strrpos.php on line 9 bool(false) ASCII String: mb_strrpos: Notice: mb_strrpos(): Offset is greater than the length of haystack string in ...\mb_strrpos.php on line 14 bool(false) strrpos: Notice: strrpos(): Offset is greater than the length of haystack string in ...\mb_strrpos.php on line 14 bool(false) -- Offset is -13 -- Multibyte String: bool(false) ASCII String: mb_strrpos: bool(false) strrpos:bool(false) -- Offset is -12 -- Multibyte String: int(9) ASCII String: mb_strrpos: int(9) strrpos:int(9) Actual result: -- -- Offset is -25 -- Multibyte String: bool(false) ASCII String: mb_strrpos: bool(false) strrpos: Notice: strrpos(): Offset is greater than the length of haystack string in ...\mb_strrpos.php on line 14 bool(false) -- Offset is -24 -- Multibyte String: int(9) ASCII String: mb_strrpos: bool(false) strrpos: Notice: strrpos(): Offset is greater than the length of haystack string in ...\mb_strrpos.php on line 14 bool(false) -- Offset is -13 -- Multibyte String: int(9) ASCII String: mb_strrpos: bool(false) strrpos:bool(false) -- Offset is -12 -- Multibyte String: int(9) ASCII String: mb_strrpos: int(9) strrpos:int(9) -- Edit this bug report at http://bugs.php.net/?id=43841&edit=1
#43840 [Opn->Asn]: mb_strpos bounds check is byte count rather than a character count
ID: 43840 Updated by: [EMAIL PROTECTED] Reported By: josmessa at uk dot ibm dot com -Status: Open +Status: Assigned Bug Type: mbstring related Operating System: Windows XP PHP Version: 5.2CVS-2008-01-14 (snap) Assigned To: hirokawa Previous Comments: [2008-01-30 15:57:54] [EMAIL PROTECTED] assigning to maintainer [2008-01-14 16:36:52] josmessa at uk dot ibm dot com Description: The bounds check for the offest argument in mb_strpos appears to be a byte count rather than a character count. In the example below, $string_ascii is 21 characters long and $string_mb is 21 characters (53 bytes) long. In both cases the needle appears twice, first at position 9 and secondly at position 20. With the multibyte string example, when the offset is past the character count of the string it would be expected to return a warning but instead a warning is returned when offest is past the byte count. Reproduce code: --- Expected result: -- Offset is 20 -- --Multibyte String:-- int(20) --ASCII String:-- int(20) -- Offset is 21 -- --Multibyte String:-- bool(false) --ASCII String:-- bool(false) -- Offset is 22 -- --Multibyte String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 9 bool(false) --ASCII String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 11 bool(false) -- Offset is 53 -- --Multibyte String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 9 bool(false) --ASCII String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 11 bool(false) -- Offset is 54 -- --Multibyte String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 9 bool(false) --ASCII String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 11 bool(false) Actual result: -- -- Offset is 20 -- --Multibyte String:-- int(20) --ASCII String:-- int(20) -- Offset is 21 -- --Multibyte String:-- bool(false) --ASCII String:-- bool(false) -- Offset is 22 -- --Multibyte String:-- bool(false) --ASCII String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 11 bool(false) -- Offset is 53 -- --Multibyte String:-- bool(false) --ASCII String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 11 bool(false) -- Offset is 54 -- --Multibyte String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 9 bool(false) --ASCII String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 11 bool(false) -- Edit this bug report at http://bugs.php.net/?id=43840&edit=1
#43840 [Opn]: mb_strpos bounds check is byte count rather than a character count
ID: 43840 Updated by: [EMAIL PROTECTED] Reported By: josmessa at uk dot ibm dot com Status: Open Bug Type: mbstring related Operating System: Windows XP PHP Version: 5.2CVS-2008-01-14 (snap) -Assigned To: +Assigned To: hirokawa New Comment: assigning to maintainer Previous Comments: [2008-01-14 16:36:52] josmessa at uk dot ibm dot com Description: The bounds check for the offest argument in mb_strpos appears to be a byte count rather than a character count. In the example below, $string_ascii is 21 characters long and $string_mb is 21 characters (53 bytes) long. In both cases the needle appears twice, first at position 9 and secondly at position 20. With the multibyte string example, when the offset is past the character count of the string it would be expected to return a warning but instead a warning is returned when offest is past the byte count. Reproduce code: --- Expected result: -- Offset is 20 -- --Multibyte String:-- int(20) --ASCII String:-- int(20) -- Offset is 21 -- --Multibyte String:-- bool(false) --ASCII String:-- bool(false) -- Offset is 22 -- --Multibyte String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 9 bool(false) --ASCII String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 11 bool(false) -- Offset is 53 -- --Multibyte String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 9 bool(false) --ASCII String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 11 bool(false) -- Offset is 54 -- --Multibyte String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 9 bool(false) --ASCII String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 11 bool(false) Actual result: -- -- Offset is 20 -- --Multibyte String:-- int(20) --ASCII String:-- int(20) -- Offset is 21 -- --Multibyte String:-- bool(false) --ASCII String:-- bool(false) -- Offset is 22 -- --Multibyte String:-- bool(false) --ASCII String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 11 bool(false) -- Offset is 53 -- --Multibyte String:-- bool(false) --ASCII String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 11 bool(false) -- Offset is 54 -- --Multibyte String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 9 bool(false) --ASCII String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 11 bool(false) -- Edit this bug report at http://bugs.php.net/?id=43840&edit=1
#43983 [Opn]: to Chang atribute, change arrays assigned before
ID: 43983 User updated by: rubens21 at gmail dot com Reported By: rubens21 at gmail dot com Status: Open Bug Type:Scripting Engine problem PHP Version: 5.2.5 New Comment: This example is more simple: $test = new stdClass(); $Objeto = new stdClass(); $test->valor = "The first value"; $Objeto->valorDeTeste[] = $test; $test->valor = "The second value"; print_r($Objeto->valorDeTeste); Expected: Array ( [0] => stdClass Object ( [valor] => The first value ) ) Actual Array ( [0] => stdClass Object ( [valor] => The second value ) ) Previous Comments: [2008-01-30 15:37:54] rubens21 at gmail dot com Description: change atribute of a class, and arrays that received values is change too. I know that the bug #33207 (http://bugs.php.net/bug.php?id=33207&edit=2) describes this same problem, but there is not the solution and the id of the other related. Reproduce code: --- $test = new stdClass(); $Objeto = new stdClass(); $test->valor = "No Change!"; $Objeto->valorDeTeste[] = $test; $test->valor = "Yes, change!"; $Objeto->valorDeTeste[] = $test; print_r($Objeto->valorDeTeste); Expected result: Array ( [0] => stdClass Object ( [valor] => No Change! ) [1] => stdClass Object ( [valor] => Yes, change! ) ) Actual result: -- Array ( [0] => stdClass Object ( [valor] => Yes, change! ) [1] => stdClass Object ( [valor] => Yes, change! ) ) -- Edit this bug report at http://bugs.php.net/?id=43983&edit=1
#43983 [NEW]: to Chang atribute, change arrays assigned before
From: rubens21 at gmail dot com Operating system: PHP version: 5.2.5 PHP Bug Type: Scripting Engine problem Bug description: to Chang atribute, change arrays assigned before Description: change atribute of a class, and arrays that received values is change too. I know that the bug #33207 (http://bugs.php.net/bug.php?id=33207&edit=2) describes this same problem, but there is not the solution and the id of the other related. Reproduce code: --- $test = new stdClass(); $Objeto = new stdClass(); $test->valor = "No Change!"; $Objeto->valorDeTeste[] = $test; $test->valor = "Yes, change!"; $Objeto->valorDeTeste[] = $test; print_r($Objeto->valorDeTeste); Expected result: Array ( [0] => stdClass Object ( [valor] => No Change! ) [1] => stdClass Object ( [valor] => Yes, change! ) ) Actual result: -- Array ( [0] => stdClass Object ( [valor] => Yes, change! ) [1] => stdClass Object ( [valor] => Yes, change! ) ) -- Edit bug report at http://bugs.php.net/?id=43983&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43983&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43983&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43983&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43983&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43983&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43983&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43983&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43983&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43983&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43983&r=support Expected behavior:http://bugs.php.net/fix.php?id=43983&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43983&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43983&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43983&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43983&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43983&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43983&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43983&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43983&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43983&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43983&r=mysqlcfg
#41562 [Asn->Csd]: SimpleXML memory issue
ID: 41562 Updated by: [EMAIL PROTECTED] -Summary: Segmentation fault Reported By: christian dot kaps at imaxx21 dot com -Status: Assigned +Status: Closed Bug Type: SimpleXML related Operating System: Ubuntu 7.04 (Feisty) PHP Version: 5.2.3 Assigned To: helly New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2007-09-07 13:48:05] [EMAIL PROTECTED] Yes, I still can reproduce it: ==23397== Invalid read of size 8 ==23397==at 0x43F714: php_libxml_node_decrement_resource (libxml.c:1036) ==23397==by 0x4FC4DD: sxe_object_free_storage (simplexml.c:1934) ==23397==by 0x642746: zend_objects_store_del_ref_by_handle (zend_objects_API.c:206) ==23397==by 0x64259E: zend_objects_store_del_ref (zend_objects_API.c:168) etc.. [2007-09-07 13:03:58] [EMAIL PROTECTED] Antony, can you check this? (I can't reproduce it..) [2007-09-07 11:57:13] christian dot kaps at imaxx21 dot com I can`t test it. Currently we use the dom extension to fix this issue in our sytem and i could only reproduce it there. With the single code snippet I couldn`t reproduce the error. Perhaps tony2001 can test it? He could reproduce it with the snippet. [2007-09-07 09:46:52] [EMAIL PROTECTED] Does this still happen with PHP 5.2.4? [2007-06-08 01:15:59] [EMAIL PROTECTED] FWIW, works for me on Linux Fedora 6, 5.2 CVS. Libxml is 2.6.28 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/41562 -- Edit this bug report at http://bugs.php.net/?id=41562&edit=1
#43973 [Opn->Csd]: __autoload called with wrong classname when triggered by static callback
ID: 43973 Updated by: [EMAIL PROTECTED] Reported By: robin_fernandes at uk dot ibm dot com -Status: Open +Status: Closed Bug Type:Class/Object related PHP Version: 6CVS-2008-01-29 (snap) New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2008-01-30 12:26:36] [EMAIL PROTECTED] Simple fix: http://ecl.zoone.com.br/etc/patches/bug43973.diff [2008-01-29 18:28:39] robin_fernandes at uk dot ibm dot com Description: NB: This issue is specific to PHP6 snaps. PHP5.2 and PHP5.3 snaps produce the expected output. When using a callback of the form 'C::f' where class C is not yet defined, __autoload() is invoked with the fully qualified method name as an argument, rather than just the class name. Reproduce code: --- Expected result: Autoload class: C In C::f() Actual result: -- Autoload class: C::f Warning: call_user_func() expects parameter 1 to be valid callback, string given in %s on line 9 -- Edit this bug report at http://bugs.php.net/?id=43973&edit=1
#43973 [Opn]: __autoload called with wrong classname when triggered by static callback
ID: 43973 Updated by: [EMAIL PROTECTED] Reported By: robin_fernandes at uk dot ibm dot com Status: Open Bug Type:Class/Object related PHP Version: 6CVS-2008-01-29 (snap) New Comment: Simple fix: http://ecl.zoone.com.br/etc/patches/bug43973.diff Previous Comments: [2008-01-29 18:28:39] robin_fernandes at uk dot ibm dot com Description: NB: This issue is specific to PHP6 snaps. PHP5.2 and PHP5.3 snaps produce the expected output. When using a callback of the form 'C::f' where class C is not yet defined, __autoload() is invoked with the fully qualified method name as an argument, rather than just the class name. Reproduce code: --- Expected result: Autoload class: C In C::f() Actual result: -- Autoload class: C::f Warning: call_user_func() expects parameter 1 to be valid callback, string given in %s on line 9 -- Edit this bug report at http://bugs.php.net/?id=43973&edit=1
#43978 [Opn->Bgs]: Compile PHP to native code
ID: 43978 Updated by: [EMAIL PROTECTED] Reported By: zy at adels dot zp dot ua -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Windows/Linux PHP Version: 5.2.5 New Comment: PHP won't directly work without at least the help from a runtime library where most of the time is spent. Feel free to implement it, I think no dev currently sees benefit in this and therefore won't implement it. Previous Comments: [2008-01-30 00:08:41] zy at adels dot zp dot ua Description: Why not to compile PHP to a native code. This will dramatically increase its execution speed. PHP developers really need this because it is expensive to use PHP when developing complicated web application. For example, now I have a project where system needs to make a lot of calculations to make a series of decisions using data from the database containing several millions of records. One of its components has a following statistics: [Debug] Time: 9.511 [Debug] Queries: 6135 [Debug] Query time: 3.11026215553 This means that it took 3 seconds to make more than 6 thousands of not simple queries and 6.5 seconds to process them using PHP. Native code (or even .NET code which compiles to native code) performs such kind of tasks faster in order of magnitude. We really need a native code compiler (at least for x86 Linux and Windows). If it was possible to create a compiler for Visual Basic 5 and 6 then it is possible to create one for PHP. Expected result: faster execution -- Edit this bug report at http://bugs.php.net/?id=43978&edit=1
#43926 [Opn->Csd]: isInstance() isn't equivalent to instanceof operator
ID: 43926
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Class/Object related
Operating System: Linux
PHP Version: 5.3CVS-2008-01-24 (CVS)
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2008-01-24 13:23:37] [EMAIL PROTECTED]
.phpt:
http://ecl.zoone.com.br/etc/patches/bug43926.phpt
Patch:
http://ecl.zoone.com.br/etc/patches/bug43926.patch
[2008-01-24 13:16:07] [EMAIL PROTECTED]
Description:
Says the documentation:
"Note: $class = new ReflectionClass('Foo'); $class->isInstance($arg) is
equivalent to $arg instanceof Foo or is_a($arg, 'Foo')."
However, this isn't true because not is checked the parent class.
Reproduce code:
---
newInstance();
$cc = $rc->newInstance();
$cd = $rd->newInstance();
$ce = $re->newInstance();
print("Is? A ". ($ra->isInstance($ca) ? 'true' : 'false') .",
instanceof: ". (($ca instanceof A) ? 'true' : 'false') ."\n");
print("Is? C ". ($ra->isInstance($cc) ? 'true' : 'false') .",
instanceof: ". (($ca instanceof C) ? 'true' : 'false') ."\n");
print("Is? D ". ($ra->isInstance($cd) ? 'true' : 'false') .",
instanceof: ". (($ca instanceof D) ? 'true' : 'false') ."\n");
print("Is? E ". ($ra->isInstance($ce) ? 'true' : 'false') .",
instanceof: ". (($ca instanceof E) ? 'true' : 'false') ."\n");
?>
Expected result:
Is? A true, instanceof: true
Is? C false, instanceof: false
Is? D true, instanceof: true
Is? E true, instanceof: true
Actual result:
--
Is? A true, instanceof: true
Is? C false, instanceof: false
Is? D false, instanceof: true
Is? E false, instanceof: true
--
Edit this bug report at http://bugs.php.net/?id=43926&edit=1
#43982 [NEW]: Running specific error code without any error messages
From: php at ert dot org dot ua Operating system: WinXP PHP version: 5.2.5 PHP Bug Type: *Compile Issues Bug description: Running specific error code without any error messages Description: When I try to index some scalar value (integer, for example), I want to get error message, but I have normal NULL result. Reproduce code: --- Expected result: Error, warning or notice Actual result: -- no -- Edit bug report at http://bugs.php.net/?id=43982&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43982&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43982&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43982&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43982&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43982&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43982&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43982&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43982&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43982&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43982&r=support Expected behavior:http://bugs.php.net/fix.php?id=43982&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43982&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43982&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43982&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43982&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43982&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43982&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43982&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43982&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43982&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43982&r=mysqlcfg
#43294 [Opn->Bgs]: htmlentities with UTF8 fails if dagger character supplied
ID: 43294
Updated by: [EMAIL PROTECTED]
Reported By: tallyce at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Strings related
Operating System: Windows or Linux
PHP Version: 5.2.5
New Comment:
Marking this as bogus for now. If you can show that a properly UTF-8
encoded dagger, or some other properly encoded UTF-8 character isn't
working, re-open it with that information. Make sure you show the
actual raw byte sequence that is being passed into the function.
Previous Comments:
[2008-01-29 14:57:26] [EMAIL PROTECTED]
Just check to see if the dagger is properly represented as a UTF-8
character. It should be e2 80 a0
That same symbol can be represented in other encodings, obviously, but
if you are telling htmlentities that you are using UTF-8 and you then
pass it a dagger not encoded in UTF-8, it has no idea what to do with
it.
To test it correctly, do this:
echo htmlentities(chr(0xe2).chr(0x80).chr(0xa0),null,'utf-8');
Spits out † then everything is fine, and the cases where it
isn't working for you is because you aren't actually passing it the
correct utf-8 sequence for that character. I don't do Windows, but the
above test works fine on Linux, FreeBSD and OSX for me.
[2008-01-22 14:55:12] tallyce at gmail dot com
I've been spending further time trying to work out what's happening,
and am convinced something is definitely not right.
I've also found another character where the presence of the character
results in the whole string disappearing, and there may be others.
Using this reproduce code:
' .
preg_replace('/[^\x00-\x7F]/e', '"&#".ord("$0").";"', 'Test ') . '' . htmlentities ('Test', ENT_COMPAT, 'UTF-8') . ''; ?>
I get different results for machines running SUSE Linux/PHP5.2.4, Linux
Ubuntu/PHP 5.2.3 and WinXP/PHP 5.2.5. Only the second gives the result I
would expect.
1. From a linux machine terminal:
Firstly doing
less t.php
gives
' . preg_replace('/[^\x00-\x7F]/e', '"&#".ord("$0").";"', 'Test 233
206') . '<
br />' . htmlentities ('Test', ENT_COMPAT, 'UTF-8') . ''; ?>
with the 233 and 206 background-highlighted.
php -v
PHP 5.2.4 (cli) (built: Sep 12 2007 15:23:24)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
Test Test › †Test
2. From the same machine but viewing with a web browser
(FF2.0.0.11/WinXP), i.e. example.com/t.php (which is serving up UTF-8
pages as confirmed by web-sniffer.net):
Test ? ?Test › †Test
[two symbols appear as ? in diamond]
3. On another machine, with the putty terminal set to UTF-8:
less t.php
gives:
' .
preg_replace('/[^\x00-\x7F]/e', '"&#".ord("$0").";"', 'Test ') . '' . htmlentities ('Test', ENT_COMPAT, 'UTF-8') . ''; ?>
exactly as first entered.
php -v
PHP 5.2.3-1ubuntu6.2 (cli) (built: Dec 3 2007 19:59:42)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
php t.php
Test › †Test ›
†Test
4. Same machine as (3) but via web browser:
Test › †Test ›
†Test
5. On a Windows machine
C:\Documents and Settings\username>php -v
PHP 5.2.5 (cli) (built: Nov 8 2007 23:18:51)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
H:\>php t.php
PHP Warning: htmlentities(): Invalid multibyte sequence in argument in
H:\t.php on line 1
Test › †Test
6. Same machine as (5) but via web browser
Test › †Test
[2007-12-18 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".
[2007-12-10 10:02:15] [EMAIL PROTECTED]
Correct output:
$ php t.php
Test †Test
[2007-12-10 10:01:49] [EMAIL PROTECTED]
Seems to work fine for me:
[EMAIL PROTECTED] ~]$ php t.php
Test †Test[
Please try on command line.
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/43294
--
Edit this bug report at http://bugs.php.net/?id=43294&edit=1
