#38745 [Opn->Bgs]: Extended Class & extract problems
ID: 38745 Updated by: [EMAIL PROTECTED] Reported By: arqentus at arqentus dot com -Status: Open +Status: Bogus Bug Type: Class/Object related Operating System: Windows 2003 PHP Version: 5.1.6 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Previous Comments: [2006-09-07 22:53:27] arqentus at arqentus dot com Odd, using your example its returning 'xxx'; Grumbles, and i already changed my code. I'll look into it tomorrow ( almost 01:00 here ). Its very odd to say the least. [2006-09-07 22:27:57] [EMAIL PROTECTED] >Yet, its perfectly able to override the class's variables > IF its not extended. What are you talking about? 'Name' ) ); var_dump($user_name->desc); ?> What do you get? "Name"? Or "xxx"? [2006-09-07 22:20:19] arqentus at arqentus dot com "extract() creates variables in the current scope, it doesn't create objects' attributes and was never meant to do it." Yet, its perfectly able to override the class's variables IF its not extended. In other words, while as you say, its not designed to work for classes, it does actually work ( if used only in a baseclass ). So, you are right, its not a complete bug, its a incomplete "feature" thats lacking the ability to see past its current scope with a extended class. Note: See several examples on the general mailing list where people use the same methode. The extract function will need a update to it scope range. Using a foreach loop is a rather inefficient way of handeling it compared to a extract. [2006-09-07 22:09:28] [EMAIL PROTECTED] Actually it has nothing to do with EXTR_. extract() creates variables in the current scope, it doesn't create objects' attributes and was never meant to do it. [2006-09-07 22:05:26] arqentus at arqentus dot com Note: The extract code was texted with EXTR_OVERWRITE & EXTR_IF_EXISTS. The "EXTR_REFS" was a final foolish attempt to see how it was going to react( expecting a error feedback, but nothing came ). Forgot to remove it from the submitted code. I'm including this comment, to be sure this bug does not get closed becouse you think i used the wrong EXTR ;) 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/38745 -- Edit this bug report at http://bugs.php.net/?id=38745&edit=1
#38748 [Opn->Bgs]: crash / malloc / dealloc error
ID: 38748 Updated by: [EMAIL PROTECTED] Reported By: lampacz at gmail dot com -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Debian unstable/testin i86/amd64 PHP Version: 5.1.6 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Endless recursion. Previous Comments: [2006-09-08 06:11:57] lampacz at gmail dot com Description: this script ends with sigseg tested on amd64 and Reproduce code: --- http://lampa.naut.cz/lib_db.phps Expected result: i don't know but anything instead crash (error message) Actual result: -- #0 0xb7b61c1f in free () from /lib/tls/libc.so.6 #1 0xb7b63c4f in malloc () from /lib/tls/libc.so.6 #2 0x0820cb31 in _emalloc (size=3082990784) at /root/src/php-5.1.5/Zend/zend_alloc.c:182 #3 0x082274f4 in zend_is_callable_check_func (check_flags=4, zobj_ptr_ptr=0xbf185148, ce_org=0x0, callable=0x90ad5ec, ce_ptr=0xbf185154, fptr_ptr=0xbf18514c) at /root/src/php-5.1.5/Zend/zend_operators.h:200 #4 0x082277fa in zend_is_callable_ex (callable=0x90ad5ec, check_flags=, callable_name=0xbf185230, callable_name_len=0xbf185158, ce_ptr=0xbf185154, fptr_ptr=0xbf18514c, zobj_ptr_ptr=0xbf185148) at /root/src/php-5.1.5/Zend/zend_API.c:2150 #5 0x08227b97 in zend_is_callable (callable=0x90ad5ec, check_flags=0, callable_name=0xbf185230) at /root/src/php-5.1.5/Zend/zend_API.c:2248 #6 0x08176c55 in zif_array_map (ht=2, return_value=0x90ad77c, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /root/src/php-5.1.5/ext/standard/array.c:4237 #7 0x0823d48d in zend_do_fcall_common_helper_SPEC (execute_data=0xbf1858a0) at /root/src/php-5.1.5/Zend/zend_vm_execute.h:200 #8 0x0823e848 in execute (op_array=0x856d154) at /root/src/php-5.1.5/Zend/zend_vm_execute.h:92 #9 0x0823ce23 in zend_do_fcall_common_helper_SPEC (execute_data=0xbf185e00) at /root/src/php-5.1.5/Zend/zend_vm_execute.h:234 #10 0x0823e848 in execute (op_array=0x856871c) at /root/src/php-5.1.5/Zend/zend_vm_execute.h:92 last two lines repeats many times -- Edit this bug report at http://bugs.php.net/?id=38748&edit=1
#38748 [NEW]: crash / malloc / dealloc error
From: lampacz at gmail dot com Operating system: Debian unstable/testin i86/amd64 PHP version: 5.1.6 PHP Bug Type: Reproducible crash Bug description: crash / malloc / dealloc error Description: this script ends with sigseg tested on amd64 and Reproduce code: --- http://lampa.naut.cz/lib_db.phps Expected result: i don't know but anything instead crash (error message) Actual result: -- #0 0xb7b61c1f in free () from /lib/tls/libc.so.6 #1 0xb7b63c4f in malloc () from /lib/tls/libc.so.6 #2 0x0820cb31 in _emalloc (size=3082990784) at /root/src/php-5.1.5/Zend/zend_alloc.c:182 #3 0x082274f4 in zend_is_callable_check_func (check_flags=4, zobj_ptr_ptr=0xbf185148, ce_org=0x0, callable=0x90ad5ec, ce_ptr=0xbf185154, fptr_ptr=0xbf18514c) at /root/src/php-5.1.5/Zend/zend_operators.h:200 #4 0x082277fa in zend_is_callable_ex (callable=0x90ad5ec, check_flags=, callable_name=0xbf185230, callable_name_len=0xbf185158, ce_ptr=0xbf185154, fptr_ptr=0xbf18514c, zobj_ptr_ptr=0xbf185148) at /root/src/php-5.1.5/Zend/zend_API.c:2150 #5 0x08227b97 in zend_is_callable (callable=0x90ad5ec, check_flags=0, callable_name=0xbf185230) at /root/src/php-5.1.5/Zend/zend_API.c:2248 #6 0x08176c55 in zif_array_map (ht=2, return_value=0x90ad77c, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /root/src/php-5.1.5/ext/standard/array.c:4237 #7 0x0823d48d in zend_do_fcall_common_helper_SPEC (execute_data=0xbf1858a0) at /root/src/php-5.1.5/Zend/zend_vm_execute.h:200 #8 0x0823e848 in execute (op_array=0x856d154) at /root/src/php-5.1.5/Zend/zend_vm_execute.h:92 #9 0x0823ce23 in zend_do_fcall_common_helper_SPEC (execute_data=0xbf185e00) at /root/src/php-5.1.5/Zend/zend_vm_execute.h:234 #10 0x0823e848 in execute (op_array=0x856871c) at /root/src/php-5.1.5/Zend/zend_vm_execute.h:92 last two lines repeats many times -- Edit bug report at http://bugs.php.net/?id=38748&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38748&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38748&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38748&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38748&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38748&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38748&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38748&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38748&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38748&r=support Expected behavior:http://bugs.php.net/fix.php?id=38748&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38748&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38748&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38748&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38748&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38748&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38748&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38748&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38748&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38748&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38748&r=mysqlcfg
#38747 [NEW]: Segfault under load
From: michaelw at webcentral dot com dot au Operating system: Solaris 10 PHP version: 4.4.4 PHP Bug Type: iPlanet related Bug description: Segfault under load Description: Crash occurs randomly when accessing PHP scripts using Sun Java Enterprise Webserver 6.1 SP5. In this case, I was using jmeter to generate some load and accessing a page containing PHP was configured with: ./configure --prefix=/opt/php --with-nsapi=/opt/SUNWwbsvr --enable-libgcc --enable-debug Reproduce code: --- Expected result: Standard phpinfo() response. Actual result: -- After a couple of hundred successful attempts, the webserver coredumps. GNU gdb 6.2.1 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.10"...(no debugging symbols found)... Core was generated by `webservd -r /opt/SUNWwbsvr -d /opt/SUNWwbsvr/https-hosting/config -n https-host'. Program terminated with signal 11, Segmentation fault. #0 0xfd818508 in zend_hash_move_forward_ex (ht=0xfd893538, pos=0x0) at /opt/admin/build/php-4.4.4/Zend/zend_hash.c:1039 1039*current = (*current)->pListNext; (gdb) bt #0 0xfd818508 in zend_hash_move_forward_ex (ht=0xfd893538, pos=0x0) at /opt/admin/build/php-4.4.4/Zend/zend_hash.c:1039 #1 0xfd6f487c in php_print_info (flag=-1, tsrm_ls=0x1084dd68) at /opt/admin/build/php-4.4.4/ext/standard/info.c:504 #2 0xfd6f6a5c in zif_phpinfo (ht=0, return_value=0x108e3e70, this_ptr=0x0, return_value_used=0, tsrm_ls=0x1084dd68) at /opt/admin/build/php-4.4.4/ext/standard/info.c:885 #3 0xfd82e380 in execute (op_array=0xee37f68, tsrm_ls=0x1084dd68) at /opt/admin/build/php-4.4.4/Zend/zend_execute.c:1675 #4 0xfd80d4ec in zend_execute_scripts (type=8, tsrm_ls=0x1084dd68, retval=0x0, file_count=3) at /opt/admin/build/php-4.4.4/Zend/zend.c:934 #5 0xfd79c870 in php_execute_script (primary_file=0xfab7faa8, tsrm_ls=0x1084dd68) at /opt/admin/build/php-4.4.4/main/main.c:1752 #6 0xfd839ae4 in php4_execute (pb=0x59e9910, sn=0xe6e4270, rq=0xe6e42e8) at /opt/admin/build/php-4.4.4/sapi/nsapi/nsapi.c:948 #7 0xff1cf9ec in __1cNfunc_exec_str6FpnKFuncStruct_pnGpblock_pnHSession_pnHRequest__i_ () from /opt/SUNWwbsvr/bin/https/lib/libns-httpd40.so #8 0xff1d0e0c in INTobject_execute () from /opt/SUNWwbsvr/bin/https/lib/libns-httpd40.so #9 0xff1d5e3c in INTservact_service () from /opt/SUNWwbsvr/bin/https/lib/libns-httpd40.so #10 0xff1d654c in INTservact_handle_processed () from /opt/SUNWwbsvr/bin/https/lib/libns-httpd40.so #11 0xff218bf0 in __1cLHttpRequestUUnacceleratedRespond6Mpc_v_ () from /opt/SUNWwbsvr/bin/https/lib/libns-httpd40.so #12 0xff2182e0 in __1cLHttpRequestNHandleRequest6MpnGnetbuf__i_ () from /opt/SUNWwbsvr/bin/https/lib/libns-httpd40.so #13 0xff2166d8 in __1cNDaemonSessionDrun6M_v_ () from /opt/SUNWwbsvr/bin/https/lib/libns-httpd40.so #14 0xff106df4 in ThreadMain () from /opt/SUNWwbsvr/bin/https/lib/libnsprwrap.so #15 0xfedd0030 in _pt_root () from /usr/lib/mps/secv1/libnspr4.so #16 0xfe03fda4 in _lwp_start () from /lib/libc.so.1 #17 0xfe03fda4 in _lwp_start () from /lib/libc.so.1 -- Edit bug report at http://bugs.php.net/?id=38747&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38747&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38747&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38747&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38747&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38747&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38747&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38747&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38747&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38747&r=support Expected behavior:http://bugs.php.net/fix.php?id=38747&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38747&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38747&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38747&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38747&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38747&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38747&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38747&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38747&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38747&r=nozend M
#15215 [Com]: Wrong path for php.ini under Windows XP (Home and Professional)
ID: 15215 Comment by: joebeazelman at hotmail dot com Reported By: php at totti dot de Status: No Feedback Bug Type: *Configuration Issues Operating System: Windows NT 5.1 (XP) PHP Version: 4.1.1 New Comment: Ditto. I am running XP with IIS 5. I removed all traces of php.ini from my system and only left a copy in the root folder of my php 4 installation and phpinfo still said it found the php.ini file in my windows directory. Previous Comments: [2006-05-03 15:24:11] t dot johnson at intercall dot ie I have incountered the same issue with php 5.1.2 and iis 6 on all 3 of our servers. The phpinfo() reports c:\windows as the location of php.ini on all installations which were manually configured. the error occurs on clean systems with nothin but OS, IIS and pho installed. Does anyone have any further info on this problem? [2002-02-28 00:00:04] php-bugs at lists dot php dot net No feedback was provided for this bug for over a month, 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". [2002-01-27 15:11:58] [EMAIL PROTECTED] Do you mean the PHP installer? Anyway, Christoph is right, it doesn't look at the version string but it just tries your Windows-directory. phpinfo() reports where it has found php.ini. Look at that path. It should really work if you place it in c:\windows. [2002-01-27 15:05:09] phpbugs at gordimer dot net This has never happened to me. My php.ini gets parsed whether it resides in windows directory (for sapi-version) or in php-directory for cgi. I'm using XP Pro, but it also works with NT 4 and non-standard windir-name (winntw). Christoph [2002-01-24 19:14:40] php at totti dot de If you install the Windows binaries on Systems running Windows XP, PHP assumes that there is a system directory 'C:\winnt\' because of the version string reported by Windows (Windows NT 5.x). As there is no such Dir (under Win XP the System Dir is named 'C:\Windows\' by default), php.ini is not found. I couldn't find help in creating this dir and put the .ini file in. Also the 'php.ini' is not found if simply put in the path. -- Edit this bug report at http://bugs.php.net/?id=15215&edit=1
#38745 [Fbk->Opn]: Extended Class & extract problems
ID: 38745
User updated by: arqentus at arqentus dot com
Reported By: arqentus at arqentus dot com
-Status: Feedback
+Status: Open
Bug Type: Class/Object related
Operating System: Windows 2003
PHP Version: 5.1.6
New Comment:
Odd, using your example its returning 'xxx'; Grumbles, and i already
changed my code. I'll look into it tomorrow ( almost 01:00 here ). Its
very odd to say the least.
Previous Comments:
[2006-09-07 22:27:57] [EMAIL PROTECTED]
>Yet, its perfectly able to override the class's variables
> IF its not extended.
What are you talking about?
'Name' ) );
var_dump($user_name->desc);
?>
What do you get? "Name"? Or "xxx"?
[2006-09-07 22:20:19] arqentus at arqentus dot com
"extract() creates variables in the current scope, it doesn't create
objects' attributes and was never meant to do it."
Yet, its perfectly able to override the class's variables IF its not
extended. In other words, while as you say, its not designed to work
for classes, it does actually work ( if used only in a baseclass ).
So, you are right, its not a complete bug, its a incomplete "feature"
thats lacking the ability to see past its current scope with a extended
class.
Note: See several examples on the general mailing list where people use
the same methode.
The extract function will need a update to it scope range. Using a
foreach loop is a rather inefficient way of handeling it compared to a
extract.
[2006-09-07 22:09:28] [EMAIL PROTECTED]
Actually it has nothing to do with EXTR_.
extract() creates variables in the current scope, it doesn't create
objects' attributes and was never meant to do it.
[2006-09-07 22:05:26] arqentus at arqentus dot com
Note: The extract code was texted with EXTR_OVERWRITE & EXTR_IF_EXISTS.
The "EXTR_REFS" was a final foolish attempt to see how it was going to
react( expecting a error feedback, but nothing came ). Forgot to remove
it from the submitted code.
I'm including this comment, to be sure this bug does not get closed
becouse you think i used the wrong EXTR ;)
[2006-09-07 22:01:51] arqentus at arqentus dot com
Description:
extract does not override the values when using a extended class.
Note: Using a manual fill, will work:
class cText extends cField{
function __construct( $fields = array() ) {
foreach($fields as $key => $val ) {
$this->{$key} = $val;
}
//extract($fields, EXTR_REFS);
}
}
Looks like the extract can't handle the extend class.
Note: Using a normal NONE extended class, and extract will work.
Somehow it seems to lack the scope. Yet, a 'manual' foreach loop is
able to access the scope.
Differend combination have been tried ( moving the construct to the
parent, passing the fields to the parent and extracting there, etc ).
None are able to work.
Reproduce code:
---
class cField{
var $desc = 'xxx';
}
class cText extends cField{
function __construct( $fields = array() ) {
extract($fields, EXTR_REFS);
}
}
$user_name = new cText( array ( _desc => 'Name' ) );
echo $user_name->desc;
Expected result:
The expect result is: 'Name';
Actual result:
--
The result archieved is: 'xxx';
--
Edit this bug report at http://bugs.php.net/?id=38745&edit=1
#38746 [NEW]: number_format() returns 'inf' for too large numbers
From: carlsagan43 at antidom dot com Operating system: Windows XP PHP version: 5.1.6 PHP Bug Type: Math related Bug description: number_format() returns 'inf' for too large numbers Description: This isnt directly something wrong, but it does need to be addressed: When working with large numbers in BCmath, the need to output the number comes about. When trying to use the function number_format(), it returns 'inf'. This function should be changed to also accept strings that are composed or digits. Reproduce code: --- Expected result: 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (with commas) Actual result: -- inf -- Edit bug report at http://bugs.php.net/?id=38746&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38746&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38746&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38746&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38746&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38746&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38746&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38746&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38746&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38746&r=support Expected behavior:http://bugs.php.net/fix.php?id=38746&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38746&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38746&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38746&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38746&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38746&r=dst IIS Stability:
#29234 [Com]: empty($object->property) incorrect when property has access overloaded (__get)
ID: 29234
Comment by: lf at burntmail dot com
Reported By: chrissy at codegoat dot com
Status: No Feedback
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.0.0
New Comment:
The problem still exists with 5.1.5.
Previous Comments:
[2006-07-16 20:48:46] info at peter-thomassen dot de
The problem still exists with 5.1.4.
[2005-03-14 01:00:14] 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".
[2005-03-06 20:49:52] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2004-07-20 19:34:48] benjcarson at digitaljunkies dot ca
This may be related to bug #28176.
[2004-07-18 01:14:15] chrissy at codegoat dot com
Description:
The code below has a class with two properties. One which is a regular
public class property and the other which is accessed through the __get
function. Both are set to "Not Empty". However, when you call empty()
on the one accessed through __get, the empty() function returns TRUE
which is incorrect. The problem can be remedied by first assigning the
value of the property to a variable and then calling the empty function
on that variable.
Reproduce code:
---
"Not Empty");
function __get($key) {
if (array_key_exists($key, $this->properties)) return
$this->properties[$key];
}
}
$emptyTest = new EmptyTest();
echo "The value of Test 1 is: \"" . $emptyTest->emptyTest1 .
"\"The value of Test 2 is: \"" . $emptyTest->emptyTest2 .
"\"---";
if (empty($emptyTest->emptyTest1)) echo "Test 1 was empty ";
else echo "Test 1 was not empty ";
if (empty($emptyTest->emptyTest2))echo "Test 2 was empty ";
else echo "Test 2 was not empty ";
$test = $emptyTest->emptyTest2;
if (empty($test))echo "Test 2 was empty this time";
else echo "Test 2 was not empty this time";
?>
Expected result:
Both emptyTest1 and emptyTest2, when passed to the empty function, the
function should return true.
It could be that calling empty with a property that has had its access
overloaded by the __get function is invalid. If this is the case, I
would assume empty should at least throw a Warning.
Actual result:
--
The output of the above program is...
The value of Test 1 is: "Not Empty"
The value of Test 2 is: "Not Empty"
---
Test 1 was not empty
Test 2 was empty
Test 2 was not empty this time
--
Edit this bug report at http://bugs.php.net/?id=29234&edit=1
#38745 [Opn->Fbk]: Extended Class & extract problems
ID: 38745
Updated by: [EMAIL PROTECTED]
Reported By: arqentus at arqentus dot com
-Status: Open
+Status: Feedback
Bug Type: Class/Object related
Operating System: Windows 2003
PHP Version: 5.1.6
New Comment:
>Yet, its perfectly able to override the class's variables
> IF its not extended.
What are you talking about?
'Name' ) );
var_dump($user_name->desc);
?>
What do you get? "Name"? Or "xxx"?
Previous Comments:
[2006-09-07 22:20:19] arqentus at arqentus dot com
"extract() creates variables in the current scope, it doesn't create
objects' attributes and was never meant to do it."
Yet, its perfectly able to override the class's variables IF its not
extended. In other words, while as you say, its not designed to work
for classes, it does actually work ( if used only in a baseclass ).
So, you are right, its not a complete bug, its a incomplete "feature"
thats lacking the ability to see past its current scope with a extended
class.
Note: See several examples on the general mailing list where people use
the same methode.
The extract function will need a update to it scope range. Using a
foreach loop is a rather inefficient way of handeling it compared to a
extract.
[2006-09-07 22:09:28] [EMAIL PROTECTED]
Actually it has nothing to do with EXTR_.
extract() creates variables in the current scope, it doesn't create
objects' attributes and was never meant to do it.
[2006-09-07 22:05:26] arqentus at arqentus dot com
Note: The extract code was texted with EXTR_OVERWRITE & EXTR_IF_EXISTS.
The "EXTR_REFS" was a final foolish attempt to see how it was going to
react( expecting a error feedback, but nothing came ). Forgot to remove
it from the submitted code.
I'm including this comment, to be sure this bug does not get closed
becouse you think i used the wrong EXTR ;)
[2006-09-07 22:01:51] arqentus at arqentus dot com
Description:
extract does not override the values when using a extended class.
Note: Using a manual fill, will work:
class cText extends cField{
function __construct( $fields = array() ) {
foreach($fields as $key => $val ) {
$this->{$key} = $val;
}
//extract($fields, EXTR_REFS);
}
}
Looks like the extract can't handle the extend class.
Note: Using a normal NONE extended class, and extract will work.
Somehow it seems to lack the scope. Yet, a 'manual' foreach loop is
able to access the scope.
Differend combination have been tried ( moving the construct to the
parent, passing the fields to the parent and extracting there, etc ).
None are able to work.
Reproduce code:
---
class cField{
var $desc = 'xxx';
}
class cText extends cField{
function __construct( $fields = array() ) {
extract($fields, EXTR_REFS);
}
}
$user_name = new cText( array ( _desc => 'Name' ) );
echo $user_name->desc;
Expected result:
The expect result is: 'Name';
Actual result:
--
The result archieved is: 'xxx';
--
Edit this bug report at http://bugs.php.net/?id=38745&edit=1
#38745 [Bgs->Opn]: Extended Class & extract problems
ID: 38745
User updated by: arqentus at arqentus dot com
Reported By: arqentus at arqentus dot com
-Status: Bogus
+Status: Open
Bug Type: Class/Object related
Operating System: Windows 2003
PHP Version: 5.1.6
New Comment:
"extract() creates variables in the current scope, it doesn't create
objects' attributes and was never meant to do it."
Yet, its perfectly able to override the class's variables IF its not
extended. In other words, while as you say, its not designed to work
for classes, it does actually work ( if used only in a baseclass ).
So, you are right, its not a complete bug, its a incomplete "feature"
thats lacking the ability to see past its current scope with a extended
class.
Note: See several examples on the general mailing list where people use
the same methode.
The extract function will need a update to it scope range. Using a
foreach loop is a rather inefficient way of handeling it compared to a
extract.
Previous Comments:
[2006-09-07 22:09:28] [EMAIL PROTECTED]
Actually it has nothing to do with EXTR_.
extract() creates variables in the current scope, it doesn't create
objects' attributes and was never meant to do it.
[2006-09-07 22:05:26] arqentus at arqentus dot com
Note: The extract code was texted with EXTR_OVERWRITE & EXTR_IF_EXISTS.
The "EXTR_REFS" was a final foolish attempt to see how it was going to
react( expecting a error feedback, but nothing came ). Forgot to remove
it from the submitted code.
I'm including this comment, to be sure this bug does not get closed
becouse you think i used the wrong EXTR ;)
[2006-09-07 22:01:51] arqentus at arqentus dot com
Description:
extract does not override the values when using a extended class.
Note: Using a manual fill, will work:
class cText extends cField{
function __construct( $fields = array() ) {
foreach($fields as $key => $val ) {
$this->{$key} = $val;
}
//extract($fields, EXTR_REFS);
}
}
Looks like the extract can't handle the extend class.
Note: Using a normal NONE extended class, and extract will work.
Somehow it seems to lack the scope. Yet, a 'manual' foreach loop is
able to access the scope.
Differend combination have been tried ( moving the construct to the
parent, passing the fields to the parent and extracting there, etc ).
None are able to work.
Reproduce code:
---
class cField{
var $desc = 'xxx';
}
class cText extends cField{
function __construct( $fields = array() ) {
extract($fields, EXTR_REFS);
}
}
$user_name = new cText( array ( _desc => 'Name' ) );
echo $user_name->desc;
Expected result:
The expect result is: 'Name';
Actual result:
--
The result archieved is: 'xxx';
--
Edit this bug report at http://bugs.php.net/?id=38745&edit=1
#38745 [Opn->Bgs]: Extended Class & extract problems
ID: 38745
Updated by: [EMAIL PROTECTED]
Reported By: arqentus at arqentus dot com
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: Windows 2003
PHP Version: 5.1.6
New Comment:
Actually it has nothing to do with EXTR_.
extract() creates variables in the current scope, it doesn't create
objects' attributes and was never meant to do it.
Previous Comments:
[2006-09-07 22:05:26] arqentus at arqentus dot com
Note: The extract code was texted with EXTR_OVERWRITE & EXTR_IF_EXISTS.
The "EXTR_REFS" was a final foolish attempt to see how it was going to
react( expecting a error feedback, but nothing came ). Forgot to remove
it from the submitted code.
I'm including this comment, to be sure this bug does not get closed
becouse you think i used the wrong EXTR ;)
[2006-09-07 22:01:51] arqentus at arqentus dot com
Description:
extract does not override the values when using a extended class.
Note: Using a manual fill, will work:
class cText extends cField{
function __construct( $fields = array() ) {
foreach($fields as $key => $val ) {
$this->{$key} = $val;
}
//extract($fields, EXTR_REFS);
}
}
Looks like the extract can't handle the extend class.
Note: Using a normal NONE extended class, and extract will work.
Somehow it seems to lack the scope. Yet, a 'manual' foreach loop is
able to access the scope.
Differend combination have been tried ( moving the construct to the
parent, passing the fields to the parent and extracting there, etc ).
None are able to work.
Reproduce code:
---
class cField{
var $desc = 'xxx';
}
class cText extends cField{
function __construct( $fields = array() ) {
extract($fields, EXTR_REFS);
}
}
$user_name = new cText( array ( _desc => 'Name' ) );
echo $user_name->desc;
Expected result:
The expect result is: 'Name';
Actual result:
--
The result archieved is: 'xxx';
--
Edit this bug report at http://bugs.php.net/?id=38745&edit=1
#38745 [Opn]: Extended Class & extract problems
ID: 38745
User updated by: arqentus at arqentus dot com
Reported By: arqentus at arqentus dot com
Status: Open
Bug Type: Class/Object related
Operating System: Windows 2003
PHP Version: 5.1.6
New Comment:
Note: The extract code was texted with EXTR_OVERWRITE & EXTR_IF_EXISTS.
The "EXTR_REFS" was a final foolish attempt to see how it was going to
react( expecting a error feedback, but nothing came ). Forgot to remove
it from the submitted code.
I'm including this comment, to be sure this bug does not get closed
becouse you think i used the wrong EXTR ;)
Previous Comments:
[2006-09-07 22:01:51] arqentus at arqentus dot com
Description:
extract does not override the values when using a extended class.
Note: Using a manual fill, will work:
class cText extends cField{
function __construct( $fields = array() ) {
foreach($fields as $key => $val ) {
$this->{$key} = $val;
}
//extract($fields, EXTR_REFS);
}
}
Looks like the extract can't handle the extend class.
Note: Using a normal NONE extended class, and extract will work.
Somehow it seems to lack the scope. Yet, a 'manual' foreach loop is
able to access the scope.
Differend combination have been tried ( moving the construct to the
parent, passing the fields to the parent and extracting there, etc ).
None are able to work.
Reproduce code:
---
class cField{
var $desc = 'xxx';
}
class cText extends cField{
function __construct( $fields = array() ) {
extract($fields, EXTR_REFS);
}
}
$user_name = new cText( array ( _desc => 'Name' ) );
echo $user_name->desc;
Expected result:
The expect result is: 'Name';
Actual result:
--
The result archieved is: 'xxx';
--
Edit this bug report at http://bugs.php.net/?id=38745&edit=1
#38745 [NEW]: Extended Class & extract problems
From: arqentus at arqentus dot com
Operating system: Windows 2003
PHP version: 5.1.6
PHP Bug Type: Class/Object related
Bug description: Extended Class & extract problems
Description:
extract does not override the values when using a extended class.
Note: Using a manual fill, will work:
class cText extends cField{
function __construct( $fields = array() ) {
foreach($fields as $key => $val ) {
$this->{$key} = $val;
}
//extract($fields, EXTR_REFS);
}
}
Looks like the extract can't handle the extend class.
Note: Using a normal NONE extended class, and extract will work. Somehow
it seems to lack the scope. Yet, a 'manual' foreach loop is able to access
the scope.
Differend combination have been tried ( moving the construct to the
parent, passing the fields to the parent and extracting there, etc ). None
are able to work.
Reproduce code:
---
class cField{
var $desc = 'xxx';
}
class cText extends cField{
function __construct( $fields = array() ) {
extract($fields, EXTR_REFS);
}
}
$user_name = new cText( array ( _desc => 'Name' ) );
echo $user_name->desc;
Expected result:
The expect result is: 'Name';
Actual result:
--
The result archieved is: 'xxx';
--
Edit bug report at http://bugs.php.net/?id=38745&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38745&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38745&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38745&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38745&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38745&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38745&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38745&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38745&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38745&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38745&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38745&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38745&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38745&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38745&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38745&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38745&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38745&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38745&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38745&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38745&r=mysqlcfg
#38566 [Com]: SAFE MODE Restriction in effect without calling any php-file
ID: 38566 Comment by: tb at tbits dot net Reported By: noc at smartterra dot de Status: Feedback Bug Type: Apache2 related Operating System: FreeBSD 5.3 PHP Version: 4.4.4 New Comment: I've the same problem since 4.3.11 ! If also tried the SNAPSHOT php4-STABLE-200609072030 without any success. Why checks php normal html files ? The only one solution at the moment is to downgrade to 4.3.11 with many security problems. :-(. Thomas Previous Comments: [2006-09-06 09:17:29] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2006-09-06 09:12:26] noc at smartterra dot de Hm, sometimes this bug is still present with my new setup: PHP Warning: Unknown(): SAFE MODE Restriction in effect. The script whose uid/gid is 0/0 is not al lowed to access /usr/home/phpissue owned by uid/gid 1025/1025 in Unknown on line 0 "Don't halloo till you're out of the wood!" :-( [2006-09-05 20:17:19] noc at smartterra dot de I set up a completly new system with FreeBSd 6.1, Apache 2.0.59 and PHP4.4.4 - it works for me without any problems. [2006-09-05 10:21:04] info at nrg-systems dot de We have the same PHP warning messages in our log files since we've upgraded from 4.3.11 to 4.4.2 (also with 4.4.3 and 4.4.4). It looks like as every file access (including static HTML pages and even images) from the Apache server results in this PHP message. But the files are delivered to the clients browser. Especially the part "in Unknown on line 0" is an evidence that the PHP check is called even for non-PHP scripts. [2006-08-24 09:24:17] noc at smartterra dot de I saved a copy here: http://smartterra.de/phpissue.html 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/38566 -- Edit this bug report at http://bugs.php.net/?id=38566&edit=1
#38744 [Opn->Fbk]: PHP5TS.DLL causes w3svc crash and application pool termination
ID: 38744 Updated by: [EMAIL PROTECTED] Reported By: jneill at gamedaytv dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Windows 2003 SP 1 PHP Version: 5.1.6 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Previous Comments: [2006-09-07 20:42:44] jneill at gamedaytv dot com Description: Description: We have been successfully using PHP 5.1.2 for several months in our server environment. Only upgrading PHP to 5.1.6, with no other software upgrades, has resulted in frequent w3svc crashes and subsequent application pool terminations. The system log includes such errors as: --- A process serving application pool 'Site1' terminated unexpectedly. The process id was '5796'. The process exit code was '0xc005'. A process serving application pool 'Site2' terminated unexpectedly. The process id was '5212'. The process exit code was '0x'. A process serving application pool 'DefaultAppPool' terminated unexpectedly. The process id was '5824'. The process exit code was '0xc005'. --- We have run the IIS Diagnostics Debug Diagnostics Tool on these crashes, which has resulted in the following report for each crash: --- Type of Analysis Performed Crash Analysis Machine Name S76217 Operating System Windows Server 2003 Service Pack 1 Number Of Processors 2 Process ID 4736 Process Image c:\WINNT\system32\inetsrv\w3wp.exe System Up-Time 0 day(s) 04:18:05 Process Up-Time 0 day(s) 00:31:08 Thread 16 - System ID 2612 Entry point msvcrt!_endthread+3b Create time 5/16/2006 5:31:43 PM Time spent in user mode 0 Days 0:0:0.0 Time spent in kernel mode 0 Days 0:0:0.0 Function Arg 1 Arg 2 Arg 3 Source +265c80 02a28890 msvcrt!_endthread+ab 029e7580 kernel32!BaseThreadStart+34 77bcb35a 029e7580 In w3wp__PID__4736__Date__05_16_2006__Time_05_31_45PM__95__Second_Chance_Ex ception_C005.dmp an access violation exception (0xC005) occured on thread 16 when another module attempted to call the following unloaded module: php5ts.dll. --- -- Edit this bug report at http://bugs.php.net/?id=38744&edit=1
#38744 [NEW]: PHP5TS.DLL causes w3svc crash and application pool termination
From: jneill at gamedaytv dot com Operating system: Windows 2003 SP 1 PHP version: 5.1.6 PHP Bug Type: Reproducible crash Bug description: PHP5TS.DLL causes w3svc crash and application pool termination Description: Description: We have been successfully using PHP 5.1.2 for several months in our server environment. Only upgrading PHP to 5.1.6, with no other software upgrades, has resulted in frequent w3svc crashes and subsequent application pool terminations. The system log includes such errors as: --- A process serving application pool 'Site1' terminated unexpectedly. The process id was '5796'. The process exit code was '0xc005'. A process serving application pool 'Site2' terminated unexpectedly. The process id was '5212'. The process exit code was '0x'. A process serving application pool 'DefaultAppPool' terminated unexpectedly. The process id was '5824'. The process exit code was '0xc005'. --- We have run the IIS Diagnostics Debug Diagnostics Tool on these crashes, which has resulted in the following report for each crash: --- Type of Analysis Performed Crash Analysis Machine Name S76217 Operating System Windows Server 2003 Service Pack 1 Number Of Processors 2 Process ID 4736 Process Image c:\WINNT\system32\inetsrv\w3wp.exe System Up-Time 0 day(s) 04:18:05 Process Up-Time 0 day(s) 00:31:08 Thread 16 - System ID 2612 Entry point msvcrt!_endthread+3b Create time 5/16/2006 5:31:43 PM Time spent in user mode 0 Days 0:0:0.0 Time spent in kernel mode 0 Days 0:0:0.0 Function Arg 1 Arg 2 Arg 3 Source +265c80 02a28890 msvcrt!_endthread+ab 029e7580 kernel32!BaseThreadStart+34 77bcb35a 029e7580 In w3wp__PID__4736__Date__05_16_2006__Time_05_31_45PM__95__Second_Chance_Ex ception_C005.dmp an access violation exception (0xC005) occured on thread 16 when another module attempted to call the following unloaded module: php5ts.dll. --- -- Edit bug report at http://bugs.php.net/?id=38744&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38744&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38744&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38744&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38744&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38744&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38744&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38744&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38744&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38744&r=support Expected behavior:http://bugs.php.net/fix.php?id=38744&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38744&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38744&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38744&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38744&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38744&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38744&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38744&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38744&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38744&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38744&r=mysqlcfg
#38742 [Opn->WFx]: hebrew letters not converted properly
ID: 38742
Updated by: [EMAIL PROTECTED]
Reported By: ashabi at yahoo dot com
-Status: Open
+Status: Wont fix
Bug Type: *Unicode Issues
Operating System: windows
PHP Version: 4.4.4
New Comment:
You have to wait for PHP6 if you need Unicode support.
Previous Comments:
[2006-09-07 18:46:57] ashabi at yahoo dot com
Description:
When I explode a URL it does not display the hebrew character in my URL
properly.
Reproduce code:
---
$page = explode("/", $_SERVER['PATH_INFO']);
$letter = $page[7];
echo $letter;
$page[7] is a hebrew letter.
Expected result:
For example: à
Actual result:
--
For example: ×
FYI - If I were to use the $_REQUEST function then it would display the
hebrew letter properly.
--
Edit this bug report at http://bugs.php.net/?id=38742&edit=1
#38742 [NEW]: hebrew letters not converted properly
From: ashabi at yahoo dot com
Operating system: windows
PHP version: 4.4.4
PHP Bug Type: *Unicode Issues
Bug description: hebrew letters not converted properly
Description:
When I explode a URL it does not display the hebrew character in my URL
properly.
Reproduce code:
---
$page = explode("/", $_SERVER['PATH_INFO']);
$letter = $page[7];
echo $letter;
$page[7] is a hebrew letter.
Expected result:
For example: à
Actual result:
--
For example: ×
FYI - If I were to use the $_REQUEST function then it would display the
hebrew letter properly.
--
Edit bug report at http://bugs.php.net/?id=38742&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38742&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38742&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38742&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38742&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38742&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38742&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38742&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38742&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38742&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38742&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38742&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38742&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38742&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38742&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38742&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38742&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38742&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38742&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38742&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38742&r=mysqlcfg
#38577 [Opn->Fbk]: ini settings leak between virtual hosts with Apache 1.3
ID: 38577 Updated by: [EMAIL PROTECTED] Reported By: php at diptyque dot net -Status: Open +Status: Feedback Bug Type: Apache related Operating System: FreeBSD 4.4 PHP Version: 4.4.4 New Comment: I'm not sure I understand what you're trying to do and to say. Previous Comments: [2006-09-07 16:39:49] php at diptyque dot net FYI, I do *NOT* have any Zend or Xdebug extension installed... I have downloaded Xdebug only to compare its overriding technique with the one used in Mbstring extension. =begin [diptyque] % php -m [PHP Modules] bz2 ctype curl gd imap mbstring mysql openssl overload pcre posix readline session sqlite standard tokenizer xml zlib [Zend Modules] =end BTW, I compared source files for apache SAPI (./sapi/apache/mod_php4.c) and mbstring extension (./ext/mbstring/mbstring.c) between version 4.4.4 and latest stable version and did not find anything different (!?) [2006-09-07 15:25:39] [EMAIL PROTECTED] Please remove all zend_extensions, including XDebug and try again. [2006-09-07 15:14:49] php at diptyque dot net Antony, I'm not very familiar with Zend Engine 1.3 innards but I had a look at how Xdebug is overriding both var_dump() and set_time_limit() functions in PHP_RINIT_FUNCTION(xdebug) and how it does restore the original function pointers in PHP_RSHUTDOWN_FUNCTION(xdebug). Peeking at mbstring extension source code, this looks a bit more verbose and it doesn't fiddle directly with orig->internal_function.handler (!?) to restore the original function. Instead it calls subsequently zend_hash_update() and zend_hash_del() using the info it gathered inside its mb_overload_def struct... IMHO, mbstring ini settings are properly reset (please see http://bugs.php.net/bug.php?id=25753) but not the initial PHP function table state. [2006-09-07 09:29:53] php at diptyque dot net Sorry but it doesn't make it. Mbstring function overloading setting is unfortunately persistent once an Apache process has served content from a vhost where this ini parameter is assigned a value distinct from zero. [2006-09-06 16:31:20] [EMAIL PROTECTED] Fixed, thanks. What about your issue? 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/38577 -- Edit this bug report at http://bugs.php.net/?id=38577&edit=1
#38577 [Fbk->Opn]: ini settings leak between virtual hosts with Apache 1.3
ID: 38577 User updated by: php at diptyque dot net Reported By: php at diptyque dot net -Status: Feedback +Status: Open Bug Type: Apache related Operating System: FreeBSD 4.4 PHP Version: 4.4.4 New Comment: FYI, I do *NOT* have any Zend or Xdebug extension installed... I have downloaded Xdebug only to compare its overriding technique with the one used in Mbstring extension. =begin [diptyque] % php -m [PHP Modules] bz2 ctype curl gd imap mbstring mysql openssl overload pcre posix readline session sqlite standard tokenizer xml zlib [Zend Modules] =end BTW, I compared source files for apache SAPI (./sapi/apache/mod_php4.c) and mbstring extension (./ext/mbstring/mbstring.c) between version 4.4.4 and latest stable version and did not find anything different (!?) Previous Comments: [2006-09-07 15:25:39] [EMAIL PROTECTED] Please remove all zend_extensions, including XDebug and try again. [2006-09-07 15:14:49] php at diptyque dot net Antony, I'm not very familiar with Zend Engine 1.3 innards but I had a look at how Xdebug is overriding both var_dump() and set_time_limit() functions in PHP_RINIT_FUNCTION(xdebug) and how it does restore the original function pointers in PHP_RSHUTDOWN_FUNCTION(xdebug). Peeking at mbstring extension source code, this looks a bit more verbose and it doesn't fiddle directly with orig->internal_function.handler (!?) to restore the original function. Instead it calls subsequently zend_hash_update() and zend_hash_del() using the info it gathered inside its mb_overload_def struct... IMHO, mbstring ini settings are properly reset (please see http://bugs.php.net/bug.php?id=25753) but not the initial PHP function table state. [2006-09-07 09:29:53] php at diptyque dot net Sorry but it doesn't make it. Mbstring function overloading setting is unfortunately persistent once an Apache process has served content from a vhost where this ini parameter is assigned a value distinct from zero. [2006-09-06 16:31:20] [EMAIL PROTECTED] Fixed, thanks. What about your issue? [2006-09-06 16:13:00] php at diptyque dot net Just downloaded the latest stable release, built it and ran the test suite and mb_strlen() test case failed because AFAIK this version of PHP (4.4.5-dev) doesn't emit catchable errors yet (E_RECOVERABLE_ERROR). Anyway I'm going to install it tomorrow morning and will let you know ASAP if it does fix the ini settings leak between virtual hosts. === = /usr/local/src/php4-STABLE-200609061230/ext/mbstring/tests/ mb_strlen.phpt === = EXPECTED OUTPUT == ASCII == 40 40 == EUC-JP == 43 72 == SJIS == 43 72 == JIS == 43 90 == UTF-8 == 43 101 == WRONG PARAMETERS == ERR: Notice 5 ERR: Catchable fatal error ERR: Notice 6 ERR: Warning ACTUAL OUTPUT == ASCII == 40 40 == EUC-JP == 43 72 == SJIS == 43 72 == JIS == 43 90 == UTF-8 == 43 101 == WRONG PARAMETERS == ERR: Notice 5 ERR: Notice 6 ERR: Warning FAILED === = 019- ERR: Catchable fatal error 019+ ERR: Notice 020- ERR: Notice 020+ 6 021- 6 021+ ERR: Warning 022- ERR: Warning === = 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/38577 -- Edit this bug report at http://bugs.php.net/?id=38577&edit=1
#38577 [Opn->Fbk]: ini settings leak between virtual hosts with Apache 1.3
ID: 38577 Updated by: [EMAIL PROTECTED] Reported By: php at diptyque dot net -Status: Open +Status: Feedback Bug Type: Apache related Operating System: FreeBSD 4.4 PHP Version: 4.4.4 New Comment: Please remove all zend_extensions, including XDebug and try again. Previous Comments: [2006-09-07 15:14:49] php at diptyque dot net Antony, I'm not very familiar with Zend Engine 1.3 innards but I had a look at how Xdebug is overriding both var_dump() and set_time_limit() functions in PHP_RINIT_FUNCTION(xdebug) and how it does restore the original function pointers in PHP_RSHUTDOWN_FUNCTION(xdebug). Peeking at mbstring extension source code, this looks a bit more verbose and it doesn't fiddle directly with orig->internal_function.handler (!?) to restore the original function. Instead it calls subsequently zend_hash_update() and zend_hash_del() using the info it gathered inside its mb_overload_def struct... IMHO, mbstring ini settings are properly reset (please see http://bugs.php.net/bug.php?id=25753) but not the initial PHP function table state. [2006-09-07 09:29:53] php at diptyque dot net Sorry but it doesn't make it. Mbstring function overloading setting is unfortunately persistent once an Apache process has served content from a vhost where this ini parameter is assigned a value distinct from zero. [2006-09-06 16:31:20] [EMAIL PROTECTED] Fixed, thanks. What about your issue? [2006-09-06 16:13:00] php at diptyque dot net Just downloaded the latest stable release, built it and ran the test suite and mb_strlen() test case failed because AFAIK this version of PHP (4.4.5-dev) doesn't emit catchable errors yet (E_RECOVERABLE_ERROR). Anyway I'm going to install it tomorrow morning and will let you know ASAP if it does fix the ini settings leak between virtual hosts. === = /usr/local/src/php4-STABLE-200609061230/ext/mbstring/tests/ mb_strlen.phpt === = EXPECTED OUTPUT == ASCII == 40 40 == EUC-JP == 43 72 == SJIS == 43 72 == JIS == 43 90 == UTF-8 == 43 101 == WRONG PARAMETERS == ERR: Notice 5 ERR: Catchable fatal error ERR: Notice 6 ERR: Warning ACTUAL OUTPUT == ASCII == 40 40 == EUC-JP == 43 72 == SJIS == 43 72 == JIS == 43 90 == UTF-8 == 43 101 == WRONG PARAMETERS == ERR: Notice 5 ERR: Notice 6 ERR: Warning FAILED === = 019- ERR: Catchable fatal error 019+ ERR: Notice 020- ERR: Notice 020+ 6 021- 6 021+ ERR: Warning 022- ERR: Warning === = [2006-09-06 09:58:07] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip 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/38577 -- Edit this bug report at http://bugs.php.net/?id=38577&edit=1
#38577 [Opn]: ini settings leak between virtual hosts with Apache 1.3
ID: 38577 User updated by: php at diptyque dot net Reported By: php at diptyque dot net Status: Open Bug Type: Apache related Operating System: FreeBSD 4.4 PHP Version: 4.4.4 New Comment: Antony, I'm not very familiar with Zend Engine 1.3 innards but I had a look at how Xdebug is overriding both var_dump() and set_time_limit() functions in PHP_RINIT_FUNCTION(xdebug) and how it does restore the original function pointers in PHP_RSHUTDOWN_FUNCTION(xdebug). Peeking at mbstring extension source code, this looks a bit more verbose and it doesn't fiddle directly with orig->internal_function.handler (!?) to restore the original function. Instead it calls subsequently zend_hash_update() and zend_hash_del() using the info it gathered inside its mb_overload_def struct... IMHO, mbstring ini settings are properly reset (please see http://bugs.php.net/bug.php?id=25753) but not the initial PHP function table state. Previous Comments: [2006-09-07 09:29:53] php at diptyque dot net Sorry but it doesn't make it. Mbstring function overloading setting is unfortunately persistent once an Apache process has served content from a vhost where this ini parameter is assigned a value distinct from zero. [2006-09-06 16:31:20] [EMAIL PROTECTED] Fixed, thanks. What about your issue? [2006-09-06 16:13:00] php at diptyque dot net Just downloaded the latest stable release, built it and ran the test suite and mb_strlen() test case failed because AFAIK this version of PHP (4.4.5-dev) doesn't emit catchable errors yet (E_RECOVERABLE_ERROR). Anyway I'm going to install it tomorrow morning and will let you know ASAP if it does fix the ini settings leak between virtual hosts. === = /usr/local/src/php4-STABLE-200609061230/ext/mbstring/tests/ mb_strlen.phpt === = EXPECTED OUTPUT == ASCII == 40 40 == EUC-JP == 43 72 == SJIS == 43 72 == JIS == 43 90 == UTF-8 == 43 101 == WRONG PARAMETERS == ERR: Notice 5 ERR: Catchable fatal error ERR: Notice 6 ERR: Warning ACTUAL OUTPUT == ASCII == 40 40 == EUC-JP == 43 72 == SJIS == 43 72 == JIS == 43 90 == UTF-8 == 43 101 == WRONG PARAMETERS == ERR: Notice 5 ERR: Notice 6 ERR: Warning FAILED === = 019- ERR: Catchable fatal error 019+ ERR: Notice 020- ERR: Notice 020+ 6 021- 6 021+ ERR: Warning 022- ERR: Warning === = [2006-09-06 09:58:07] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2006-08-28 15:56:47] php at diptyque dot net Dunno for PHP 5 -- I have to make some tests before trying to switch -- but I wonder if this bug could be related to http://bugs.php.net/bug.php?id=37932. 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/38577 -- Edit this bug report at http://bugs.php.net/?id=38577&edit=1
#36895 [Fbk->Opn]: Access Violation and Faulting Application (both Apache & IIS)
ID: 36895 User updated by: jsschuetz at knapheide dot com Reported By: jsschuetz at knapheide dot com -Status: Feedback +Status: Open Bug Type: ODBC related Operating System: server2003/WinXP Pro PHP Version: 5.1.2 New Comment: We were able to solve the problem. It had to do with null terminated strings in the DB2 database on the AS400. There must be an issue with the IBM ODBC driver or something that does not always handle the data/error appropriately and when and error is thrown it crashes PHP and the web server. When we stopped null terminating the data in the table, the problem when away. Hope this helps Previous Comments: [2006-09-07 13:57:03] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-09-07 13:51:40] karlsonas at mazylis dot lt P.S. I'm on Win2K3, using MySQL 5.0.x [2006-09-07 13:49:43] karlsonas at mazylis dot lt Hi, I've tryed several combinations of Apache/PHP and found only one which still generated error, but Apache recovers from crach and continues to work. It's PHP 5.1.1/Apache 2.0.55 Combinations on which Apache crashes without recovering: PHP5.1.4/Apache2.0.58 PHP5.1.6/Apache2.0.59 PHP5.1.1/Apache2.0.59 PHP5.1.6/Apache2.0.55 I have two servers - test and production with exact configuration and code. And strangest thing that I have PHP5.1.4/Apache2.0.58 working without any problems on test server and can't get it crash at all. On production server I have crach after 15-30mins after upgrade. Of course production server is used by 100-200 users... I've tryed to look through acceess/error logs but really can't find what is cousing this crash ... Could You please give me a way to debug that not rising production servers resources use ? I will try to follow instructions on back-trace .. but it's kind a hard on prod server :) Wish me luch :) [2006-08-02 10:50:04] matthius at pointbtel dot com I'm fairly certain that I am suffering from this same bug. Though I am not using ODBC, I do however hit MySQL pretty hard. Sadly I'm not equipped to generate a backtrace on this machine. This is a major problem though, I am going to have to roll everything back to PHP4 bacause i can't seem to keep Apache on its feet for more than 15 min as it is. I'm currently running PHP 5.1.4 and I've tried Apache 2.0.53 and 2.2.3. - both die the same way :-( - Matt [2006-04-20 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/36895 -- Edit this bug report at http://bugs.php.net/?id=36895&edit=1
#36286 [Com]: Variable holding query results has to be unset
ID: 36286
Comment by: barry dot verdon at complinet dot com
Reported By: memoimyself at yahoo dot com dot br
Status: No Feedback
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.1.2
New Comment:
I have experienced the same thing on 5.1.3 on Debian. Here is the test
case I used
$db = new PDO(DSN, USERNAME, PASSWORD);
$stmt = $db->query('SELECT 1+1 AS answer');
$answer = $stmt->fetch(PDO::FETCH_ASSOC); // All fine here
$stmt = $db->query('SELECT 1+2 AS result');
$result = $stmt->fetch(PDO::FETCH_ASSOC); // Result is false
It does the same thing with a foreach loop. But if you named the
variables $stmt1 and $stmt2 is would work fine. It even caused a
problem when I had a class wrapping, not extending, PDOStatement,
slightly different error, on the __call magic method instead, but with
different variable names all worked fine.
Previous Comments:
[2006-02-12 01:00:03] 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".
[2006-02-04 18:47:21] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-02-04 14:39:58] memoimyself at yahoo dot com dot br
Description:
When running more than one query in a row with PDO, if the result set
is assigned to a variable with the same name (e.g. $result) each time,
only the first assignment works properly: from the second time on, the
variable will contain an empty result set.
I have tested my code in two different setups: Linux (A2 Web Hosting
server running PHP 5.1.2) and Windows XP (my test server, also running
PHP 5.1.2). This problem ONLY occurs in the first setup (Linux).
It does not matter which "fetch style" is used.
I have worked around this problem by unsetting the result variable each
time as soon as all data has been fetched from it.
Reproduce code:
---
$dbh = new PDO(BD_DSN, BD_USERNAME, BD_PWD);
if ($result = $dbh->query('SELECT * FROM table_1'))
{
$all_rows_1 = $result->fetchAll(PDO::FETCH_OBJ);
}
if ($result = $dbh->query('SELECT * FROM table_2'))
{
$all_rows_2 = $result->fetchAll(PDO::FETCH_OBJ);
}
Expected result:
If both tables actually contain data, $all_rows_1 and $all_rows_2
should both contain all the data from each table.
Actual result:
--
When code similar to the example is run on my Windows XP test server,
everything works as expected.
When, however, the same code is run on the Linux production server,
$all_rows_2 will contain an empty array rather than an array with
objects representing each row from the table.
If I add unset($result) after each $result->fetchAll(PDO::FETCH_OBJ),
then everything works well on the Linux server as well.
Curiously, I have had no problems assigning other types of object the
variables with the same name in a sequence or loop (e.g. when creating
XML elements in a loop and assigning them to a variable with the same
name each time).
--
Edit this bug report at http://bugs.php.net/?id=36286&edit=1
#37448 [Com]: FastCGI Error: Server too busy Server
ID: 37448 Comment by: robert dot sevcik at gmail dot com Reported By: coder1 at gmail dot com Status: No Feedback Bug Type: CGI related Operating System: Windows XP PHP Version: 5.1.4 New Comment: I'm sorry for spamming, but I went a step further, downgraded to PHP Version 5.1.0-dev and the FastCGI has no problem. Build date Jun 21 2005 12:21:48 Previous Comments: [2006-09-07 10:20:42] robert dot sevcik at gmail dot com I tested it with my app, output_buffering doesn't workaround the problem fully. Bigger output still harmes the fastcgi. [2006-09-07 10:13:19] robert dot sevcik at gmail dot com Hello, I confirm, still no go with latest snapshot - 5.2.0RC4-dev, Build Date Sep 7 2006 00:15:28 I tried phpinfo() with CGI only, go Tried the same with isapi_fcgi.dll, no go Then I changed output_buffering=1000 and... GO! :) (Windows 2003 server SP1) [2006-07-30 23:34:14] djohnson241 at gmail dot com Some more information( hopefully useful ). After further testing I was able to determine that this is only happening for me if I output a lot of text at once. If I split it up into a bunch of smaller echo's, it works fine. Unfortunately this doesn't work with my template system, as all output is echoed in one statement. dave [2006-07-30 23:16:36] djohnson241 at gmail dot com I can verify the above experiment. I got the 5.2 snapshot and used the following: ", 131); ?> That works fine. But change the 131 to 132 and you get the 503 error. At a loss. dave [2006-06-28 01:00:02] 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/37448 -- Edit this bug report at http://bugs.php.net/?id=37448&edit=1
#36895 [NoF->Fbk]: Access Violation and Faulting Application (both Apache & IIS)
ID: 36895 Updated by: [EMAIL PROTECTED] Reported By: jsschuetz at knapheide dot com -Status: No Feedback +Status: Feedback Bug Type: ODBC related Operating System: server2003/WinXP Pro PHP Version: 5.1.2 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Previous Comments: [2006-09-07 13:51:40] karlsonas at mazylis dot lt P.S. I'm on Win2K3, using MySQL 5.0.x [2006-09-07 13:49:43] karlsonas at mazylis dot lt Hi, I've tryed several combinations of Apache/PHP and found only one which still generated error, but Apache recovers from crach and continues to work. It's PHP 5.1.1/Apache 2.0.55 Combinations on which Apache crashes without recovering: PHP5.1.4/Apache2.0.58 PHP5.1.6/Apache2.0.59 PHP5.1.1/Apache2.0.59 PHP5.1.6/Apache2.0.55 I have two servers - test and production with exact configuration and code. And strangest thing that I have PHP5.1.4/Apache2.0.58 working without any problems on test server and can't get it crash at all. On production server I have crach after 15-30mins after upgrade. Of course production server is used by 100-200 users... I've tryed to look through acceess/error logs but really can't find what is cousing this crash ... Could You please give me a way to debug that not rising production servers resources use ? I will try to follow instructions on back-trace .. but it's kind a hard on prod server :) Wish me luch :) [2006-08-02 10:50:04] matthius at pointbtel dot com I'm fairly certain that I am suffering from this same bug. Though I am not using ODBC, I do however hit MySQL pretty hard. Sadly I'm not equipped to generate a backtrace on this machine. This is a major problem though, I am going to have to roll everything back to PHP4 bacause i can't seem to keep Apache on its feet for more than 15 min as it is. I'm currently running PHP 5.1.4 and I've tried Apache 2.0.53 and 2.2.3. - both die the same way :-( - Matt [2006-04-20 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". [2006-04-12 14:59:28] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. 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/36895 -- Edit this bug report at http://bugs.php.net/?id=36895&edit=1
#36895 [Com]: Access Violation and Faulting Application (both Apache & IIS)
ID: 36895
Comment by: karlsonas at mazylis dot lt
Reported By: jsschuetz at knapheide dot com
Status: No Feedback
Bug Type: ODBC related
Operating System: server2003/WinXP Pro
PHP Version: 5.1.2
New Comment:
P.S. I'm on Win2K3, using MySQL 5.0.x
Previous Comments:
[2006-09-07 13:49:43] karlsonas at mazylis dot lt
Hi,
I've tryed several combinations of Apache/PHP and found only one which
still generated error, but Apache recovers from crach and continues to
work. It's PHP 5.1.1/Apache 2.0.55
Combinations on which Apache crashes without recovering:
PHP5.1.4/Apache2.0.58
PHP5.1.6/Apache2.0.59
PHP5.1.1/Apache2.0.59
PHP5.1.6/Apache2.0.55
I have two servers - test and production with exact configuration and
code. And strangest thing that I have PHP5.1.4/Apache2.0.58 working
without any problems on test server and can't get it crash at all. On
production server I have crach after 15-30mins after upgrade.
Of course production server is used by 100-200 users...
I've tryed to look through acceess/error logs but really can't find
what is cousing this crash ...
Could You please give me a way to debug that not rising production
servers resources use ?
I will try to follow instructions on back-trace .. but it's kind a hard
on prod server :)
Wish me luch :)
[2006-08-02 10:50:04] matthius at pointbtel dot com
I'm fairly certain that I am suffering from this same bug.
Though I am not using ODBC, I do however hit MySQL pretty
hard.
Sadly I'm not equipped to generate a backtrace on this
machine. This is a major problem though, I am going to have
to roll everything back to PHP4 bacause i can't seem to keep
Apache on its feet for more than 15 min as it is.
I'm currently running PHP 5.1.4 and I've tried Apache 2.0.53
and 2.2.3. - both die the same way :-(
- Matt
[2006-04-20 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".
[2006-04-12 14:59:28] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
[2006-04-12 13:30:47] jsschuetz at knapheide dot com
I narrowed down the code causing the problem. The below is the entire
program that will cause the error at random.
I am connecting to a DB2 database on an AS400 Iseries with ODCB drivers
provided by IBM client access software.
-
$con = odbc_connect('as400','username','password');
?>
Version 6
http://bugs.php.net/36895
--
Edit this bug report at http://bugs.php.net/?id=36895&edit=1
#36895 [Com]: Access Violation and Faulting Application (both Apache & IIS)
ID: 36895
Comment by: karlsonas at mazylis dot lt
Reported By: jsschuetz at knapheide dot com
Status: No Feedback
Bug Type: ODBC related
Operating System: server2003/WinXP Pro
PHP Version: 5.1.2
New Comment:
Hi,
I've tryed several combinations of Apache/PHP and found only one which
still generated error, but Apache recovers from crach and continues to
work. It's PHP 5.1.1/Apache 2.0.55
Combinations on which Apache crashes without recovering:
PHP5.1.4/Apache2.0.58
PHP5.1.6/Apache2.0.59
PHP5.1.1/Apache2.0.59
PHP5.1.6/Apache2.0.55
I have two servers - test and production with exact configuration and
code. And strangest thing that I have PHP5.1.4/Apache2.0.58 working
without any problems on test server and can't get it crash at all. On
production server I have crach after 15-30mins after upgrade.
Of course production server is used by 100-200 users...
I've tryed to look through acceess/error logs but really can't find
what is cousing this crash ...
Could You please give me a way to debug that not rising production
servers resources use ?
I will try to follow instructions on back-trace .. but it's kind a hard
on prod server :)
Wish me luch :)
Previous Comments:
[2006-08-02 10:50:04] matthius at pointbtel dot com
I'm fairly certain that I am suffering from this same bug.
Though I am not using ODBC, I do however hit MySQL pretty
hard.
Sadly I'm not equipped to generate a backtrace on this
machine. This is a major problem though, I am going to have
to roll everything back to PHP4 bacause i can't seem to keep
Apache on its feet for more than 15 min as it is.
I'm currently running PHP 5.1.4 and I've tried Apache 2.0.53
and 2.2.3. - both die the same way :-(
- Matt
[2006-04-20 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".
[2006-04-12 14:59:28] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
[2006-04-12 13:30:47] jsschuetz at knapheide dot com
I narrowed down the code causing the problem. The below is the entire
program that will cause the error at random.
I am connecting to a DB2 database on an AS400 Iseries with ODCB drivers
provided by IBM client access software.
-
$con = odbc_connect('as400','username','password');
?>
Version 6
http://bugs.php.net/?id=36895&edit=1
#38549 [Com]: Cannot reference name of file calling function
ID: 38549
Comment by: dtyschenko at soft-ukraine dot com
Reported By: phpbugs at replies dot cyways dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: Linux (CentOS 4.3)
PHP Version: 5.1.5
New Comment:
You can use Exceptions call stack
Previous Comments:
[2006-08-22 19:32:07] phpbugs at replies dot cyways dot com
Description:
It appears to be impossible to determine the name of a file that calls
a function stored in another file, e.g., a class library included at
startup. The __FILE__ variable returns the name of the script which
contains the function called (the class library in this example), but
there doesn't seem to be any comparable variable that returns the name
of the file where the function is invoked.
In my particular case, I have a simple library function
debug('debugtext',trigger_level) which compares trigger_level to a
global value and prints 'debugtext' as appropriate. I'd like to be
able to print out the name of the file that called this function as
well so I can trace errors more efficiently. As it stands now, I don't
see any way to do this other than some kludge that uses
get_included_files().
--
Edit this bug report at http://bugs.php.net/?id=38549&edit=1
#38741 [NEW]: inconsistent feedback when accessing a null object
From: fh at ez dot no Operating system: linux PHP version: 5.1.6 PHP Bug Type: Scripting Engine problem Bug description: inconsistent feedback when accessing a null object Description: Accessing a null object will only result in a notice if you are accessing a property but a fatal error if you are trying to access a method. This is especially strange if the object you expected to access uses __get and so you actually expect your code to fail. I think at the very least that the notice should be upgraded to a warning. An error is also in place since accessing a member variable of a null value is most probably a serious problem in your application. Reproduce code: --- member; // notice $var->member(); // fatal error ?> -- Edit bug report at http://bugs.php.net/?id=38741&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38741&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38741&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38741&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38741&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38741&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38741&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38741&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38741&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38741&r=support Expected behavior:http://bugs.php.net/fix.php?id=38741&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38741&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38741&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38741&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38741&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38741&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38741&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38741&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38741&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38741&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38741&r=mysqlcfg
#38740 [Opn->Asn]: mysqli_stmt::$errno not available
ID: 38740 Updated by: [EMAIL PROTECTED] Reported By: dave at psntn dot com -Status: Open +Status: Assigned Bug Type: MySQLi related Operating System: Linux (SUSE 9.3) PHP Version: 6CVS-2006-09-07 (CVS) -Assigned To: +Assigned To: georg New Comment: >This might be due to the extension not having been upgraded for unicode Yes. Assigned to the maintainer. Previous Comments: [2006-09-07 10:50:42] dave at psntn dot com Description: When using PHP6.0.0-dev (checked out from CVS, updated in the last 20 mins) the $errno property of mysqli_stmt is not defined. This only happens when unicode.semantics = on. This might be due to the extension not having been upgraded for unicode but I can't quickly find any list of the status of the various extensions. PHP Configure statement: ./configure --prefix=/srv/httpd/php6/php6 --with-apxs2=/srv/httpd/php6/httpd/bin/apxs --with-mysqli=/usr/local/mysql/bin/mysql_config --with-mysql=/usr/local/mysql --with-pear --with-gd --with-png-dir=/usr --enable-gd-native-ttf --with-jpeg-dir=/usr --with-png --with-zlib-dir=/usr --enable-sockets --with-bz2 --with-dom --with-ftp --with-pdf --with-cpdf --with-sqlite --with-freetype-dir=/usr --enable-bcmath --with-tiff-dir=/usr --enable-exif --enable-simplexml --enable-soap --with-zip --enable-mbstring --enable-mbstr-enc-trans --disable-mbregex --with-curl --with-pdo --with-pdo_mysql=/usr/local/mysql/bin/mysql_config php.ini: unicode.semantics = on Reproduce code: --- http://php4.david-salisbury.co.uk/mysqli.phps Expected result: unicode.semantics = off // just to show unicode semantics status Error code for insert of (1, 2, 3, 4): 0 Error code for insert of (1, 5, 6, 7): 1062 Actual result: -- unicode.semantics = on // just to show unicode semantics status Error code for insert of (1, 2, 3, 4): Notice: Undefined property: mysqli_stmt::$errno in /www/testingServer/php6test/mysqli.php on line 31 Error code for insert of (1, 5, 6, 7): Notice: Undefined property: mysqli_stmt::$errno in /www/testingServer/php6test/mysqli.php on line 41 -- Edit this bug report at http://bugs.php.net/?id=38740&edit=1
#38740 [NEW]: mysqli_stmt::$errno not available
From: dave at psntn dot com Operating system: Linux (SUSE 9.3) PHP version: 6CVS-2006-09-07 (CVS) PHP Bug Type: MySQLi related Bug description: mysqli_stmt::$errno not available Description: When using PHP6.0.0-dev (checked out from CVS, updated in the last 20 mins) the $errno property of mysqli_stmt is not defined. This only happens when unicode.semantics = on. This might be due to the extension not having been upgraded for unicode but I can't quickly find any list of the status of the various extensions. PHP Configure statement: ./configure --prefix=/srv/httpd/php6/php6 --with-apxs2=/srv/httpd/php6/httpd/bin/apxs --with-mysqli=/usr/local/mysql/bin/mysql_config --with-mysql=/usr/local/mysql --with-pear --with-gd --with-png-dir=/usr --enable-gd-native-ttf --with-jpeg-dir=/usr --with-png --with-zlib-dir=/usr --enable-sockets --with-bz2 --with-dom --with-ftp --with-pdf --with-cpdf --with-sqlite --with-freetype-dir=/usr --enable-bcmath --with-tiff-dir=/usr --enable-exif --enable-simplexml --enable-soap --with-zip --enable-mbstring --enable-mbstr-enc-trans --disable-mbregex --with-curl --with-pdo --with-pdo_mysql=/usr/local/mysql/bin/mysql_config php.ini: unicode.semantics = on Reproduce code: --- http://php4.david-salisbury.co.uk/mysqli.phps Expected result: unicode.semantics = off // just to show unicode semantics status Error code for insert of (1, 2, 3, 4): 0 Error code for insert of (1, 5, 6, 7): 1062 Actual result: -- unicode.semantics = on // just to show unicode semantics status Error code for insert of (1, 2, 3, 4): Notice: Undefined property: mysqli_stmt::$errno in /www/testingServer/php6test/mysqli.php on line 31 Error code for insert of (1, 5, 6, 7): Notice: Undefined property: mysqli_stmt::$errno in /www/testingServer/php6test/mysqli.php on line 41 -- Edit bug report at http://bugs.php.net/?id=38740&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38740&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38740&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38740&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38740&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38740&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38740&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38740&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38740&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38740&r=support Expected behavior:http://bugs.php.net/fix.php?id=38740&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38740&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38740&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38740&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38740&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38740&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38740&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38740&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38740&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38740&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38740&r=mysqlcfg
#37448 [Com]: FastCGI Error: Server too busy Server
ID: 37448 Comment by: robert dot sevcik at gmail dot com Reported By: coder1 at gmail dot com Status: No Feedback Bug Type: CGI related Operating System: Windows XP PHP Version: 5.1.4 New Comment: I tested it with my app, output_buffering doesn't workaround the problem fully. Bigger output still harmes the fastcgi. Previous Comments: [2006-09-07 10:13:19] robert dot sevcik at gmail dot com Hello, I confirm, still no go with latest snapshot - 5.2.0RC4-dev, Build Date Sep 7 2006 00:15:28 I tried phpinfo() with CGI only, go Tried the same with isapi_fcgi.dll, no go Then I changed output_buffering=1000 and... GO! :) (Windows 2003 server SP1) [2006-07-30 23:34:14] djohnson241 at gmail dot com Some more information( hopefully useful ). After further testing I was able to determine that this is only happening for me if I output a lot of text at once. If I split it up into a bunch of smaller echo's, it works fine. Unfortunately this doesn't work with my template system, as all output is echoed in one statement. dave [2006-07-30 23:16:36] djohnson241 at gmail dot com I can verify the above experiment. I got the 5.2 snapshot and used the following: ", 131); ?> That works fine. But change the 131 to 132 and you get the 503 error. At a loss. dave [2006-06-28 01:00:02] 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". [2006-06-20 14:48:06] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip 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/37448 -- Edit this bug report at http://bugs.php.net/?id=37448&edit=1
#37448 [Com]: FastCGI Error: Server too busy Server
ID: 37448 Comment by: robert dot sevcik at gmail dot com Reported By: coder1 at gmail dot com Status: No Feedback Bug Type: CGI related Operating System: Windows XP PHP Version: 5.1.4 New Comment: Hello, I confirm, still no go with latest snapshot - 5.2.0RC4-dev, Build Date Sep 7 2006 00:15:28 I tried phpinfo() with CGI only, go Tried the same with isapi_fcgi.dll, no go Then I changed output_buffering=1000 and... GO! :) (Windows 2003 server SP1) Previous Comments: [2006-07-30 23:34:14] djohnson241 at gmail dot com Some more information( hopefully useful ). After further testing I was able to determine that this is only happening for me if I output a lot of text at once. If I split it up into a bunch of smaller echo's, it works fine. Unfortunately this doesn't work with my template system, as all output is echoed in one statement. dave [2006-07-30 23:16:36] djohnson241 at gmail dot com I can verify the above experiment. I got the 5.2 snapshot and used the following: ", 131); ?> That works fine. But change the 131 to 132 and you get the 503 error. At a loss. dave [2006-06-28 01:00:02] 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". [2006-06-20 14:48:06] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-05-30 15:16:14] coder1 at gmail dot com The bug does seem to go away with the 5.2 version. I am also able to reproduce the behavior described by msisolak exactly. 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/37448 -- Edit this bug report at http://bugs.php.net/?id=37448&edit=1
#38739 [NEW]: stream_socket_server should not require a port
From: magicaltux at ookoo dot org Operating system: * PHP version: 5.1.6 PHP Bug Type: Feature/Change Request Bug description: stream_socket_server should not require a port Description: When trying, for example, to do : We get the following output : Warning: stream_socket_server(): unable to connect to tcp://0.0.0.0 (Failed to parse address "0.0.0.0") in /home/magicaltux/- on line 2 string(33) "Failed to parse address "0.0.0.0"" Expected result would be to have no port passed to bind, and thru having a random port allocated by the operating system (that we would later retrieve with stream_socket_get_name). In socket_bind, the port is also optionnal. It's still possible to get a random port by using ":0" but the no-port behaviour would be great too (and probably not too hard to implement). Reproduce code: --- Expected result: string(0) "" Actual result: -- Warning: stream_socket_server(): unable to connect to tcp://0.0.0.0 (Failed to parse address "0.0.0.0") in /home/magicaltux/- on line 2 string(33) "Failed to parse address "0.0.0.0"" -- Edit bug report at http://bugs.php.net/?id=38739&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38739&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38739&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38739&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38739&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38739&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38739&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38739&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38739&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38739&r=support Expected behavior:http://bugs.php.net/fix.php?id=38739&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38739&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38739&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38739&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38739&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38739&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38739&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38739&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38739&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38739&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38739&r=mysqlcfg
#38577 [Fbk->Opn]: ini settings leak between virtual hosts with Apache 1.3
ID: 38577 User updated by: php at diptyque dot net Reported By: php at diptyque dot net -Status: Feedback +Status: Open Bug Type: Apache related Operating System: FreeBSD 4.4 PHP Version: 4.4.4 New Comment: Sorry but it doesn't make it. Mbstring function overloading setting is unfortunately persistent once an Apache process has served content from a vhost where this ini parameter is assigned a value distinct from zero. Previous Comments: [2006-09-06 16:31:20] [EMAIL PROTECTED] Fixed, thanks. What about your issue? [2006-09-06 16:13:00] php at diptyque dot net Just downloaded the latest stable release, built it and ran the test suite and mb_strlen() test case failed because AFAIK this version of PHP (4.4.5-dev) doesn't emit catchable errors yet (E_RECOVERABLE_ERROR). Anyway I'm going to install it tomorrow morning and will let you know ASAP if it does fix the ini settings leak between virtual hosts. === = /usr/local/src/php4-STABLE-200609061230/ext/mbstring/tests/ mb_strlen.phpt === = EXPECTED OUTPUT == ASCII == 40 40 == EUC-JP == 43 72 == SJIS == 43 72 == JIS == 43 90 == UTF-8 == 43 101 == WRONG PARAMETERS == ERR: Notice 5 ERR: Catchable fatal error ERR: Notice 6 ERR: Warning ACTUAL OUTPUT == ASCII == 40 40 == EUC-JP == 43 72 == SJIS == 43 72 == JIS == 43 90 == UTF-8 == 43 101 == WRONG PARAMETERS == ERR: Notice 5 ERR: Notice 6 ERR: Warning FAILED === = 019- ERR: Catchable fatal error 019+ ERR: Notice 020- ERR: Notice 020+ 6 021- 6 021+ ERR: Warning 022- ERR: Warning === = [2006-09-06 09:58:07] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2006-08-28 15:56:47] php at diptyque dot net Dunno for PHP 5 -- I have to make some tests before trying to switch -- but I wonder if this bug could be related to http://bugs.php.net/bug.php?id=37932. [2006-08-25 15:51:25] judas dot iscariote at gmail dot com PHP5 produces the same effects for you ? 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/38577 -- Edit this bug report at http://bugs.php.net/?id=38577&edit=1
#38738 [Opn->Bgs]: infinite loops causes wait condition to other pages having session_start()
ID: 38738 Updated by: [EMAIL PROTECTED] Reported By: awahid at gmail dot com -Status: Open +Status: Bogus Bug Type: Session related -Operating System: Linux +Operating System: * -PHP Version: 5.1.6 +PHP Version: * 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 Close the session early using session_close(). Previous Comments: [2006-09-07 06:57:43] awahid at gmail dot com Description: /* run the code to understand better */ Go /*otherPage --- */ -- Edit this bug report at http://bugs.php.net/?id=38738&edit=1
