#43134 [Fbk->Opn]: Apache2 crashes upon processing any php page.
ID: 43134 User updated by: akujin at akujin dot com Reported By: akujin at akujin dot com -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Vista 32-bit PHP Version: 5.2.4 New Comment: Ok, Here are a few backtraces, to show reproduction: Report for httpd__PID__6908__Date__10_30_2007__Time_11_30_23PM__571__Second_Chance_Exception_C005.dmp Type of Analysis Performed Crash Analysis Machine Name ISUKA-PC Operating System Windows Vista Number Of Processors 1 Process ID 6908 Process Image C:\Program Files\Apache Software Foundation\Apache2.2\bin\httpd.exe System Up-Time 1 day(s) 00:26:58 Process Up-Time 00:00:36 Thread 250 - System ID 8012 Entry point msvcrt!_endthreadex+6f Create time 10/30/2007 23:29:47 Time spent in user mode 0 Days 0:0:0.15 Time spent in kernel mode 0 Days 0:0:0.15 Function Arg 1 Arg 2 Arg 3 Source php5ts!zend_hash_destroy+d 014904c8 00d278cc php_threads!zm_deactivate_threads+38 0001 001d 01577ea0 php5ts!module_registry_cleanup+1c 014884e8 01577ea0 01577ea0 php5ts!zend_hash_apply+40 011d43c0 00d278b0 01577ea0 php5ts!zend_deactivate_modules+62 0573ff88 56433230 php5ts!zend_deactivate_modules+48 0155c301 0591a728 php5ts!php_end_ob_buffers+26 0573fb90 01577ea0 0004 php5ts!execute+1c5 0573ff88 56433230 php5ts!php_request_shutdown+137 015bc5f0 1008 00ddb59c php5ts!_efree+39 0591aa30 00ca2560 01577ea0 php5ts!php_execute_script+24c 00ce20c0 01577ea0 0004 php5apache2_2!php_handler+643 PHP5TS!ZEND_HASH_DESTROY+DIn httpd__PID__6908__Date__10_30_2007__Time_11_30_23PM__571__Second_Chance_Exception_C005.dmp the assembly instruction at php5ts!zend_hash_destroy+d in C:\Program Files\PHP\php5ts.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x0014 on thread 250 Module Information Image Name: C:\Program Files\PHP\php5ts.dll Symbol Type: PDB Base address: 0x00d2 Time Stamp: Thu Aug 30 04:06:12 2007 Checksum: 0x Comments: COM DLL: False Company Name: The PHP Group ISAPIExtension: False File Description: PHP Script Interpreter ISAPIFilter: False File Version: 5.2.4.4 Managed DLL: False Internal Name: php5ts.dll VB DLL: False Legal Copyright: Copyright © 1997-2007 The PHP Group Loaded Image Name: php5ts.dll Legal Trademarks: PHP Mapped Image Name: C:\Program Files\PHP\php5ts.dll Original filename: php5ts.dll Module name: php5ts Private Build: Single Threaded: False Product Name: PHP Script Interpreter Module Size: 4.86 MBytes Product Version: 5.2.4 Symbol File Name: C:\Users\isuka\Downloads\php-debug-pack-5.2.4-Win32\php5ts.pdb Special Build: & Report for httpd__PID__6400__Date__10_30_2007__Time_11_29_33PM__267__Second_Chance_Exception_C005.dmp Report for httpd__PID__6400__Date__10_30_2007__Time_11_29_33PM__267__Second_Chance_Exception_C005.dmp Type of Analysis Performed Crash Analysis Machine Name ISUKA-PC Operating System Windows Vista Number Of Processors 1 Process ID 6400 Process Image C:\Program Files\Apache Software Foundation\Apache2.2\bin\httpd.exe System Up-Time 1 day(s) 00:26:12 Process Up-Time 00:00:06 Thread 2 - System ID 5884 Entry point msvcrt!_endthreadex+6f Create time 10/30/2007 23:29:28 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 php5ts!zend_hash_destroy+d 014304c8 00d278cc php_threads!zm_deactivate_threads+38 0001 001d 015a7b78 php5ts!module_registry_cleanup+1c 014284e8 015a7b78 015a7b78 php5ts!zend_hash_apply+40 011d43c0 00d278b0 015a7b78 php5ts!zend_deactivate_modules+62 0123ff88 56433230 php5ts!zend_deactivate_modules+48 0158c201 05b5a728 php5ts!php_end_ob_buffers+26 00fe630c 09dc 0123fdc8 php5ts!php_body_write+1d 0123ff88 56433230 php5ts!php_request_shutdown+137 001a 015a7b78 00dc23ba php5ts!ts_resource_ex+15 015a7b78 php5ts!zend_file_handle_dtor+a 0123fe80 00ca2560 015a7b78 php5ts!php_execute_script+59 00ce60d0 015a7b78 0004 php5apache2_2!php_handler+643 PHP5TS!ZEND_HASH_DESTROY+DIn httpd__PID__6400__Date__10_30_2007__Time_11_29_33PM__267__Second_Chance_Exception_C005.dmp the assembly instruction at php5ts!zend_hash_destroy+d in C:\Program Files\PHP\php5t
#43156 [NEW]: not getting results
From: ocknu at comcast dot net
Operating system: vista x64
PHP version: 5.2.4
PHP Bug Type: Scripting Engine problem
Bug description: not getting results
Description:
can not get the code to work right. instead of giving a true respond it
gives a false ll the time. why?
running from url http://127.0.0.1
Reproduce code:
---
echo "Checking current url ";
if (stristr($url, '127.0.0.1') === TRUE) {
echo 'You are running as localhost(127.0.0.1),
this is not smart and can result in wrong paths';
}
elseif (stristr($url, 'localhost') === TRUE) {
echo 'You are running as localhost, this is not
smart and can result in wrong paths';
}
echo 'Found url: ';
echo $url."";
Expected result:
You are running as localhost(127.0.0.1), this is not smart and can result
in wrong paths
Actual result:
--
found url: 127.0.0.1
--
Edit bug report at http://bugs.php.net/?id=43156&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43156&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43156&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43156&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43156&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43156&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43156&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43156&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43156&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43156&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43156&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43156&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43156&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43156&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43156&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43156&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43156&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43156&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43156&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43156&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43156&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43156&r=mysqlcfg
#43152 [Opn]: php throws 100x error on ntdll.dll
ID: 43152 User updated by: kevinbell at converger dot com -Summary: php throws 1004 error on ntdll.dll Reported By: kevinbell at converger dot com Status: Open Bug Type: IIS related Operating System: Windows 2003 PHP Version: 5.2.4 New Comment: Event Type: Error Event Source: Application Error Event Category: (100) Event ID: 1000 Date: 10/30/2007 Time: 8:01:42 PM User: N/A Computer: Description: Faulting application php.exe, version 5.2.4.4, faulting module ntdll.dll, version 5.2.3790.3959, fault address 0x0001a379. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Data: : 41 70 70 6c 69 63 61 74 Applicat 0008: 69 6f 6e 20 46 61 69 6c ion Fail 0010: 75 72 65 20 20 70 68 70 ure php 0018: 2e 65 78 65 20 35 2e 32 .exe 5.2 0020: 2e 34 2e 34 20 69 6e 20 .4.4 in 0028: 6e 74 64 6c 6c 2e 64 6c ntdll.dl 0030: 6c 20 35 2e 32 2e 33 37 l 5.2.37 0038: 39 30 2e 33 39 35 39 20 90.3959 0040: 61 74 20 6f 66 66 73 65 at offse 0048: 74 20 30 30 30 31 61 33 t 0001a3 0050: 37 39 79 Previous Comments: [2007-10-30 22:47:05] kevinbell at converger dot com Description: faulting application: php.exe version 5.2.4 faulting module ntdll.dll As a result, PHP loads, but doesn't actually do anything in IIS, and cannot access MySQL. -- Edit this bug report at http://bugs.php.net/?id=43152&edit=1
#43155 [NEW]: make test; generates error and says to email text file
From: mvensky at qnet dot com Operating system: solaris 10 i86 PHP version: 5.2.5RC1 PHP Bug Type: Scripting Engine problem Bug description: make test; generates error and says to email text file Description: once get email address will respond with text file; version not correct 5.2.3 but not a choice in your picklist Reproduce code: --- n/a Expected result: make test to run without errors Actual result: -- make test errors out; config and make ran fine; make install dies -- Edit bug report at http://bugs.php.net/?id=43155&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43155&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43155&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43155&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43155&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43155&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43155&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43155&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43155&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43155&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43155&r=support Expected behavior:http://bugs.php.net/fix.php?id=43155&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43155&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43155&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43155&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43155&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43155&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43155&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43155&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43155&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43155&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43155&r=mysqlcfg
#43154 [Opn->Fbk]: __toArray() or __toIterator() Magic Method?
ID: 43154 Updated by: [EMAIL PROTECTED] Reported By: smoseley at transio dot com -Status: Open +Status: Feedback Bug Type: Feature/Change Request Operating System: Linux PHP Version: 5.2.4 New Comment: What's wrong with the Iterator and IteratorAggregate interfaces? Previous Comments: [2007-10-31 00:21:24] smoseley at transio dot com Description: Would love to see a __toArray() MM added that would default to an associative array of an object's properties in scope, but that could be overloaded with whatever. It would be very useful in cases where a specific method is required to iterate through an object's properties. Thanks! :) -- Edit this bug report at http://bugs.php.net/?id=43154&edit=1
#43154 [NEW]: __toArray() or __toIterator() Magic Method?
From: smoseley at transio dot com Operating system: Linux PHP version: 5.2.4 PHP Bug Type: Feature/Change Request Bug description: __toArray() or __toIterator() Magic Method? Description: Would love to see a __toArray() MM added that would default to an associative array of an object's properties in scope, but that could be overloaded with whatever. It would be very useful in cases where a specific method is required to iterate through an object's properties. Thanks! :) -- Edit bug report at http://bugs.php.net/?id=43154&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43154&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43154&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43154&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43154&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43154&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43154&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43154&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43154&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43154&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43154&r=support Expected behavior:http://bugs.php.net/fix.php?id=43154&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43154&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43154&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43154&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43154&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43154&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43154&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43154&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43154&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43154&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43154&r=mysqlcfg
#43147 [Fbk->Opn]: Random "PHP Fatal error: Maximum execution time of 60 seconds exceeded"
ID: 43147
User updated by: marquinhocb at hotmail dot com
Reported By: marquinhocb at hotmail dot com
-Status: Feedback
+Status: Open
Bug Type: Performance problem
Operating System: Windows Server 2003 R2 x64
PHP Version: 5.2.4
New Comment:
That's the weird thing - it's almost like an infinite loop. If I
increase the timeout to 120 seconds, or 240, or decrease it to 30
seconds, it continues to stall in similar lines: always on a call to
print()
Terribly sorry, here's the info:
Apache 2.2.4
PHP Apache Module
Previous Comments:
[2007-10-30 22:08:29] [EMAIL PROTECTED]
It's pretty normal that sometimes things take time, especially with
high load if the scripts are "heavy". Have you tried increasing the
max_execution time in your php.ini? Also, you didn't give any
information about your setup, like what webserver you're using, whether
you use FastCGI/CGI or some module?
[2007-10-30 17:52:15] marquinhocb at hotmail dot com
Description:
I can only get this to happen on a production server. It may have to
do with the server load. I have the exact same setup on my local
machine, never experienced this problem.
Server is a Dual-Processor Xeon Dual Core (4 cores in total).
I am willing to debug and help in any way necessary, I am a
professional software engineer.
After getting these errors, I made my own extension with extended
debugging information to help trace the problem.
Reproduce code:
---
Nothing special about the code causing the stall, as you can see:
windowmanager.class.php:
304: if (! $this->hasFooter)
305:print(""); //content
menumanager.class.php:
81: else if ((count ($j->subItems) > 0) || ($j->forceSub))
82: {
83: print("menuBarVar}.MenuItemMouseover(event,
'{$j->id}');\">");
Expected result:
The stall always seems to be on a print(), and obviously this should
not be a stalling or very intensive function.
Actual result:
--
[30-Oct-2007 09:22:48] PHP Fatal error: Maximum execution time of 60
seconds exceeded
End()
End()
End()
in D:\yuniti\includes\windowmanager.class.php [/index.php] on line
305
[30-Oct-2007 09:39:24] PHP Fatal error: Maximum execution time of 60
seconds exceeded
InternalOutputItem()
InternalOutputItem()
InternalOutputSubItems()
Output()
Output()
Output()
in D:\yuniti\includes\menumanager.class.php [/user.php] on line 83
[30-Oct-2007 09:42:02] PHP Fatal error: Maximum execution time of 60
seconds exceeded
InternalOutputItem()
InternalOutputItem()
InternalOutputSubItems()
Output()
Output()
Output()
in D:\yuniti\includes\menumanager.class.php [/user.php] on line 83
[30-Oct-2007 09:47:08] PHP Fatal error: Maximum execution time of 60
seconds exceeded
End()
End()
End()
in D:\yuniti\includes\windowmanager.class.php [/index.php] on line 305
--
Edit this bug report at http://bugs.php.net/?id=43147&edit=1
#43144 [Opn->Fbk]: configure fails checking for c++ compiler
ID: 43144 Updated by: [EMAIL PROTECTED] Reported By: babt at us dot ibm dot com -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Mac OS X 10.5 PHP Version: 5.2.4 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi IIRC, I fixed something related to this in CVS. Previous Comments: [2007-10-30 23:05:33] babt at us dot ibm dot com Nope, no extensions. The problem is that configure is looking for the presence of the C++ compiler and even though it's not being used, it doesn't finish the configuration if it can't find one!!! [2007-10-30 22:10:49] [EMAIL PROTECTED] You have some 3rd party extensions added by yourself in the build or what? There aren't any C++ extensions in the PHP core, AFAIK. [2007-10-30 18:12:39] babt at us dot ibm dot com Here's the configure line used... ./configure --prefix=/usr/local/php5 --with-config-file- path=/usr/local/php5/lib --with-mysql=/usr/local/mysql --with-pdo- mysql=/usr/local/mysql --with-apxs2 --with-pcre-regex --with-iconv -- with-openssl --with-zlib --with-mysqli=/usr/local/mysql/bin/mysql_config --with-libxml --with-xsl --with-xmlrpc --enable-wddx --with-curl -- enable-exit --enable-soap --enable-ftp --enable-calendar --enable-dbx -- enable-sockets --with-bz2 --enable-dbase --enable-fastcgi --enable- mbstring --with-pdflib --with-mysql-sock=/tmp/mysql.sock [2007-10-30 17:13:25] [EMAIL PROTECTED] What configure line did you use? [2007-10-30 14:32:54] babt at us dot ibm dot com Description: When running configure, process fails to properly detect c++ due to previous failure to remove a directory. Below is the stream from the script. Configuring libtool checking build system type... i686-apple-darwin9.0.0 checking for ld used by gcc... /usr/libexec/gcc/i686-apple- darwin9/4.0.1/ld checking if the linker (/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld) is GNU ld... no checking for /usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking how to recognise dependent libraries... pass_all checking for object suffix... o checking for executable suffix... rm: conftest.dSYM: is a directory .dSYM checking for c++... c++ checking whether the C++ compiler (c++ ) works... no configure: error: installation or configuration problem: C++ compiler cannot create executables. Reproduce code: --- Plain vanilla OS X 10.5 Leopard build with Xcode 3.0 tools installed. Expected result: Configuring libtool checking build system type... i686-apple-darwin9.0.0 checking for ld used by /Developer/usr/bin/cc... /Developer/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld checking if the linker (/Developer/usr/libexec/gcc/i686-apple- darwin9/4.0.1/ld) is GNU ld... no checking for /Developer/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld option to reload object files... -r checking for BSD-compatible nm... /Developer/usr/bin/nm -p checking how to recognise dependent libraries... pass_all checking for object suffix... o checking for executable suffix... .dSYM checking for c++... c++ checking whether the C++ compiler (c++ ) works... yes Actual result: -- As in description. Workaround - Change configure script to use 'rm -rf' during the check for the executable suffix. -- Edit this bug report at http://bugs.php.net/?id=43144&edit=1
#43144 [Fbk->Opn]: configure fails checking for c++ compiler
ID: 43144 User updated by: babt at us dot ibm dot com Reported By: babt at us dot ibm dot com -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Mac OS X 10.5 PHP Version: 5.2.4 New Comment: Nope, no extensions. The problem is that configure is looking for the presence of the C++ compiler and even though it's not being used, it doesn't finish the configuration if it can't find one!!! Previous Comments: [2007-10-30 22:10:49] [EMAIL PROTECTED] You have some 3rd party extensions added by yourself in the build or what? There aren't any C++ extensions in the PHP core, AFAIK. [2007-10-30 18:12:39] babt at us dot ibm dot com Here's the configure line used... ./configure --prefix=/usr/local/php5 --with-config-file- path=/usr/local/php5/lib --with-mysql=/usr/local/mysql --with-pdo- mysql=/usr/local/mysql --with-apxs2 --with-pcre-regex --with-iconv -- with-openssl --with-zlib --with-mysqli=/usr/local/mysql/bin/mysql_config --with-libxml --with-xsl --with-xmlrpc --enable-wddx --with-curl -- enable-exit --enable-soap --enable-ftp --enable-calendar --enable-dbx -- enable-sockets --with-bz2 --enable-dbase --enable-fastcgi --enable- mbstring --with-pdflib --with-mysql-sock=/tmp/mysql.sock [2007-10-30 17:13:25] [EMAIL PROTECTED] What configure line did you use? [2007-10-30 14:32:54] babt at us dot ibm dot com Description: When running configure, process fails to properly detect c++ due to previous failure to remove a directory. Below is the stream from the script. Configuring libtool checking build system type... i686-apple-darwin9.0.0 checking for ld used by gcc... /usr/libexec/gcc/i686-apple- darwin9/4.0.1/ld checking if the linker (/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld) is GNU ld... no checking for /usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking how to recognise dependent libraries... pass_all checking for object suffix... o checking for executable suffix... rm: conftest.dSYM: is a directory .dSYM checking for c++... c++ checking whether the C++ compiler (c++ ) works... no configure: error: installation or configuration problem: C++ compiler cannot create executables. Reproduce code: --- Plain vanilla OS X 10.5 Leopard build with Xcode 3.0 tools installed. Expected result: Configuring libtool checking build system type... i686-apple-darwin9.0.0 checking for ld used by /Developer/usr/bin/cc... /Developer/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld checking if the linker (/Developer/usr/libexec/gcc/i686-apple- darwin9/4.0.1/ld) is GNU ld... no checking for /Developer/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld option to reload object files... -r checking for BSD-compatible nm... /Developer/usr/bin/nm -p checking how to recognise dependent libraries... pass_all checking for object suffix... o checking for executable suffix... .dSYM checking for c++... c++ checking whether the C++ compiler (c++ ) works... yes Actual result: -- As in description. Workaround - Change configure script to use 'rm -rf' during the check for the executable suffix. -- Edit this bug report at http://bugs.php.net/?id=43144&edit=1
#43153 [NEW]: ALERT ECHO FOR PHP
From: jmartyn at nctimes dot com Operating system: winxpsp2 PHP version: 5.2.4 PHP Bug Type: PHP options/info functions Bug description: ALERT ECHO FOR PHP Description: To aide programmers, and for fasting coding techniques it would be wonderful to have a php alert dialog that automatically and/or manually disappears during parsing. Reproduce code: --- In the process of coding and for text placement ease, it would be easier for php in the browser to alert any such special echo statements instead of displaying them. It takes on the average of one second to find your echo statement on a full page. I see so many webmasters color coding echo statements. Some going as far as quick code javascript inserts. It would be so easy to include and it would save so much time. Webmasters are always flipping back and forth. I thought it would be good to have the php.ini file contain the config of the alert box such as: interval between two windows from closing to opening whether it was closed manually or automatically time a window is open. have the option to manually or automatically close alert windows This would certainly make debugging so much easier because you can set whether it would display the alert code in the parse later on, therefore it would ignore the alerts but leave them for future debugging instead of commenting them out or erasing them. It's pure PHP genius. Who wouldn't want it? -- Edit bug report at http://bugs.php.net/?id=43153&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43153&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43153&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43153&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43153&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43153&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43153&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43153&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43153&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43153&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43153&r=support Expected behavior:http://bugs.php.net/fix.php?id=43153&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43153&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43153&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43153&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43153&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43153&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43153&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43153&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43153&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43153&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43153&r=mysqlcfg
#35386 [Sus->Csd]: firebird: first row is null
ID: 35386
Updated by: [EMAIL PROTECTED]
Reported By: slapaf at hotmail dot com
-Status: Suspended
+Status: Closed
Bug Type: PDO related
Operating System: winxp sp2
PHP Version: 5CVS-2006-12-02 (snap)
Assigned To: jacques
New Comment:
Fixed in CVS (PHP_5_3 branch)
Previous Comments:
[2007-10-12 17:31:08] Lars dot Westermann at privat dot dk
Well, tried to dig into this ...
After some trial and error, I found this little quick and dirty trick,
which solves (or rather works around) another quick and dirty trick ...
Try this in etc/pdo_firebird/firebird_statement.c:
/* called by PDO to retrieve information about the fields being
returned */
static int firebird_stmt_describe(pdo_stmt_t *stmt, int colno
TSRMLS_DC) /* {{{ */
{
pdo_firebird_stmt *S = (pdo_firebird_stmt*)stmt->driver_data;
struct pdo_column_data *col = &stmt->columns[colno];
XSQLVAR *var = &S->out_sqlda.sqlvar[colno];
/* allocate storage for the column */
var->sqlind = (void*)emalloc(var->sqllen + 2*sizeof(short));
var->sqldata = &((char*)var->sqlind)[sizeof(short)];
col->precision = -var->sqlscale;
col->maxlen = var->sqllen;
col->namelen = var->aliasname_length;
col->name = estrndup(var->aliasname,var->aliasname_length);
/*
* Compensates for hack in another function:
* Force data-type in column to string
*/
col->param_type = PDO_PARAM_STR;
/* = */
return 1;
}
/* }}} */
The same hack is found in same module, in another function, but AFTER
the columntype is set for the first row - hence it works for the
subsequent rows ...
static int firebird_stmt_get_col(pdo_stmt_t *stmt, int colno, char
**ptr, /* {{{ */
unsigned long *len, int *caller_frees TSRMLS_DC)
{
pdo_firebird_stmt *S = (pdo_firebird_stmt*)stmt->driver_data;
XSQLVAR const *var = &S->out_sqlda.sqlvar[colno];
if (*var->sqlind == -1) {
/* A NULL value */
*ptr = NULL;
*len = 0;
} else {
/* override the column param type */
/* set_param_type(&stmt->columns[colno].param_type,var); */
=>stmt->columns[colno].param_type = PDO_PARAM_STR;
if (var->sqlscale < 0) {
static ISC_INT64 const scales[] = { 1, 10, 100, 1000,
1, 10, 100,
1, 10, 10,
LL_LIT(100),LL_LIT(1000),
The row pointed to above (=>) could/should be removed, as
columntype definition _should_ be handled in firebird_stmt_describe()
function (where my hack resides).
I have tested this with PHP 5.2.4 on Fedora Core 7 - and this hack
works. I miss the total overview of PDO, so I can't reactivate the
code-parts originally handling conversion from native Firebird/Interbase
sql-type to PDO datatype constants. But this work should be done. If I
have/get the time, and come to understand the code better, I would be
happy to contribute.
For now I hope the above can help anyone, who compile the source, and
that this quick and dirty hack can make it into the next release
(5.2.5?) of PHP. It works, but is not the long term solution, I think.
Greetings,
Lars
[2007-10-09 00:07:26] acerb at softhome dot net
System :
Windows NT 5.1 build 2600 (MS Windows XP SP2)
Apache 2.0
PHP 5.1.2 & 5.2.3
I tried several methods :
PDOStatement->fetchAll(), PDOStatement->fetch(), PDO->query()
with arguments :
PDO::FETCH_NUM, PDO::FETCH_ASSOC, PDO::FETCH_LAZY,
PDO::FETCH_COLUMN, PDO::FETCH_GROUP
same result : First row is missing
Array (
[LAN_ID] =>
[LAN_NAME_EN] =>
[LAN_CODE] => )
Array (
[LAN_ID] => 2
[LAN_NAME_EN] => FRENCH
[LAN_CODE] => FR )
Array (
[LAN_ID] => 3
[LAN_NAME_EN] => ENGLISH
[LAN_CODE] => EN )
I tried with different tables and select statements and I always got
the same result. As it seems to be a pretty obvious bug/error, could it
be corrected in the next release (of PHP), please ?
[2007-10-04 09:11:55] tetikr at spytech dot cz
This is quite an old bug (2 years!) and yet not fixed in 5.2.4.
Ridiculous! I'm using Doctrine with Firebird and it makes me crazy. Do
something about it, please.
[2007-08-20 15:47:04] dong_peng at 163 dot com
I have met the same problem.
OS : Windows XP SP2
PHP: 5.2.3
Firebird : WI-V6.3.1.12855 Firebird 2.0
I have a simple table named school in my database, the CREATE TABLE
statement is as below :
CREATE TABLE school
( school_code SMALLINT PRIMARY KEY,
school_name VARCHAR(40) NOT NULL,
short_name VARCHAR(20)
);
#41522 [Asn->Csd]: PDO firebird driver returns null if it fails to connect
ID: 41522
Updated by: [EMAIL PROTECTED]
Reported By: mark-phpbugs at vectrex dot org dot uk
-Status: Assigned
+Status: Closed
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.2.2
Assigned To: abies
New Comment:
Fixed in CVS (PHP_5_3 branch)
Previous Comments:
[2007-10-12 20:26:01] Lars dot Westermann at privat dot dk
See comment for bug #39822, where a fix is suggested.
Greetings,
Lars
[2007-05-28 17:08:09] mark-phpbugs at vectrex dot org dot uk
Description:
The firebird PDO driver returns nothing, or null if it fails to connect
- this is contradictory to what the PDO documentation says (should throw
PDOException) and the behaviour of the other drivers.
Reproduce code:
---
$conn = new PDO("firebird:dbname=localhost:test.fdb",
'SYSDBA','wrong password');
Expected result:
It should throw a PDOException, ideally with an explanation or error
code.
Actual result:
--
Returns NULL with no errors or warnings even with
error_reporting(E_ALL)
--
Edit this bug report at http://bugs.php.net/?id=41522&edit=1
#39822 [Sus->Csd]: new PDO() doesn't work with firebird
ID: 39822
Updated by: [EMAIL PROTECTED]
Reported By: bx at clansphere dot de
-Status: Suspended
+Status: Closed
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5CVS-2006-12-13 (snap)
Assigned To: wez
New Comment:
Fixed in CVS (PHP_5_3 branch)
Previous Comments:
[2007-10-12 20:21:45] Lars dot Westermann at privat dot dk
The above mentioned block didn't print the correct error-code; use this
instead:
if (!dbh->methods) {
char errmsg[512];
long *pvector = H->isc_status;
isc_interprete(errmsg, &pvector);
zend_throw_exception_ex(php_pdo_get_exception(), 0 TSRMLS_CC,
"SQLSTATE[%s] [%d] %s",
"HY000", (short) H->isc_status[1], errmsg);
}
(Use the (short) typecast to get the correct error-code)
Greetings,
Lars
[2007-10-12 20:14:26] Lars dot Westermann at privat dot dk
Maybe not the correct way of doing this, but it works:
In ext/pdo_firebird/firebird_driver.c:
/* the driver-specific PDO handle constructor */
static int pdo_firebird_handle_factory(pdo_dbh_t *dbh, zval
*driver_options TSRMLS_DC) /* {{{ */
{
struct pdo_data_src_parser vars[] = {
{ "dbname", NULL, 0 },
{ "charset", NULL, 0 },
{ "role", NULL, 0 }
};
int i, ret = 0;
short buf_len = 256, dpb_len;
pdo_firebird_db_handle *H = dbh->driver_data =
pecalloc(1,sizeof(*H),dbh->is_persistent);
php_pdo_parse_data_source(dbh->data_source, dbh->data_source_len,
vars, 3);
do {
static char const dpb_flags[] = {
isc_dpb_user_name, isc_dpb_password, isc_dpb_lc_ctype,
isc_dpb_sql_role_name };
char const *dpb_values[] = { dbh->username, dbh->password,
vars[1].optval, vars[2].optval };
char dpb_buffer[256] = { isc_dpb_version1 }, *dpb;
dpb = dpb_buffer + 1;
/* loop through all the provided arguments and set dpb fields
accordingly */
for (i = 0; i < sizeof(dpb_flags); ++i) {
if (dpb_values[i] && buf_len > 0) {
dpb_len = slprintf(dpb, buf_len, "%c%c%s",
dpb_flags[i], (unsigned char)strlen(dpb_values[i]),
dpb_values[i]);
dpb += dpb_len;
buf_len -= dpb_len;
}
}
/* fire it up baby! */
if (isc_attach_database(H->isc_status, 0, vars[0].optval,
&H->db,(short)(dpb-dpb_buffer), dpb_buffer)) {
break;
}
dbh->methods = &firebird_methods;
dbh->native_case = PDO_CASE_UPPER;
dbh->alloc_own_columns = 1;
ret = 1;
} while (0);
for (i = 0; i < sizeof(vars)/sizeof(vars[0]); ++i) {
if (vars[i].freeme) {
efree(vars[i].optval);
}
}
if (!dbh->methods) {
char errmsg[512];
long *pvector = H->isc_status;
isc_interprete(errmsg, &pvector);
zend_throw_exception_ex(php_pdo_get_exception(), 0 TSRMLS_CC,
"SQLSTATE[%s] [%d] %s",
"HY000", (long) H->isc_status[1], errmsg);
}
if (!ret) {
firebird_handle_closer(dbh TSRMLS_CC);
}
return ret;
}
/* }}} */
IMHO the _firebird_error() function should be written like the
functions in pdo_pgsql and pdo_mysql, which - to mee - look like they
are built on the same template - and the firebird version is not.
But the above codeblock containing the zend_throw_exception_ex() does
it's job and prints the firebird errormessage.
Hope it at least can serve as a quick fix, until the a more correct
approach (better error-handler) has been made.
Greetings,
Lars
[2006-12-18 15:26:50] [EMAIL PROTECTED]
Looking for a maintainer
[2006-12-13 22:08:25] bx at clansphere dot de
Description:
using try/catch doesn't work for firebird like it works with other
rdbms extensions. i think the problem is that firebird returns something
(NULL) so that try expects all went well, but it is not checking for the
PDO object itself.
i am using is_object() currently to look for errors, but that way i
can't get errorcodes like 'database does not exist' for example and even
when track_errors is enabled $php_errormsg is empty.
Reproduce code:
---
try {
$connection = new PDO('firebird:dbname=test.fdb', $user,
$password);
}
catch(PDOException $error) {
echo $error->getMessage();
}
Expected result:
catch can be called to get the exact error
Actual result:
--
try statement thinks everything is ok
--
Edit this bug report at http://bugs.php.net/?id=39822&edit=1
#43152 [NEW]: php throws 1004 error on ntdll.dll
From: kevinbell at converger dot com Operating system: Windows 2003 PHP version: 5.2.4 PHP Bug Type: IIS related Bug description: php throws 1004 error on ntdll.dll Description: faulting application: php.exe version 5.2.4 faulting module ntdll.dll As a result, PHP loads, but doesn't actually do anything in IIS, and cannot access MySQL. -- Edit bug report at http://bugs.php.net/?id=43152&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43152&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43152&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43152&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43152&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43152&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43152&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43152&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43152&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43152&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43152&r=support Expected behavior:http://bugs.php.net/fix.php?id=43152&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43152&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43152&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43152&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43152&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43152&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43152&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43152&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43152&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43152&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43152&r=mysqlcfg
#36128 [Sus->Csd]: Interbase PDO
ID: 36128
Updated by: [EMAIL PROTECTED]
Reported By: michael at bluemoon dot com
-Status: Suspended
+Status: Closed
Bug Type: PDO related
Operating System: Linux/Windows
PHP Version: 5.1.2
New Comment:
Fixed in PHP_5_3 branch
Previous Comments:
[2006-04-09 07:48:28] [EMAIL PROTECTED]
Looking for a firebird maintainer.
[2006-01-25 17:08:02] michael at bluemoon dot com
To amend my earlier problem description, it appears that I CAN issue
the SELECT query shown in my previous example successfully. However, it
appears that I cannot retrieve values from TIMESTAMP-type columns.
If I substitute "SELECT MY_TIMESTAMP_FIELD FROM MY_TABLE" for the query
in my original code, it will execute without throwing an exception, but
the value returned is empty (null). The result I am expecting is an
integer (Unix timestamp) value.
I don't know if this constitutes a 'bug' or if I am simply not going
about this the right way. I have tried many of the various permutations
for fetching results as shown in the PDO documentation, but nothing
seems to work.
Is there a way to fetch TIMESTAMP values using the Firebird/Interbase
PDO driver?
[2006-01-23 10:51:33] [EMAIL PROTECTED]
Assigned to the maintainer.
[2006-01-23 02:21:25] michael at bluemoon dot com
Description:
Exception thrown when issuing SELECT query using PDO driver
for Firebird/Interbase. Database Server runs Interbase 7.5.x
(Linux).
Problem occurs with PHP 5.1.2 running in both Linux/Apache 2
and Windows 2000/IIS environments.
Tried running PHP alternately with Interbase 6 and 7.5 Run-
time Client Libraries on each platform; same problem.
Native PHP Firebird/Interbase functions (e.g., ibase_connect
(), etc.) functions work fine in same environments used to
test PDO functions.
Confirmed DSN string used in my PDO connection function is
correct by testing PDO::ATTR_CONNECTION_STATUS attribute;
value returned is 1.
Reproduce code:
---
try {
$dbh = new PDO($dsn, $user, $password, array(
PDO::ATTR_PERSISTENT => true
));
$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$stmt = $dbh->prepare("SELECT Count(*) FROM MY_TABLE");
$stmt->execute();
$row = $stmt->fetch(PDO::FETCH_NUM);
$stmt = null;
echo $row[0];
}
catch (PDOException $e) {
die $e->getMessage();
}
Expected result:
Should output integer value result from SELECT query to screen
Actual result:
--
Outputs the following error:
SQLSTATE[HY000]: General error: -804 Dynamic SQL Error SQL
error code = -804 Incorrect values within SQLDA structure
--
Edit this bug report at http://bugs.php.net/?id=36128&edit=1
#42294 [Asn]: round will not use PHP_ROUND_FUZZ on 64bit CPUs
ID: 42294
Updated by: [EMAIL PROTECTED]
Reported By: oliver at teqneers dot de
Status: Assigned
Bug Type: *Configuration Issues
-Operating System: OpenSuSE 10.2
+Operating System: *
-PHP Version: 5.2.4RC1
+PHP Version: 5CVS-2007-10-30
Assigned To: iliaa
New Comment:
Previous comment has good points. I'm leaning towards the C99
approach..but that's for Ilia to decide. :)
Previous Comments:
[2007-08-16 12:53:18] chris_se at gmx dot net
I just read this bug report and wanted to add a few things. Rounding
floating point numbers is anything but trivial.
The core issue is that certain numbers which are representable with
only a finite amount of digits in the decimal system are not necessarily
representable with a finite amount of digits in the binary system. The
number 0.285 in this bug report is an example for that: In the binary
system, its representation is periodic - just as 1/3 can only be
displayed as a periodic number (0.3...) in the decimal system.
Since a floating point number only supports a finite number of digits,
the period is "cut off" and therefore the number 0.285 stored as a float
is not exactly 0.285 but slightly smaller, you can try it yourself:
2
0.28497558
(The exact representation may vary depending on how percise the
floating point unit in your processor is.)
Another number 1.285 mentioned in this thread also has the same
problem:
1.28492006
Now, the traditional rounding method in the decimal system is to take
the lower number for the digits 0, 1, 2, 3 and 4 and the higher number
for the digits 5, 6, 7, 8 and 9. So 1.4 becomes 1 and 1.5 becomes 2 if
rounded to zero digits precision.
The problem is that if the internal representation of the floating
point number is 0.2849...something instead of 0.285, the rounding
algorithm will incorrectly assume the last digit is a 4 and not a 5 and
then return the lower number instead of the higher one.
Now one may ask why does 1.285 work and 0.285 doesn't if both are not
representable using finite digits in the binary system? This is due to
the way the rounding algorithm works: It first multiplies the numbers by
10 to the power of the places of precision (with 2 places precision, it
multiplies them with 100) and then it rounds to the next integer. Now,
if you have a look at the representation of 1.285 * 100 and 0.285 * 100,
you will get:
128.5000
28.49644729
Of course, one might argue that 28.5 is infact representable as a
floating point number - sure, but that does not matter the computer
always calculates with floating point numbers - so in the case of 128.5
the computer actually makes two errors due to decreased precision: The
first is not being able to correctly represent 1.285 and the second is
to accidentally compensate that error due to lack of precision. With
0.285, only the first error happens and so the result is incorrect.
So that's the reason why round() does not always work as expected. Now
there are two possibilities to solve this:
1) Don't give a shit about the error and simply calculate as before.
This is what the Linux implementation of the C99 function round(3) does
(and probably the C99 standard itself, but I don't know since I haven't
looked into it).
2) Try to correct the error: This is what the PHP_ROUND_FUZZ code is
fore. A bit of background: A round() function is available in C only
from C99 onwards - to ensure compability, PHP does rounding manually
using floor/ceil. In order to keep this post short, I'll just look at
positive numbers. So the current implementation of PHP's round() as
found in ext/standard/math.c does the following:
#define PHP_ROUND_WITH_FUZZ(val, places) { \
double tmp_val=val, f = pow(10.0, (double) places); \
tmp_val *= f; \
if (tmp_val >= 0.0) { \
tmp_val = floor(tmp_val + PHP_ROUND_FUZZ); \
} else {\
tmp_val = ceil(tmp_val - PHP_ROUND_FUZZ); \
} \
tmp_val /= f; \
val = !zend_isnan(tmp_val) ? tmp_val : val; \
} \
Let's assume for a moment that PHP_ROUND_FUZZ is 0.5, then the code is
obvious: 0.5 is added to the number and then floor() is called. That
will produce the identical result for positive numbers as round() does.
Now, a possible correction for the rounding error is setting
PHP_ROUND_FUZZ to 0.501 - the last digit 1 does just enough to
make round() work as expected.
Obviously, this code has one minor drawback: If one wants to round
0.499 to 0 places precision, the "corrected" function will
incorrectly return 1
#42848 [Opn->Asn]: Status: header incorrect under FastCGI
ID: 42848
Updated by: [EMAIL PROTECTED]
Reported By: madcamel at gmail dot com
-Status: Open
+Status: Assigned
Bug Type: CGI related
Operating System: Linux, FreeBSD
PHP Version: 5.2.4
-Assigned To:
+Assigned To: dmitry
New Comment:
Dmitry, any ideas about this?
Previous Comments:
[2007-10-23 16:25:33] madcamel at gmail dot com
Nope, still the same behavior.
I notice there is rudimentary handling for adding descriptions to
status codes in isapi/php5isapi.c:270
Could something like this but perhaps a little more robust be added to
the cgi/fcgi sapi perhaps?
[2007-10-22 08:54:55] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
[2007-10-04 04:47:05] madcamel at gmail dot com
404 behavior:
$ php-fcgi does-not-exist.php
Status: 404
Content-type: text/html
Expected: "Status: 404 Not Found"
[2007-10-04 04:41:30] madcamel at gmail dot com
Description:
When PHP is used as a FastCGI it outputs incorrect Status: headers.
For example, a redirect triggered by header("Location: http://x.com/";)
returns "Status: 302", not "Status: 302 Moved Temporarily" as is
explicitly required by the FastCGI specification.
This leads to most web servers returning "HTTP/1.1 302" instead of
"HTTP/1.1 302 Moved Temporarily", thereby breaking some very picky
browsers.
This problem also also occurs with 404 if a PHP file could not be
found, and I'm sure every other type of "Special" response. This makes
it different than bug 41738.
Related bugs:
http://bugs.php.net/bug.php?id=41378
http://bugs.php.net/bug.php?id=31065
http://bugs.php.net/bug.php?id=36705
Reproduce code:
---
--- Test 1
http://www.google.com/";);
?>
$ php-fcgi fun.php
Status: 302
Location: http://www.google.com/
Content-type: text/html
--- Test 2
http://www.google.com/";);
?>
$ php-fcgi fun.php
Status: 302
Location: http://www.google.com/
Content-type: text/html
--- Test 3
http://www.google.com/";);
?>
$ php-fcgi fun.php
Status: 302
Status: 302 Moved Temporarily
Location: http://www.google.com/
Content-type: text/html
Note the duplicate "Status:" headers, which is dissallowed by the
FastCGI spec.
--
Edit this bug report at http://bugs.php.net/?id=42848&edit=1
#43035 [Opn->Fbk]: Tests affected by system php.ini file
ID: 43035 Updated by: [EMAIL PROTECTED] Reported By: chad at herballure dot com -Status: Open +Status: Feedback Bug Type: *General Issues Operating System: Linux PHP Version: 5.2.5RC1 New Comment: It's intentional to use system php.ini to find possible issues with different settings being something else than default. To help us fix the tests or some bug in PHP you need to come up with a diff against the stock php.ini-dist / php.ini-recommended (depending what you used as base for your php.ini). Previous Comments: [2007-10-19 14:04:59] [EMAIL PROTECTED] The tests are still broken, but not because of the reason that you mention. All tests should run under *any* environment - although some of the settings we force to avoid some of the things you mention. [2007-10-19 12:37:43] chad at herballure dot com Description: ignore_repeated_errors, error_reporting, and display_errors in the system php.ini file can interfere with testing, causing bogus failure reports. Tests should run in a known-good environment, not under the system's /usr/local/lib/php.ini settings. 388 additional failures can be provoked in 5.2.5RC1 this way. This wastes the time of both PHP-QA (who get bogus reports) and users (who have to hide the system php.ini by hand and replace it after running tests--if they remember). -- Edit this bug report at http://bugs.php.net/?id=43035&edit=1
#43144 [Opn->Fbk]: configure fails checking for c++ compiler
ID: 43144 Updated by: [EMAIL PROTECTED] Reported By: babt at us dot ibm dot com -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Mac OS X 10.5 PHP Version: 5.2.4 New Comment: You have some 3rd party extensions added by yourself in the build or what? There aren't any C++ extensions in the PHP core, AFAIK. Previous Comments: [2007-10-30 18:12:39] babt at us dot ibm dot com Here's the configure line used... ./configure --prefix=/usr/local/php5 --with-config-file- path=/usr/local/php5/lib --with-mysql=/usr/local/mysql --with-pdo- mysql=/usr/local/mysql --with-apxs2 --with-pcre-regex --with-iconv -- with-openssl --with-zlib --with-mysqli=/usr/local/mysql/bin/mysql_config --with-libxml --with-xsl --with-xmlrpc --enable-wddx --with-curl -- enable-exit --enable-soap --enable-ftp --enable-calendar --enable-dbx -- enable-sockets --with-bz2 --enable-dbase --enable-fastcgi --enable- mbstring --with-pdflib --with-mysql-sock=/tmp/mysql.sock [2007-10-30 17:13:25] [EMAIL PROTECTED] What configure line did you use? [2007-10-30 14:32:54] babt at us dot ibm dot com Description: When running configure, process fails to properly detect c++ due to previous failure to remove a directory. Below is the stream from the script. Configuring libtool checking build system type... i686-apple-darwin9.0.0 checking for ld used by gcc... /usr/libexec/gcc/i686-apple- darwin9/4.0.1/ld checking if the linker (/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld) is GNU ld... no checking for /usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking how to recognise dependent libraries... pass_all checking for object suffix... o checking for executable suffix... rm: conftest.dSYM: is a directory .dSYM checking for c++... c++ checking whether the C++ compiler (c++ ) works... no configure: error: installation or configuration problem: C++ compiler cannot create executables. Reproduce code: --- Plain vanilla OS X 10.5 Leopard build with Xcode 3.0 tools installed. Expected result: Configuring libtool checking build system type... i686-apple-darwin9.0.0 checking for ld used by /Developer/usr/bin/cc... /Developer/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld checking if the linker (/Developer/usr/libexec/gcc/i686-apple- darwin9/4.0.1/ld) is GNU ld... no checking for /Developer/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld option to reload object files... -r checking for BSD-compatible nm... /Developer/usr/bin/nm -p checking how to recognise dependent libraries... pass_all checking for object suffix... o checking for executable suffix... .dSYM checking for c++... c++ checking whether the C++ compiler (c++ ) works... yes Actual result: -- As in description. Workaround - Change configure script to use 'rm -rf' during the check for the executable suffix. -- Edit this bug report at http://bugs.php.net/?id=43144&edit=1
#43147 [Opn->Fbk]: Random "PHP Fatal error: Maximum execution time of 60 seconds exceeded"
ID: 43147
Updated by: [EMAIL PROTECTED]
Reported By: marquinhocb at hotmail dot com
-Status: Open
+Status: Feedback
Bug Type: Performance problem
Operating System: Windows Server 2003 R2 x64
PHP Version: 5.2.4
New Comment:
It's pretty normal that sometimes things take time, especially with
high load if the scripts are "heavy". Have you tried increasing the
max_execution time in your php.ini? Also, you didn't give any
information about your setup, like what webserver you're using, whether
you use FastCGI/CGI or some module?
Previous Comments:
[2007-10-30 17:52:15] marquinhocb at hotmail dot com
Description:
I can only get this to happen on a production server. It may have to
do with the server load. I have the exact same setup on my local
machine, never experienced this problem.
Server is a Dual-Processor Xeon Dual Core (4 cores in total).
I am willing to debug and help in any way necessary, I am a
professional software engineer.
After getting these errors, I made my own extension with extended
debugging information to help trace the problem.
Reproduce code:
---
Nothing special about the code causing the stall, as you can see:
windowmanager.class.php:
304: if (! $this->hasFooter)
305:print(""); //content
menumanager.class.php:
81: else if ((count ($j->subItems) > 0) || ($j->forceSub))
82: {
83: print("menuBarVar}.MenuItemMouseover(event,
'{$j->id}');\">");
Expected result:
The stall always seems to be on a print(), and obviously this should
not be a stalling or very intensive function.
Actual result:
--
[30-Oct-2007 09:22:48] PHP Fatal error: Maximum execution time of 60
seconds exceeded
End()
End()
End()
in D:\yuniti\includes\windowmanager.class.php [/index.php] on line
305
[30-Oct-2007 09:39:24] PHP Fatal error: Maximum execution time of 60
seconds exceeded
InternalOutputItem()
InternalOutputItem()
InternalOutputSubItems()
Output()
Output()
Output()
in D:\yuniti\includes\menumanager.class.php [/user.php] on line 83
[30-Oct-2007 09:42:02] PHP Fatal error: Maximum execution time of 60
seconds exceeded
InternalOutputItem()
InternalOutputItem()
InternalOutputSubItems()
Output()
Output()
Output()
in D:\yuniti\includes\menumanager.class.php [/user.php] on line 83
[30-Oct-2007 09:47:08] PHP Fatal error: Maximum execution time of 60
seconds exceeded
End()
End()
End()
in D:\yuniti\includes\windowmanager.class.php [/index.php] on line 305
--
Edit this bug report at http://bugs.php.net/?id=43147&edit=1
#39580 [Com]: Incorrect Error in Configure PDO
ID: 39580 Comment by: jesse at mcmds dot com Reported By: drh1 at cec dot wustl dot edu Status: No Feedback Bug Type: Compile Failure Operating System: Mac OS 10.4.8 PHP Version: 5.2CVS-2006-11-22 Assigned To: wez New Comment: Might also be helpful to note that I did not have any difficulty compiling 5.1.4 with shared PDO on this same machine. Unfortunately we are running into an unrelated bug on our dev server that was fixed in 5.2.0, so I needed to upgrade. Previous Comments: [2007-10-30 21:47:15] jesse at mcmds dot com Yes, the problem still occurs in 5.2.4. checking whether to enable PDO support... yes, shared configure: error: Due to the way that loadable modules work on OSX/Darwin, you need to compile the PDO package statically into the PHP core. Please follow the instructions at: http://netevil.org/node.php?nid=202 for more detail on this issue. x1:/vol/build/php-5.2.4 root# [2007-09-06 11:12:36] [EMAIL PROTECTED] So we let this rot. [2007-09-05 14:22:05] drh1 at cec dot wustl dot edu I no longer have a mac, so I cannot provide feedback. [2007-09-05 13:58:33] [EMAIL PROTECTED] Fix version field. Does this problem exist with PHP 5.2.4? Note: This report was lost due to invalid version number. First char in the version field is supposed to be the major version number!! [2006-11-22 13:48:50] drh1 at cec dot wustl dot edu Since I apparently tested 1 minute before CVS updated, php5.2-200611221330 doesn't work either . 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/39580 -- Edit this bug report at http://bugs.php.net/?id=39580&edit=1
#39580 [Com]: Incorrect Error in Configure PDO
ID: 39580 Comment by: jesse at mcmds dot com Reported By: drh1 at cec dot wustl dot edu Status: No Feedback Bug Type: Compile Failure Operating System: Mac OS 10.4.8 PHP Version: 5.2CVS-2006-11-22 Assigned To: wez New Comment: Yes, the problem still occurs in 5.2.4. checking whether to enable PDO support... yes, shared configure: error: Due to the way that loadable modules work on OSX/Darwin, you need to compile the PDO package statically into the PHP core. Please follow the instructions at: http://netevil.org/node.php?nid=202 for more detail on this issue. x1:/vol/build/php-5.2.4 root# Previous Comments: [2007-09-06 11:12:36] [EMAIL PROTECTED] So we let this rot. [2007-09-05 14:22:05] drh1 at cec dot wustl dot edu I no longer have a mac, so I cannot provide feedback. [2007-09-05 13:58:33] [EMAIL PROTECTED] Fix version field. Does this problem exist with PHP 5.2.4? Note: This report was lost due to invalid version number. First char in the version field is supposed to be the major version number!! [2006-11-22 13:48:50] drh1 at cec dot wustl dot edu Since I apparently tested 1 minute before CVS updated, php5.2-200611221330 doesn't work either . [2006-11-22 13:40:35] drh1 at cec dot wustl dot edu This error still occurs in php5.2-200611221130 . 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/39580 -- Edit this bug report at http://bugs.php.net/?id=39580&edit=1
#43148 [Com]: filesize and unicode filenames
ID: 43148
Comment by: carsten_sttgt at gmx dot de
Reported By: banu_daniel1 at yahoo dot com
Status: Open
Bug Type: Filesystem function related
Operating System: windows xp 32 bits
PHP Version: 5.2.4
New Comment:
The filesystem functions have no problem with unicode (utf-8). But you
must use a unicode char, and not a HTML entity which are represent a
unicode char.
| $size= sprintf("%u",
| filesize(html_entity_decode($eps["FNAME"][$f],
| ENT_COMPAT, 'UTF-8')
| )
| );
Regards,
Carsten
Previous Comments:
[2007-10-30 18:25:36] banu_daniel1 at yahoo dot com
Description:
it seems that this bug was reported and it says there "Marking as
closed... also please try a newer version. " but the problem is still
there even on windows xp so this is the problem
filesize function dose not work with filenames with unicode
characters.
on linux version i don't have this problem.
Reproduce code:
---
$size=sprintf("%u", filesize($eps["FNAME"][$f])
Actual result:
--
Warning: filesize() [function.filesize]: stat failed for
E:\Emilya・Chad.mpg in C:\WWW\files.php on line 45
Just an example.
--
Edit this bug report at http://bugs.php.net/?id=43148&edit=1
#43151 [NEW]: [peer_certificate_chain] => HTTP/1.1 200 OK
From: p dot vanbrouwershaven at networking4all dot com Operating system: Linux 2.6.8-2-686 #1 Tue Au PHP version: 5.2.4 PHP Bug Type: OpenSSL related Bug description: [peer_certificate_chain] => HTTP/1.1 200 OK Description: peer_certificate_chain returns "HTTP/1.1 200 OK" Reproduce code: --- $opts = array( 'ssl' => array( 'capture_peer_cert' => true, 'peer_certificate' => true, 'capture_peer_cert_chain' => true ) ); $context = stream_context_create($opts); $fp = fopen($url, 'rb', false, $context); $meta = stream_get_meta_data($fp); $options = stream_context_get_options($fp); fclose($fp); print_r($options); Expected result: [ssl] => Array ( [capture_peer_cert] => 1 [peer_certificate] => Resource id #28 [capture_peer_cert_chain] => 1 [peer_certificate_chain] => Resource id #** ) Actual result: -- [ssl] => Array ( [capture_peer_cert] => 1 [peer_certificate] => Resource id #28 [capture_peer_cert_chain] => 1 [peer_certificate_chain] => HTTP/1.1 200 OK ) -- Edit bug report at http://bugs.php.net/?id=43151&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43151&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43151&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43151&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43151&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43151&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43151&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43151&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43151&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43151&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43151&r=support Expected behavior:http://bugs.php.net/fix.php?id=43151&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43151&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43151&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43151&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43151&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43151&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43151&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43151&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43151&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43151&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43151&r=mysqlcfg
#40735 [Opn]: stream_select returns 0 for php > 5.1.6
ID: 40735
User updated by: rodricg at sellingsource dot com
Reported By: rodricg at sellingsource dot com
Status: Open
Bug Type: Streams related
Operating System: x86_64 GNU/Linux
PHP Version: 5.2.3
New Comment:
This was sent to me via email so I'm posting it here in the interest
of collecting all relevant information.
> I have the same weird behaviour on x86_64 but with gcc-3.4.6-8
(CentOS 4.5)
> and PHP 5.2.4
>
> P.S. I havent tested yet if it's related but I have FD_SETSIZE
macro in
> /usr/include/* set to 16384 (instead of original 1024). Though
> stream_select in php4 has no problems.
>
> Well, I started to debug the code and noticed that system's
select()
> returns correct return value but this value will be later
overwritten?? and
> PHP script gets always wrong result.
>
> The cure for me was to replace an variable type from 'int'
to 'long' in
> function stream_array_from_fd_set:
>
> --- streamsfuncs.c.orig 2007-10-09 16:21:30.0 +0300
> +++ streamsfuncs.c 2007-10-09 16:21:41.0 +0300
> @@ -608,7 +608,7 @@
> zval **elem, **dest_elem;
> php_stream *stream;
> HashTable *new_hash;
> - int this_fd, ret = 0;
> + long this_fd, ret = 0;
>
> if (Z_TYPE_P(stream_array) != IS_ARRAY) {
> return 0;
>
> regards,
> Margus Kaidja
Previous Comments:
[2007-10-29 07:15:48] patrick at chegg dot com
I'm also seeing this problem... the code from rodricg produces the same
(incorrect) result, returning Selected: 0. I was testing my own
application which is how I found the bug, but rodricg's test script
provides the same result. I do not have my original script, however I
had a working version and when I moved everything to a class the
incorrect return value became a problem, leading me to believe this is a
PHP bug.
This is also an x86_64 machine with openssl and curl.
$ php -v
PHP 5.2.3 (cli) (built: Oct 29 2007 00:07:41)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-mpfr --enable-checking=release x86_64-linux-gnu
Thread model: posix
gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
PHP configure:
./configure --with-apxs2=/usr/local/apache/bin/apxs
--with-config-file-path=/etc --with-bz2 --enable-calendar --with-curl
--with-curlwrappers --with-inifile --enable-exif --enable-ftp --with-gd
--enable-json --with-mysql --with-mysqli --with-pdo-mysql --with-mssql
--enable-soap --enable-sockets --with-pear --with-xsl --with-zlib
--with-openssl --enable-pcntl
Send me an email, I will provide a test account as needed to those with
a @php.net email. Recompiling with -O1 did NOT solve the problem for me.
[2007-08-15 08:26:55] [EMAIL PROTECTED]
Nobody else is able to reproduce this on several different (or same)
types of systems -> bogus. (reopen if you can reproduce this on 2
different machines using Fedorda..I can't. :)
[2007-08-03 22:42:15] rodricg at sellingsource dot com
Just verified that I still see the same behavior with:
php-5.2.3
openssl-0.9.8e
gcc-4.1.2
I am using the same test script as before.
Changing it to use:
-O1 --with-openssl
*or*
-O2 --without-openssl
gives the correct behavior.
[2007-08-03 21:12:20] blade at debian dot org
It is even worse on the current Debian Sid, with 5.2.3-1+b1. It returns
0 and the modified arrays contain just nothing, but there is obviosly
data available there. Tested with slightly adapted code from
http://netevil.org/blog/2005/may/guru-multiplexing .
[2007-03-16 23:06:09] [EMAIL PROTECTED]
I have a x86(-32) gentoo box with the same gcc version as you and your
script works perfectly. anyway if this is a compiler error, you need
report it to gentoo guys, that will then investigate to see if it is
caused by their patchset or not.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/40735
--
Edit this bug report at http://bugs.php.net/?id=40735&edit=1
#43138 [Opn]: Allow keywords self and parent in dynamic class references
ID: 43138 Updated by: [EMAIL PROTECTED] -Summary: self and parent in variable Reported By: felipensp at gmail dot com Status: Open -Bug Type: Scripting Engine problem +Bug Type: Feature/Change Request Operating System: Linux -PHP Version: 5.3CVS-2007-10-30 (snap) +PHP Version: 5.3 -Assigned To: +Assigned To: colder New Comment: This behavior is consistent with the old one: new $classname is also available in version prior to 5.3, and works the same way. self and parent are keywords, not real class names. Hence I reclassify this report as a feature request. Previous Comments: [2007-10-30 11:36:02] felipensp at gmail dot com Description: 'self' and 'parent' don't are evaluated when calling static member/method with class name in variables. Reproduce code: --- http://bugs.php.net/?id=43138&edit=1
#43150 [NEW]: stack overflow in php5ts.dll
From: jeff dot orrok at reedbusiness dot com
Operating system: windows xp sp2
PHP version: 5.2.4
PHP Bug Type: Reproducible crash
Bug description: stack overflow in php5ts.dll
Description:
Invoking a non-existent method on a SOAP service crashes apache. Although
PEAR's SOAP module is involved in the problem, I thought y'all should know
about it in case there was something you could do to make your code more
robust.
C:\wamp\logs\apache_error.log:
[Tue Oct 30 11:58:42 2007] [notice] Parent: child process exited with
status 3221225477 -- Restarting.
Analysys Summary from Debug Diagnostic Tool:
In
httpd__PID__5256__Date__10_29_2007__Time_07_05_58PM__48__Second_Chance_Exception_C0FD.dmp
the assembly instruction at php5ts!xbuf_format_converter+5b in
C:\wamp\Apache2\bin\php5ts.dll from The PHP Group has caused a stack
overflow exception (0xC0FD) when trying to write to memory location
0x01b82ffc on thread 15
Reproduce code:
---
This is merely to demonstrate what I'm doing. I was hoping it might be
reproducible with any kind of "hello world" service. I am behind on my
deadline and need to get caught up before I can spend a lot of time on
this. I will try to pare down the amount of code to the smallest necessary
to reproduce, if it turns out to be a very specific circumstance.
require_once ('SOAP/Client.php'); // pear soap-0.11.0
define('RBI_COMMON_AUTH_WS_URL',
'http://localhost/WebServices/AuthenticationWS/service.php?wsdl');
define('RBICA_APP', 'BLOG');
define('RBICA_APP_TOKEN_ID', 'PERM_BLOG');
$wsdl_ca = new SOAP_WSDL (RBI_COMMON_AUTH_WS_URL,array('timeout' => 30));
$client_ca = $wsdl_ca->getProxy();
$wpUserId = $login->ID;
$result = $client_ca->GetMasterID(RBICA_APP_TOKEN_ID, RBICA_APP,
(integer)$wpUserId); // GetMasterID happens to not exist in the current
version of the service.
Expected result:
(be automatically logged in to WordPress via our in-house common
authentication service)
Actual result:
--
Report for
httpd__PID__5256__Date__10_29_2007__Time_07_05_58PM__48__Second_Chance_Exception_C0FD.dmp
Type of Analysis Performed Crash Analysis
Machine Name HRAORROCKJ1D
Operating System Windows XP Service Pack 2
Number Of Processors 2
Process ID 5256
Process Image C:\wamp\Apache2\bin\httpd.exe
System Up-Time 10 day(s) 08:39:57
Process Up-Time 00:03:23
Thread 15 - System ID 784
Entry point msvcrt!_endthreadex+3a
Create time 10/29/2007 7:02:35 PM
Time spent in user mode 0 Days 0:0:0.500
Time spent in kernel mode 0 Days 0:0:0.62
Function Arg 1 Arg 2 Arg 3 Source
php5ts!xbuf_format_converter+5b 01b83280 00a359ac 01b8332c
php5ts!vspprintf+29 01b832b8 0400 00a359ac
php5ts!php_error_cb+3a 0800 07da1180 015f
php5ts!zend_error+43e 0800 00a359ac 0079ca49
php5ts!zif_is_a+f 0002 08f9a0f0
php5ts!zend_do_fcall_common_helper_SPEC+7d9 01b833b8 05cab000
07dd7fd8
php5ts!ZEND_DO_FCALL_SPEC_CONST_HANDLER+e5 05cab000
08f96944
php5ts!execute+1c5 07d95490 05cab000 05cab000
php5ts!zend_do_fcall_common_helper_SPEC+8f8 01b83460 05cab000
0079c1e5
php5ts!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER+15 01b83460 05cab000
08f94b84
php5ts!execute+1c5 07dcf3e8 05cab000 05cab000
... followed by hundreds of lines similar to the following:
php5ts!zend_do_fcall_common_helper_SPEC+8f8 01b835b0 05cab000
0079c1e5
php5ts!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER+15 01b835b0 05cab000
08f8ea8c
php5ts!execute+1c5 07dcf3e8 05cab000 05cab000
... followed by:
php5ts!zend_do_fcall_common_helper_SPEC+8f8 01bbfbb0 05cab000
0079c1e5
php5ts!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER+15 01bbfbb0 05cab000
05cab000
php5ts!execute+1c5 07d7e2e0 05cab000
php5ts!zend_execute_scripts+107 0008 05cab000
php5ts!php_execute_script+20d 01bbfea0 05cab000 0005
php5apache2_2!php_handler+5cd 05d40e70 0074c4c0 05d40e70
libhttpd!ap_run_handler+21 05d40e70 05d40e70 05d40e70
libhttpd!ap_invoke_handler+ae 05d3e128 01bbff38
libhttpd!ap_die+24e 05d40e70 0068e510
libhttpd!ap_get_request_note+1c6c 05d3e128 05d3e128 05d3e128
libhttpd!ap_run_process_connection+21 05d3e128 00716300
01bbff80
libhttpd!ap_process_connection+33 05d3e128 05cb9050
libhttpd!ap_regkey_value_remove+c0c 05d3e120 00e10050
msvcrt!_endthreadex+a9 01018b08 00e10050
kernel32!BaseThreadStart+37 77c3a341 01018b08
PHP5TS!XBUF_FORMAT_CONVERTER+5BIn
httpd__PID__5256__Date__10_29_2007__Time_07_05_58PM__48__Second_Chance_Except
#43149 [NEW]: Problem with abstract functions and classes
From: henrik at bonest dot dk
Operating system: Windows XP
PHP version: 5.2.4
PHP Bug Type: Class/Object related
Bug description: Problem with abstract functions and classes
Description:
An abstract class should hold one abstract methods.
The class that implements it, may not be declared abstract, but this
simple structure does not give the results expected
Reproduce code:
---
abstract class bizView {
abstract public function getHTML();
}
abstract class bizViewFront extends bizView
{
abstract public function getHTML();
public function somethingelse() {
echo "Something";
}
}
class bizViewOutput extends bizViewFront
{
public function getHTML() {
echo "HTML";
}
}
$test = new bizViewOutput();
$test->getHTML();
Expected result:
I would expect the text "HTML" to be printed, because the getHTML function
is implemented in the child class but declared abstract in the base
abstract classes.
This is a common OOP practice.
Actual result:
--
Fatal error: Can't inherit abstract function bizView::getHTML()
(previously declared abstract in bizViewFront)
--
Edit bug report at http://bugs.php.net/?id=43149&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43149&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43149&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43149&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43149&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43149&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43149&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43149&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43149&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43149&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43149&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43149&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43149&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43149&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43149&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43149&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43149&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43149&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43149&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43149&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43149&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43149&r=mysqlcfg
#43148 [NEW]: filesize and unicode filenames
From: banu_daniel1 at yahoo dot com
Operating system: windows xp 32 bits
PHP version: 5.2.4
PHP Bug Type: Filesystem function related
Bug description: filesize and unicode filenames
Description:
it seems that this bug was reported and it says there "Marking as
closed... also please try a newer version. " but the problem is still there
even on windows xp so this is the problem
filesize function dose not work with filenames with unicode characters.
on linux version i don't have this problem.
Reproduce code:
---
$size=sprintf("%u", filesize($eps["FNAME"][$f])
Actual result:
--
Warning: filesize() [function.filesize]: stat failed for
E:\Emilya・Chad.mpg in C:\WWW\files.php on line 45
Just an example.
--
Edit bug report at http://bugs.php.net/?id=43148&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43148&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43148&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43148&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43148&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43148&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43148&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43148&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43148&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43148&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43148&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43148&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43148&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43148&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43148&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43148&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43148&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43148&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43148&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43148&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43148&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43148&r=mysqlcfg
#43144 [Fbk->Opn]: configure fails checking for c++ compiler
ID: 43144 User updated by: babt at us dot ibm dot com Reported By: babt at us dot ibm dot com -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Mac OS X 10.5 PHP Version: 5.2.4 New Comment: Here's the configure line used... ./configure --prefix=/usr/local/php5 --with-config-file- path=/usr/local/php5/lib --with-mysql=/usr/local/mysql --with-pdo- mysql=/usr/local/mysql --with-apxs2 --with-pcre-regex --with-iconv -- with-openssl --with-zlib --with-mysqli=/usr/local/mysql/bin/mysql_config --with-libxml --with-xsl --with-xmlrpc --enable-wddx --with-curl -- enable-exit --enable-soap --enable-ftp --enable-calendar --enable-dbx -- enable-sockets --with-bz2 --enable-dbase --enable-fastcgi --enable- mbstring --with-pdflib --with-mysql-sock=/tmp/mysql.sock Previous Comments: [2007-10-30 17:13:25] [EMAIL PROTECTED] What configure line did you use? [2007-10-30 14:32:54] babt at us dot ibm dot com Description: When running configure, process fails to properly detect c++ due to previous failure to remove a directory. Below is the stream from the script. Configuring libtool checking build system type... i686-apple-darwin9.0.0 checking for ld used by gcc... /usr/libexec/gcc/i686-apple- darwin9/4.0.1/ld checking if the linker (/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld) is GNU ld... no checking for /usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking how to recognise dependent libraries... pass_all checking for object suffix... o checking for executable suffix... rm: conftest.dSYM: is a directory .dSYM checking for c++... c++ checking whether the C++ compiler (c++ ) works... no configure: error: installation or configuration problem: C++ compiler cannot create executables. Reproduce code: --- Plain vanilla OS X 10.5 Leopard build with Xcode 3.0 tools installed. Expected result: Configuring libtool checking build system type... i686-apple-darwin9.0.0 checking for ld used by /Developer/usr/bin/cc... /Developer/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld checking if the linker (/Developer/usr/libexec/gcc/i686-apple- darwin9/4.0.1/ld) is GNU ld... no checking for /Developer/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld option to reload object files... -r checking for BSD-compatible nm... /Developer/usr/bin/nm -p checking how to recognise dependent libraries... pass_all checking for object suffix... o checking for executable suffix... .dSYM checking for c++... c++ checking whether the C++ compiler (c++ ) works... yes Actual result: -- As in description. Workaround - Change configure script to use 'rm -rf' during the check for the executable suffix. -- Edit this bug report at http://bugs.php.net/?id=43144&edit=1
#43147 [NEW]: Random "PHP Fatal error: Maximum execution time of 60 seconds exceeded"
From: marquinhocb at hotmail dot com
Operating system: Windows Server 2003 R2 x64
PHP version: 5.2.4
PHP Bug Type: Performance problem
Bug description: Random "PHP Fatal error: Maximum execution time of 60
seconds exceeded"
Description:
I can only get this to happen on a production server. It may have to do
with the server load. I have the exact same setup on my local machine,
never experienced this problem.
Server is a Dual-Processor Xeon Dual Core (4 cores in total).
I am willing to debug and help in any way necessary, I am a professional
software engineer.
After getting these errors, I made my own extension with extended
debugging information to help trace the problem.
Reproduce code:
---
Nothing special about the code causing the stall, as you can see:
windowmanager.class.php:
304: if (! $this->hasFooter)
305:print(""); //content
menumanager.class.php:
81: else if ((count ($j->subItems) > 0) || ($j->forceSub))
82: {
83: print("menuBarVar}.MenuItemMouseover(event,
'{$j->id}');\">");
Expected result:
The stall always seems to be on a print(), and obviously this should not
be a stalling or very intensive function.
Actual result:
--
[30-Oct-2007 09:22:48] PHP Fatal error: Maximum execution time of 60
seconds exceeded
End()
End()
End()
in D:\yuniti\includes\windowmanager.class.php [/index.php] on line 305
[30-Oct-2007 09:39:24] PHP Fatal error: Maximum execution time of 60
seconds exceeded
InternalOutputItem()
InternalOutputItem()
InternalOutputSubItems()
Output()
Output()
Output()
in D:\yuniti\includes\menumanager.class.php [/user.php] on line 83
[30-Oct-2007 09:42:02] PHP Fatal error: Maximum execution time of 60
seconds exceeded
InternalOutputItem()
InternalOutputItem()
InternalOutputSubItems()
Output()
Output()
Output()
in D:\yuniti\includes\menumanager.class.php [/user.php] on line 83
[30-Oct-2007 09:47:08] PHP Fatal error: Maximum execution time of 60
seconds exceeded
End()
End()
End()
in D:\yuniti\includes\windowmanager.class.php [/index.php] on line 305
--
Edit bug report at http://bugs.php.net/?id=43147&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43147&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43147&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43147&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43147&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43147&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43147&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43147&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43147&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43147&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43147&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43147&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43147&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43147&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43147&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43147&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43147&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43147&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43147&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43147&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43147&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43147&r=mysqlcfg
#43132 [Com]: Date returned from exec command is formatted
ID: 43132
Comment by: b_ulrich at t-online dot de
Reported By: jpozzoli at yahoo dot com
Status: Feedback
Bug Type: CGI related
Operating System: Debian Linux 2.6.18-5-686
PHP Version: 5.2.0
New Comment:
This isn't a Bug.
If you take a look at the documentation for who you will find:
Time stamps are listed according to the time zone rules specified by
the `TZ' environment variable, or by the system default rules if `TZ'
is not set. *Note Specifying the Time Zone with `TZ': (libc)TZ
Variable.
It seems that the environment of the user wich runs the Apache is
different from the environment of your putty user...
Previous Comments:
[2007-10-30 17:12:18] [EMAIL PROTECTED]
Yes, but you're using an unsupported PHP version. We only support the
non-patched ones you can get as sources here at php.net. Some distros
patch their PHP binaries (and often badly) so..
[2007-10-30 16:03:29] jpozzoli at yahoo dot com
I'll get the CVS, but just for your reference, here's a composite of
several screens showing this "error", with the actual PHP code in the
box to the right.
http://www.flipnut.com/php-bug-43132.jpg
[2007-10-30 11:03:41] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
I can't reproduce this.
[2007-10-29 19:57:00] jpozzoli at yahoo dot com
Description:
This is on Debian PHP version 5.2.0-8+etch7 running on Apache/2.2.3
When trying to get the last reboot date of a linux server, from the
command line I run "who -b". More precisely, I run "who -b|awk \'{print
$3" "$4}\'" which, on the CLI, returns "2007-10-18 04:45". When I run
the PHP command echo exec('who -b|awk \'{print $3" "$4}\''); I get the
following result: Oct 18
Obviously, this has been formatted by PHP.
To make sure of this, I tried this:
$rebootdate = strftime("%m-%d-%Y %I:%M%p",
strtotime($rebootdateexec));
This get's closer. It outputs "10-18-2007 12:00AM". So it got the date
but missed the time.
Reproduce code:
---
$rebootdateexec = exec('who -b|awk \'{print $3" "$4}\'');
echo $rebootdateexec;
$rebootdate = strftime("%m-%d-%Y %I:%M%p",
strtotime($rebootdateexec));
echo $rebootdate;
Expected result:
$rebootdateexec = 2007-10-18 04:45
$rebootdate = 10-18-2007 04:45AM
Actual result:
--
$rebootdateexec = Oct 18
$rebootdate = 10-18-2007 12:00AM
--
Edit this bug report at http://bugs.php.net/?id=43132&edit=1
#42862 [Opn]: IMAP toolkit crash: rfc822.c legacy routine buffer, overflow
ID: 42862 Updated by: [EMAIL PROTECTED] Reported By: Maylein at ub dot uni-heidelberg dot de Status: Open Bug Type: IMAP related Operating System: Linux 2.6.22 PHP Version: 5.2.4 New Comment: Reclassified. (This is the correct place for this, it's imap related) Previous Comments: [2007-10-22 11:44:14] Maylein at ub dot uni-heidelberg dot de No one seems to care about a bug report in the category 'imap related', so I put it now in the category 'reproducible crash'. [2007-10-11 08:49:53] Maylein at ub dot uni-heidelberg dot de Please tell me, if there will be a patch for the imap-extension. It's an security issue, isn't it? If you don't plan to patch the imap extension (as I understand from the answer on Bug #40925) then you subsequently need to remove this extension. [2007-10-11 08:20:14] Maylein at ub dot uni-heidelberg dot de See also http://archives.devshed.com/forums/networking-100/new-message-writing-routines-in-imap-2005t-1639473.html [2007-10-05 07:29:33] Maylein at ub dot uni-heidelberg dot de Description: I am using the uw imap c-client-library with php-5.2.4 and apache 2.0.61 for my webmailer software TWIG. Some actions causes the httpd child to crash: httpd: IMAP toolkit crash: rfc822.c legacy routine buffer overflow See also http://bugs.php.net/bug.php?id=40925&edit=1 uw imap developers say that it is definitely a php issue which you have been denying in former bug reports. So please have a second thought on this issue. Here is the response of the uw imap developers: > PHP is calling c-client legacy RFC 822 header generation routines > that write headers into a "big enough buffer". These routines were > never intended for external use. > There is no way in the old interface to know how much space is left > in the buffer. Those routines were written in 1988 when that was > "good enough". They were left unfixed because supposedly "nobody > used them". When it became clear that people were using those > routines after all, they were replaced by routines with proper > buffer checking. > The old routine names exist as compatibility interfaces into the new > routines, but the old interface itself prevents proper checking. > ... > Let's be clear; if PHP calls these old routines, it is not just a > core dump issue; it is a security bug. The abort catches some, but > NOT all of the buffer overflows. > ... > In case it wasn't clear from the previous message, there is nothing > to fix at the c-client end. That "legacy routine buffer overflow" > is effectively the same thing as getting a SEGV from strcpy(). As > the message says, it's a detected buffer overflow. But there is > nothing that c-client can do to recover. > The fix is not to call the routine that has the buffer overflow, but > that has to be in PHP. > I'm sorry that this is bad news for you, especially as the PHP > developers seem to be unable to understand the issue (and thus are > telling you to talk to me). Actual result: -- httpd child crashes with a buffer overflow httpd: IMAP toolkit crash: rfc822.c legacy routine buffer overflow -- Edit this bug report at http://bugs.php.net/?id=42862&edit=1
#43144 [Opn->Fbk]: configure fails checking for c++ compiler
ID: 43144 Updated by: [EMAIL PROTECTED] Reported By: babt at us dot ibm dot com -Status: Open +Status: Feedback -Bug Type: *Configuration Issues +Bug Type: Compile Failure Operating System: Mac OS X 10.5 PHP Version: 5.2.4 New Comment: What configure line did you use? Previous Comments: [2007-10-30 14:32:54] babt at us dot ibm dot com Description: When running configure, process fails to properly detect c++ due to previous failure to remove a directory. Below is the stream from the script. Configuring libtool checking build system type... i686-apple-darwin9.0.0 checking for ld used by gcc... /usr/libexec/gcc/i686-apple- darwin9/4.0.1/ld checking if the linker (/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld) is GNU ld... no checking for /usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking how to recognise dependent libraries... pass_all checking for object suffix... o checking for executable suffix... rm: conftest.dSYM: is a directory .dSYM checking for c++... c++ checking whether the C++ compiler (c++ ) works... no configure: error: installation or configuration problem: C++ compiler cannot create executables. Reproduce code: --- Plain vanilla OS X 10.5 Leopard build with Xcode 3.0 tools installed. Expected result: Configuring libtool checking build system type... i686-apple-darwin9.0.0 checking for ld used by /Developer/usr/bin/cc... /Developer/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld checking if the linker (/Developer/usr/libexec/gcc/i686-apple- darwin9/4.0.1/ld) is GNU ld... no checking for /Developer/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld option to reload object files... -r checking for BSD-compatible nm... /Developer/usr/bin/nm -p checking how to recognise dependent libraries... pass_all checking for object suffix... o checking for executable suffix... .dSYM checking for c++... c++ checking whether the C++ compiler (c++ ) works... yes Actual result: -- As in description. Workaround - Change configure script to use 'rm -rf' during the check for the executable suffix. -- Edit this bug report at http://bugs.php.net/?id=43144&edit=1
#43132 [Fbk]: Date returned from exec command is formatted
ID: 43132
Updated by: [EMAIL PROTECTED]
Reported By: jpozzoli at yahoo dot com
Status: Feedback
Bug Type: CGI related
Operating System: Debian Linux 2.6.18-5-686
PHP Version: 5.2.0
New Comment:
Yes, but you're using an unsupported PHP version. We only support the
non-patched ones you can get as sources here at php.net. Some distros
patch their PHP binaries (and often badly) so..
Previous Comments:
[2007-10-30 16:03:29] jpozzoli at yahoo dot com
I'll get the CVS, but just for your reference, here's a composite of
several screens showing this "error", with the actual PHP code in the
box to the right.
http://www.flipnut.com/php-bug-43132.jpg
[2007-10-30 11:03:41] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
I can't reproduce this.
[2007-10-29 19:57:00] jpozzoli at yahoo dot com
Description:
This is on Debian PHP version 5.2.0-8+etch7 running on Apache/2.2.3
When trying to get the last reboot date of a linux server, from the
command line I run "who -b". More precisely, I run "who -b|awk \'{print
$3" "$4}\'" which, on the CLI, returns "2007-10-18 04:45". When I run
the PHP command echo exec('who -b|awk \'{print $3" "$4}\''); I get the
following result: Oct 18
Obviously, this has been formatted by PHP.
To make sure of this, I tried this:
$rebootdate = strftime("%m-%d-%Y %I:%M%p",
strtotime($rebootdateexec));
This get's closer. It outputs "10-18-2007 12:00AM". So it got the date
but missed the time.
Reproduce code:
---
$rebootdateexec = exec('who -b|awk \'{print $3" "$4}\'');
echo $rebootdateexec;
$rebootdate = strftime("%m-%d-%Y %I:%M%p",
strtotime($rebootdateexec));
echo $rebootdate;
Expected result:
$rebootdateexec = 2007-10-18 04:45
$rebootdate = 10-18-2007 04:45AM
Actual result:
--
$rebootdateexec = Oct 18
$rebootdate = 10-18-2007 12:00AM
--
Edit this bug report at http://bugs.php.net/?id=43132&edit=1
#43132 [Opn->Fbk]: Date returned from exec command is formatted
ID: 43132
Updated by: [EMAIL PROTECTED]
Reported By: jpozzoli at yahoo dot com
-Status: Open
+Status: Feedback
Bug Type: CGI related
Operating System: Debian Linux 2.6.18-5-686
PHP Version: 5.2.0
Previous Comments:
[2007-10-30 16:03:29] jpozzoli at yahoo dot com
I'll get the CVS, but just for your reference, here's a composite of
several screens showing this "error", with the actual PHP code in the
box to the right.
http://www.flipnut.com/php-bug-43132.jpg
[2007-10-30 11:03:41] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
I can't reproduce this.
[2007-10-29 19:57:00] jpozzoli at yahoo dot com
Description:
This is on Debian PHP version 5.2.0-8+etch7 running on Apache/2.2.3
When trying to get the last reboot date of a linux server, from the
command line I run "who -b". More precisely, I run "who -b|awk \'{print
$3" "$4}\'" which, on the CLI, returns "2007-10-18 04:45". When I run
the PHP command echo exec('who -b|awk \'{print $3" "$4}\''); I get the
following result: Oct 18
Obviously, this has been formatted by PHP.
To make sure of this, I tried this:
$rebootdate = strftime("%m-%d-%Y %I:%M%p",
strtotime($rebootdateexec));
This get's closer. It outputs "10-18-2007 12:00AM". So it got the date
but missed the time.
Reproduce code:
---
$rebootdateexec = exec('who -b|awk \'{print $3" "$4}\'');
echo $rebootdateexec;
$rebootdate = strftime("%m-%d-%Y %I:%M%p",
strtotime($rebootdateexec));
echo $rebootdate;
Expected result:
$rebootdateexec = 2007-10-18 04:45
$rebootdate = 10-18-2007 04:45AM
Actual result:
--
$rebootdateexec = Oct 18
$rebootdate = 10-18-2007 12:00AM
--
Edit this bug report at http://bugs.php.net/?id=43132&edit=1
#43146 [Opn->Bgs]: configure claims that --with-mnogosearch is unknown..
ID: 43146 Updated by: [EMAIL PROTECTED] Reported By: stephen at thelonecoder dot com -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: Debian 40r1 PHP Version: 5.2.4 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 "Note: This extension has been moved to the » PECL repository and is no longer bundled with PHP as of PHP 5.1.0." http://php.net/mnogosearch Previous Comments: [2007-10-30 16:18:27] stephen at thelonecoder dot com Description: Notice: Following unknown configure options were used: --with-mnogosearch I am assuming that mnogosearch is still a supported extension in PHP 5. Sorry if this is not a bug, but everywhere I look tells me that this should work, so I am not sure where else to go. -- Edit this bug report at http://bugs.php.net/?id=43146&edit=1
#43141 [Opn->WFx]: Converting $this to int
ID: 43141 Updated by: [EMAIL PROTECTED] Reported By: felipensp at gmail dot com -Status: Open +Status: Wont fix Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 5.3CVS-2007-10-30 (snap) New Comment: Yes, it's inconsistent but we won't change it (soon). Previous Comments: [2007-10-30 12:42:21] felipensp at gmail dot com Description: When try converter $this to string, one Catchable fatal error occur. $this to int, only Notice... Reproduce code: --- $this; // Odd... Notice: Undefined property: foo::$2 var_dump($this->test); // foo var_dump($this); // int(2) } } new foo; Expected result: Catchable fatal error: Object of class foo could not be converted to int Actual result: -- Notice: Object of class foo could not be converted to int in /home/felipe/public_html/bug.php on line 16 int(2) string(3) "foo" int(2) -- Edit this bug report at http://bugs.php.net/?id=43141&edit=1
#43142 [Opn->Bgs]: Call different function
ID: 43142 Updated by: [EMAIL PROTECTED] Reported By: felipensp at gmail dot com -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 5.3CVS-2007-10-30 (snap) New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Mind the 12 as length of oyur output - the actual name of the lambda function is "\0lambda_1" but your terminal/browser doesn't dispaly the null byte. Previous Comments: [2007-10-30 13:07:53] felipensp at gmail dot com Description: Return of create_function() concat. with 'foo'. But, when calling the function with the name of variable's value, only 'foo' is used... Reproduce code: --- http://bugs.php.net/?id=43142&edit=1
#43140 [Opn->Bgs]: Error in parser
ID: 43140
Updated by: [EMAIL PROTECTED]
Reported By: felipensp at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 5.3CVS-2007-10-30 (snap)
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
create_fucntion($params, $code) actually is eval("function
lambda1($params) { $code }"). In your code $params is an Array which is
being casted to a string "Array" so the full code reads like
function lambda(Array) { print1; }
where the error message is misleading but correct.
Previous Comments:
[2007-10-30 12:09:05] felipensp at gmail dot com
Description:
Parser recognize wrong the array parameter.
It see array(..) as (array).
Reproduce code:
---
$a = create_function(array(1), 'print 1;');
Expected result:
Parse error: syntax error, unexpected T_ARRAY, expecting '&' or
T_VARIABLE
Actual result:
--
Parse error: syntax error, unexpected T_ARRAY_CAST, expecting '(' in
/home/felipe/public_html/bug.php(4) : runtime-created function
--
Edit this bug report at http://bugs.php.net/?id=43140&edit=1
#43146 [NEW]: configure claims that --with-mnogosearch is unknown..
From: stephen at thelonecoder dot com Operating system: Debian 40r1 PHP version: 5.2.4 PHP Bug Type: *Configuration Issues Bug description: configure claims that --with-mnogosearch is unknown.. Description: Notice: Following unknown configure options were used: --with-mnogosearch I am assuming that mnogosearch is still a supported extension in PHP 5. Sorry if this is not a bug, but everywhere I look tells me that this should work, so I am not sure where else to go. -- Edit bug report at http://bugs.php.net/?id=43146&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43146&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43146&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43146&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43146&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43146&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43146&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43146&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43146&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43146&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43146&r=support Expected behavior:http://bugs.php.net/fix.php?id=43146&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43146&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43146&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43146&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43146&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43146&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43146&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43146&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43146&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43146&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43146&r=mysqlcfg
#43145 [NEW]: Add support for SORT_LOCALE_STRING to array_multisort() function
From: sw at veracomp dot pl Operating system: Linux / Any PHP version: 5.2.4 PHP Bug Type: Feature/Change Request Bug description: Add support for SORT_LOCALE_STRING to array_multisort() function Description: Hi, I'm writing an application that utilizes the array_multisort function. We have to sort data in polish language whitch contains non-ASCII characters. We tried to pass SORT_LOCALE_STRING to the function, but the but it produces warning: Argument #3 is an unknown sort flag We are aware that the Docs says it supports only SORT_STRING, SORT_REGULAR and SORT_NUMERIC flags, but we do need locale sorting. Please add support for SORT_LOCALE_STRING flag to this function. Thanks, in advance Szymon Wilkolazki Reproduce code: --- array_multisort($columnsArray, SORT_ASC, SORT_LOCALE_STRING, $theDataToBeSorted ); Expected result: Table sorted. Actual result: -- Warning: array_multisort() [function.array-multisort]: Argument #3 is an unknown sort flag in... Table not sorted. -- Edit bug report at http://bugs.php.net/?id=43145&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43145&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43145&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43145&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43145&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43145&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43145&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43145&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43145&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43145&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43145&r=support Expected behavior:http://bugs.php.net/fix.php?id=43145&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43145&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43145&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43145&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43145&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43145&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43145&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43145&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43145&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43145&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43145&r=mysqlcfg
#43132 [Fbk->Opn]: Date returned from exec command is formatted
ID: 43132
User updated by: jpozzoli at yahoo dot com
Reported By: jpozzoli at yahoo dot com
-Status: Feedback
+Status: Open
Bug Type: CGI related
Operating System: Debian Linux 2.6.18-5-686
PHP Version: 5.2.0
New Comment:
I'll get the CVS, but just for your reference, here's a composite of
several screens showing this "error", with the actual PHP code in the
box to the right.
http://www.flipnut.com/php-bug-43132.jpg
Previous Comments:
[2007-10-30 11:03:41] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
I can't reproduce this.
[2007-10-29 19:57:00] jpozzoli at yahoo dot com
Description:
This is on Debian PHP version 5.2.0-8+etch7 running on Apache/2.2.3
When trying to get the last reboot date of a linux server, from the
command line I run "who -b". More precisely, I run "who -b|awk \'{print
$3" "$4}\'" which, on the CLI, returns "2007-10-18 04:45". When I run
the PHP command echo exec('who -b|awk \'{print $3" "$4}\''); I get the
following result: Oct 18
Obviously, this has been formatted by PHP.
To make sure of this, I tried this:
$rebootdate = strftime("%m-%d-%Y %I:%M%p",
strtotime($rebootdateexec));
This get's closer. It outputs "10-18-2007 12:00AM". So it got the date
but missed the time.
Reproduce code:
---
$rebootdateexec = exec('who -b|awk \'{print $3" "$4}\'');
echo $rebootdateexec;
$rebootdate = strftime("%m-%d-%Y %I:%M%p",
strtotime($rebootdateexec));
echo $rebootdate;
Expected result:
$rebootdateexec = 2007-10-18 04:45
$rebootdate = 10-18-2007 04:45AM
Actual result:
--
$rebootdateexec = Oct 18
$rebootdate = 10-18-2007 12:00AM
--
Edit this bug report at http://bugs.php.net/?id=43132&edit=1
#38111 [Com]: PHP crashes IIS worker process and application pool
ID: 38111 Comment by: huet_bartels at hotmail dot com Reported By: svendavidh at hotmail dot com Status: No Feedback Bug Type: IIS related Operating System: Windows Server 2003 Std. Ed. R2 PHP Version: 5.1.4 New Comment: I have the same issue. I am using PHP/5.2.3 on IIS6 with plesk installed. The application pool just crashes every 1/2 to 1 hour. Previous Comments: [2007-07-15 13:35:15] zeon77 at gmail dot com The moodle_cron service causes the problem to me... [2007-07-11 18:11:59] zeon77 at gmail dot com Same with PHP 5.2.3, w2k3 r2 x86, iis6. PHP installed as ISAPI extension. Applications using PHP are running in a separate App pool. Error occurs in every half an hour [2007-07-07 11:06:35] mitch at mitchellgeere dot com I am running Windows Vista Ultimate with PHP 5.2, MySql, IIS 7.0. I am evaluating php, so far asp.net is holding my favour. [2007-05-27 05:03:49] doug at shontz dot net I am having this problem also. Clean installs of Vista (IIS7) and Server 2003 Enterprise (IIS6). PHP Version 5.2.2 with no additional plugins or filters (isapi or otherwise) on either box. Disable PHP and the problem stops...enable it and I can log it happening multiple times within an hour. I am running open source apps such as Joomla and WordPress, but I can get this to happen without having any pages on the site at all. [2007-05-23 09:35:10] bjoern dot andersen at atosorigin dot com Additional Info: The problem seems to go away when all webs run in the same application pool (No multithreading). So there is a point to start. It's not a real workaround for us, because in the huge production environment we run, we need to separate the application in safe pools. 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/38111 -- Edit this bug report at http://bugs.php.net/?id=38111&edit=1
#43144 [NEW]: configure fails checking for c++ compiler
From: babt at us dot ibm dot com Operating system: Mac OS X 10.5 PHP version: 5.2.4 PHP Bug Type: *Configuration Issues Bug description: configure fails checking for c++ compiler Description: When running configure, process fails to properly detect c++ due to previous failure to remove a directory. Below is the stream from the script. Configuring libtool checking build system type... i686-apple-darwin9.0.0 checking for ld used by gcc... /usr/libexec/gcc/i686-apple- darwin9/4.0.1/ld checking if the linker (/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld) is GNU ld... no checking for /usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking how to recognise dependent libraries... pass_all checking for object suffix... o checking for executable suffix... rm: conftest.dSYM: is a directory .dSYM checking for c++... c++ checking whether the C++ compiler (c++ ) works... no configure: error: installation or configuration problem: C++ compiler cannot create executables. Reproduce code: --- Plain vanilla OS X 10.5 Leopard build with Xcode 3.0 tools installed. Expected result: Configuring libtool checking build system type... i686-apple-darwin9.0.0 checking for ld used by /Developer/usr/bin/cc... /Developer/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld checking if the linker (/Developer/usr/libexec/gcc/i686-apple- darwin9/4.0.1/ld) is GNU ld... no checking for /Developer/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld option to reload object files... -r checking for BSD-compatible nm... /Developer/usr/bin/nm -p checking how to recognise dependent libraries... pass_all checking for object suffix... o checking for executable suffix... .dSYM checking for c++... c++ checking whether the C++ compiler (c++ ) works... yes Actual result: -- As in description. Workaround - Change configure script to use 'rm -rf' during the check for the executable suffix. -- Edit bug report at http://bugs.php.net/?id=43144&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43144&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43144&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43144&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43144&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43144&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43144&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43144&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43144&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43144&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43144&r=support Expected behavior:http://bugs.php.net/fix.php?id=43144&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43144&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43144&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43144&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43144&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43144&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43144&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43144&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43144&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43144&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43144&r=mysqlcfg
#43139 [Com]: PDO ignore ATTR_DEFAULT_FETCH_MODE in some cases
ID: 43139
Comment by: stochnagara at hotmail dot com
Reported By: develar at gmail dot com
Status: Open
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5.2.4
New Comment:
I have a similar problem with 5.2.4 on a linux/mysql installation. The
things worked on 5.2.0. The only difference is that I have a class that
overrides PDOStatement and there I use $this->setFetchMode
(PDO::FETCH_OBJ) which is not taken into account if FETCH_OBJ is not
explicitly set in further fetch/fetchAll calls.
Previous Comments:
[2007-10-30 11:49:32] develar at gmail dot com
Description:
In 5.2.4 (earlier all worked) and 5.2.5RC2dev (I now use this version)
PDO ignore ATTR_DEFAULT_FETCH_MODE.
PostgreSQL 8.2.4 and 8.3beta1.
Reproduce code:
---
setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC);
$Db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
print_r($Db->query('select 0 as name, 1 as table, 2 as
schema')->fetchAll(PDO::FETCH_GROUP));
?>
Expected result:
Array
(
[0] => Array
(
[0] => Array
(
[table] => 1
[schema] => 2
)
)
)
Actual result:
--
Array
(
[0] => Array
(
[0] => Array
(
[table] => 1
[0] => 1
[schema] => 2
[1] => 2
)
)
)
--
Edit this bug report at http://bugs.php.net/?id=43139&edit=1
#43143 [NEW]: Warning about empty IV with MCRYPT_MODE_ECB.
From: dylan at wedefy dot com Operating system: Windows XP PHP version: 5.2.4 PHP Bug Type: mcrypt related Bug description: Warning about empty IV with MCRYPT_MODE_ECB. Description: This warning makes sense for the other block cipher modes, but when using MCRYPT_MODE_ECB the initialization vector is not used at all, so it is misleading to recommend using one. In fact there should be a notice/warning when an IV is supplied with mode MCRYPT_MODE_ECB to alert that the IV is ignored. Reproduce code: --- Expected result: no warning Actual result: -- PHP Warning: mcrypt_encrypt(): Attempt to use an empty IV, which is NOT recommend -- Edit bug report at http://bugs.php.net/?id=43143&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43143&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43143&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43143&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43143&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43143&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43143&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43143&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43143&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43143&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43143&r=support Expected behavior:http://bugs.php.net/fix.php?id=43143&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43143&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43143&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43143&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43143&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43143&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43143&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43143&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43143&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43143&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43143&r=mysqlcfg
#43135 [Fbk->Csd]: Segmentation fault (core dumped)
ID: 43135 User updated by: a_kassasys at yahoo dot com -Reported By: kassasys at yahoo dot com +Reported By: a_kassasys at yahoo dot com -Status: Feedback +Status: Closed Bug Type: Reproducible crash Operating System: FreeBSD 6.2 PHP Version: 5.2.4 New Comment: Sorry, error was with interbase.so Previous Comments: [2007-10-30 10:59:38] [EMAIL PROTECTED] Get rid of the Zend extensions first. And then get a GDB backtrace of the crash. [2007-10-30 07:29:57] a_kassasys at yahoo dot com Description: Segmentation fault (core dumped) Reproduce code: --- php -v Expected result: PHP 5.2.4 (cli) (built: Oct 30 2007 09:00:28) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with Zend Extension Manager v1.2.0, Copyright (c) 2003-2006, by Zend Technol ogies with Zend Optimizer v3.2.2, Copyright (c) 1998-2006, by Zend Technologies Segmentation fault (core dumped) Actual result: -- %php -n -v PHP 5.2.4 (cli) (built: Oct 30 2007 09:00:28) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies -- Edit this bug report at http://bugs.php.net/?id=43135&edit=1
#43142 [NEW]: Call different function
From: felipensp at gmail dot com Operating system: Linux PHP version: 5.3CVS-2007-10-30 (snap) PHP Bug Type: Scripting Engine problem Bug description: Call different function Description: Return of create_function() concat. with 'foo'. But, when calling the function with the name of variable's value, only 'foo' is used... Reproduce code: --- http://bugs.php.net/?id=43142&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43142&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43142&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43142&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43142&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43142&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43142&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43142&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43142&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43142&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43142&r=support Expected behavior:http://bugs.php.net/fix.php?id=43142&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43142&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43142&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43142&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43142&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43142&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43142&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43142&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43142&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43142&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43142&r=mysqlcfg
#43141 [NEW]: Converting $this to int
From: felipensp at gmail dot com Operating system: Linux PHP version: 5.3CVS-2007-10-30 (snap) PHP Bug Type: Scripting Engine problem Bug description: Converting $this to int Description: When try converter $this to string, one Catchable fatal error occur. $this to int, only Notice... Reproduce code: --- $this; // Odd... Notice: Undefined property: foo::$2 var_dump($this->test); // foo var_dump($this); // int(2) } } new foo; Expected result: Catchable fatal error: Object of class foo could not be converted to int Actual result: -- Notice: Object of class foo could not be converted to int in /home/felipe/public_html/bug.php on line 16 int(2) string(3) "foo" int(2) -- Edit bug report at http://bugs.php.net/?id=43141&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43141&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43141&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43141&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43141&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43141&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43141&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43141&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43141&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43141&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43141&r=support Expected behavior:http://bugs.php.net/fix.php?id=43141&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43141&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43141&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43141&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43141&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43141&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43141&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43141&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43141&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43141&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43141&r=mysqlcfg
#43140 [NEW]: Error in parser
From: felipensp at gmail dot com
Operating system: Linux
PHP version: 5.3CVS-2007-10-30 (snap)
PHP Bug Type: Scripting Engine problem
Bug description: Error in parser
Description:
Parser recognize wrong the array parameter.
It see array(..) as (array).
Reproduce code:
---
$a = create_function(array(1), 'print 1;');
Expected result:
Parse error: syntax error, unexpected T_ARRAY, expecting '&' or T_VARIABLE
Actual result:
--
Parse error: syntax error, unexpected T_ARRAY_CAST, expecting '(' in
/home/felipe/public_html/bug.php(4) : runtime-created function
--
Edit bug report at http://bugs.php.net/?id=43140&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43140&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43140&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43140&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43140&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43140&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43140&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43140&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43140&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43140&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43140&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43140&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43140&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43140&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43140&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43140&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43140&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43140&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43140&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43140&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43140&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43140&r=mysqlcfg
#43139 [NEW]: PDO ignore ATTR_DEFAULT_FETCH_MODE in some cases
From: develar at gmail dot com
Operating system: Windows XP SP2
PHP version: 5.2.4
PHP Bug Type: PDO related
Bug description: PDO ignore ATTR_DEFAULT_FETCH_MODE in some cases
Description:
In 5.2.4 (earlier all worked) and 5.2.5RC2dev (I now use this version) PDO
ignore ATTR_DEFAULT_FETCH_MODE.
PostgreSQL 8.2.4 and 8.3beta1.
Reproduce code:
---
setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC);
$Db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
print_r($Db->query('select 0 as name, 1 as table, 2 as
schema')->fetchAll(PDO::FETCH_GROUP));
?>
Expected result:
Array
(
[0] => Array
(
[0] => Array
(
[table] => 1
[schema] => 2
)
)
)
Actual result:
--
Array
(
[0] => Array
(
[0] => Array
(
[table] => 1
[0] => 1
[schema] => 2
[1] => 2
)
)
)
--
Edit bug report at http://bugs.php.net/?id=43139&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43139&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43139&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43139&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43139&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43139&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43139&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43139&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43139&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43139&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43139&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43139&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43139&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43139&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43139&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43139&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43139&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43139&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43139&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43139&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43139&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43139&r=mysqlcfg
#43128 [Com]: Very long class name causes segfault
ID: 43128
Comment by: crrodriguez at suse dot de
Reported By: felipensp at gmail dot com
Status: Analyzed
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 5.3CVS-2007-10-29 (snap)
New Comment:
Yes, an smaller limit like 1024 looks OK and is still high enough to
avoid annoying insane coders ;-)
Previous Comments:
[2007-10-30 10:48:14] [EMAIL PROTECTED]
That would already allocate 64kb on the stack, I doubt that will work
on all systems. I would suggest a somewhat smaller limit, say 1024?
[2007-10-30 10:37:39] crrodriguez at suse dot de
Index: Zend/zend_execute_API.c
===
RCS file: /repository/ZendEngine2/zend_execute_API.c,v
retrieving revision 1.331.2.20.2.24.2.8
diff -u -p -r1.331.2.20.2.24.2.8 zend_execute_API.c
--- Zend/zend_execute_API.c 7 Oct 2007 05:22:03 -
1.331.2.20.2.24.2.8
+++ Zend/zend_execute_API.c 30 Oct 2007 10:14:29 -
@@ -1073,6 +1073,10 @@ ZEND_API int zend_lookup_class_ex(const
if (name == NULL || !name_length) {
return FAILURE;
}
+
+ if(name_length >= ZEND_MAX_CLASSNAME_LEN) {
+ zend_error(E_ERROR, "Class name cannot be longer than
%d", ZEND_MAX_CLASSNAME_LEN);
+ }
lc_free = lc_name = do_alloca(name_length + 1);
zend_str_tolower_copy(lc_name, name, name_length);
Index: Zend/zend.h
===
RCS file: /repository/ZendEngine2/zend.h,v
retrieving revision 1.293.2.11.2.9.2.7
diff -u -p -r1.293.2.11.2.9.2.7 zend.h
--- Zend/zend.h 7 Oct 2007 05:22:02 - 1.293.2.11.2.9.2.7
+++ Zend/zend.h 30 Oct 2007 10:14:29 -
@@ -712,7 +712,7 @@ END_EXTERN_C()
#define ZEND_MAX_RESERVED_RESOURCES4
-
+#define ZEND_MAX_CLASSNAME_LEN 65535
#include "zend_operators.h"
#include "zend_variables.h"
ZEND_MAX_CLASSNAME_LEN being the same as java, not to mention that I
dont see any reason why such insane long naming will be useful :-)
HTH.
[2007-10-30 08:21:08] [EMAIL PROTECTED]
Segfaults for me too, looks like a stack smash with valgrind:
==7344== Warning: client switching stacks? SP change: 0x7FEFFD9A0 -->
0x7FE674310
==7344== to suppress, use: --max-stackframe=1016 or
greater
==7344== Invalid write of size 8
==7344==at 0x85D4D3: zend_lookup_class_ex
(zend_execute_API.c:1046)
==7344== Address 0x7FE674308 is on thread 1's stack
==7344==
==7344== Process terminating with default action of signal 11
(SIGSEGV)
==7344== Access not within mapped region at address 0x7FE674308
==7344==at 0x85D4D3: zend_lookup_class_ex
(zend_execute_API.c:1046)
==7344==
==7344== Invalid write of size 8
==7344==at 0x4A1E310: _vgnU_freeres (vg_preloaded.c:56)
==7344== Address 0x7FE674300 is on thread 1's stack
==7344==
==7344== Process terminating with default action of signal 11
(SIGSEGV)
==7344== Access not within mapped region at address 0x7FE674300
Which makes sense, as lc_name in
zend_lookup_class_ex() is allocated on line 1045 with:
lc_name = do_alloca(name_length + 1);
zend_str_tolower_copy(lc_name, name, name_length);
SPL and Reflection have the same problem in the files:
ext/spl/php_spl.c
ext/reflection/php_reflection.c
A possible fix would be to set an arbitrary limit on the name of
classes here...
[2007-10-30 00:14:09] crrodriguez at suse dot de
Always reproducible on linux64 bit hosts.
[2007-10-29 23:46:15] felipensp at gmail dot com
PHP 5.2.5RC2-dev (cli) (built: Oct 29 2007 21:22:10):
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1211684448 (LWP 31245)]
zend_lookup_class_ex (name=0xb722e018 'a' ...,
name_length=1000, use_autoload=0, ce=0xbfa0c498)
at /home/felipe/php5.2-200710292130/Zend/zend_execute_API.c:1046
1046zend_str_tolower_copy(lc_name, name, name_length);
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/43128
--
Edit this bug report at http://bugs.php.net/?id=43128&edit=1
#43138 [NEW]: self and parent in variable
From: felipensp at gmail dot com Operating system: Linux PHP version: 5.3CVS-2007-10-30 (snap) PHP Bug Type: Scripting Engine problem Bug description: self and parent in variable Description: 'self' and 'parent' don't are evaluated when calling static member/method with class name in variables. Reproduce code: --- http://bugs.php.net/?id=43138&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43138&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43138&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43138&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43138&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43138&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43138&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43138&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43138&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43138&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43138&r=support Expected behavior:http://bugs.php.net/fix.php?id=43138&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43138&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43138&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43138&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43138&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43138&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43138&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43138&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43138&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43138&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43138&r=mysqlcfg
#43132 [Opn->Fbk]: Date returned from exec command is formatted
ID: 43132
Updated by: [EMAIL PROTECTED]
Reported By: jpozzoli at yahoo dot com
-Status: Open
+Status: Feedback
Bug Type: CGI related
Operating System: Debian Linux 2.6.18-5-686
PHP Version: 5.2.0
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
I can't reproduce this.
Previous Comments:
[2007-10-29 19:57:00] jpozzoli at yahoo dot com
Description:
This is on Debian PHP version 5.2.0-8+etch7 running on Apache/2.2.3
When trying to get the last reboot date of a linux server, from the
command line I run "who -b". More precisely, I run "who -b|awk \'{print
$3" "$4}\'" which, on the CLI, returns "2007-10-18 04:45". When I run
the PHP command echo exec('who -b|awk \'{print $3" "$4}\''); I get the
following result: Oct 18
Obviously, this has been formatted by PHP.
To make sure of this, I tried this:
$rebootdate = strftime("%m-%d-%Y %I:%M%p",
strtotime($rebootdateexec));
This get's closer. It outputs "10-18-2007 12:00AM". So it got the date
but missed the time.
Reproduce code:
---
$rebootdateexec = exec('who -b|awk \'{print $3" "$4}\'');
echo $rebootdateexec;
$rebootdate = strftime("%m-%d-%Y %I:%M%p",
strtotime($rebootdateexec));
echo $rebootdate;
Expected result:
$rebootdateexec = 2007-10-18 04:45
$rebootdate = 10-18-2007 04:45AM
Actual result:
--
$rebootdateexec = Oct 18
$rebootdate = 10-18-2007 12:00AM
--
Edit this bug report at http://bugs.php.net/?id=43132&edit=1
#22427 [Com]: Missing Form Post Data
ID: 22427
Comment by: sbauer at gjl-network dot net
Reported By: jroland at uow dot edu dot au
Status: No Feedback
Bug Type: *General Issues
Operating System: Windows XP / 2000
PHP Version: 4.2.3
New Comment:
While experiencing this issue, too we found that the cause of this
problem was the suhosin patch, wich was - by default - configured to
have a max limit for the length of cookie, request, post, get and
session vars. E.g. for POST this looks like:
suhosin.post.max_array_depth100 100
suhosin.post.max_array_index_length 64 64
suhosin.post.max_name_length64 64
suhosin.post.max_totalname_length 256 256
suhosin.post.max_value_length 65000 65000
suhosin.post.max_vars 200 200
Those derivatives needs to be set to a adequate higher number. E.g. in
our case, the problem was, that our POST data was too long (as this
seems to be the case for a lot of you here).
So I suggest to check your php.ini or (according to your distribution
there often is a suhosin.ini) and correct the above values or set them
to 0 to disable it. If those derivatives are not set, default values
will be used.
You need to check / add:
suhosin.post.max_
suhosin.request.max_...
suhosin.get.max_...
suhosin.session.max_...
suhosin.cookie.max_...
Refer to your phpinfo() where these values should be listed!
Previous Comments:
[2007-10-23 18:33:37] bcoy at chicagoreader dot com
It appears I miscounted the length of my data in the above comment.
Here is a test script that proves the maximum length, at least on this
setup, is exactly 10,000 characters:
Request Length: " .
getenv("CONTENT_LENGTH") . "";
echo "POST: "; print_r($_POST); echo "";
echo "HTTP_POST_VARS: ";
print_r($HTTP_POST_VARS);
?>
[2007-10-23 18:16:34] bcoy at chicagoreader dot com
This post exists to try and organize what I've read above.
There appear to be two main issues here. The special character issue
in IE seems to be well understood at this point. The fix is to to
translate all those characters into ascii (unicode html entities are
helpful here).
However, it appears that several people, including myself, still have a
length problem. In my script, I have max_post_size set to 50M and
output_buffering on (as suggested in these comments). I have an
all-ascii piece of data, which works up to 10021 characters, but fails
at 10022, regardless of what the last character is. This fails in all
browsers: Safari, Firefox, and IE. The data is not accessible via
$_POST or $HTTP_POST_VARS. It fails with or without
enctype="multipart/form-data". getenv("CONTENT_LENGTH") is 10173 in
Firefox and 10111 in Safari. If I change to a GET request, I receive an
error indicating that the URI is too long for the server to support.
My setup is:
PHP 5.03
Apache 1.3.33
FreeBSD 4.10
[2007-10-02 06:08:19] solidus_in at yahoo dot com
When the post data contains HTML special entities i.e. "&" it is
stripped off. PHP POst variable only contains data before the first
occurrence of "&"
I am not sure whether it is a bug or something else. I am yet to test
the POST containing other HTML entities. I have been trying to solve the
issue but it remains yet.
Any help there?
[2007-09-21 08:48:04] umberto at meroni dot name
Hi there,
I solved this problem setting
output_buffering = On
in my PHP.ini.
I hope this helps.
Umberto Meroni
[2007-09-18 11:57:57] idefix at dwaal dot net
The same problem happens to me (and my users unfortunately).
- PHP Version 5.1.6
- Apache/2.2.3 (CentOS)
- only with enctype="multipart/form-data"
- only with IE6 on WinXP sp2
- _POST is completely empty (count($_POST) === 0)
- Uploaded files are smaller than 3 MB.
- Charset: US-ASCII (both Apache header and Meta-tag)
For some reason only _some_ IE6 WinXP SP2 machines trigger this error.
Opera and Firefox do not seem to trigger this error at all.
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/22427
--
Edit this bug report at http://bugs.php.net/?id=22427&edit=1
#43120 [Opn]: PDO: domain Authenticated Machines no Username/password (make them optional)
ID: 43120 Updated by: [EMAIL PROTECTED] Reported By: tshipclark at gmail dot com Status: Open -Bug Type: PDO related +Bug Type: Feature/Change Request Operating System: Windows PHP Version: 5.2.4 New Comment: it's a feature/change request, keep it there. Previous Comments: [2007-10-28 14:18:11] tshipclark at gmail dot com Description: We currently use mssql_pconnect to connect to our server and we don't supply a username/password because the machine iis is running on is domain authenticated. My problem is Pdo will not allow me to not enter a username and password. And even if I put in blanks for username/password i still get permission denied. If you could make username/password optional that would be great! -- Edit this bug report at http://bugs.php.net/?id=43120&edit=1
#43134 [Opn->Fbk]: Apache2 crashes upon processing any php page.
ID: 43134 Updated by: [EMAIL PROTECTED] Reported By: akujin at akujin dot com -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Vista 32-bit PHP Version: 5.2.4 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Previous Comments: [2007-10-30 06:53:48] akujin at akujin dot com All right, a bit of new information. The error log in apache was picking up this at every crash: [Mon Oct 29 23:50:59 2007] [notice] Parent: child process exited with status 3221225477 -- Restarting. [Mon Oct 29 23:50:59 2007] [notice] Apache/2.2.6 (Win32) PHP/5.2.4 configured -- resuming normal operations [Mon Oct 29 23:50:59 2007] [notice] Server built: Sep 5 2007 08:58:56 [Mon Oct 29 23:50:59 2007] [notice] Parent: Created child process 5776 [Mon Oct 29 23:51:00 2007] [notice] Child 5776: Child process is running [Mon Oct 29 23:51:00 2007] [notice] Child 5776: Acquired the start mutex. [Mon Oct 29 23:51:00 2007] [notice] Child 5776: Starting 250 worker threads. [Mon Oct 29 23:51:00 2007] [notice] Child 5776: Starting thread to listen on port 80. So error status 3221225477 would be my problem. [2007-10-30 06:46:14] akujin at akujin dot com Description: This is a fresh install on Vista. I've installed the standard server setup (Apache2+Php+Mysql) I've been using for years, and everything seems to be going fine. The first time I attempt to load a .php page, apache2 crashes. I reboot, reload the page, and apache crashes again. I've tried writing test pages, loading standard functions (phpinfo()), and every process seems to crash apache. I'm at a loss as to the cause. Apache 2.2.6, PHP 5.2.4, Vista 32-bit. Reproduce code: --- Any PHP code. Expected result: A page returned from the server. Actual result: -- Apache2 crashes. I've been unable to find a cause in the logs. -- Edit this bug report at http://bugs.php.net/?id=43134&edit=1
#43135 [Opn->Fbk]: Segmentation fault (core dumped)
ID: 43135 Updated by: [EMAIL PROTECTED] Reported By: kassasys at yahoo dot com -Status: Open +Status: Feedback Bug Type: Output Control Operating System: FreeBSD 6.2 PHP Version: 5.2.4 New Comment: Get rid of the Zend extensions first. And then get a GDB backtrace of the crash. Previous Comments: [2007-10-30 07:29:57] kassasys at yahoo dot com Description: Segmentation fault (core dumped) Reproduce code: --- php -v Expected result: PHP 5.2.4 (cli) (built: Oct 30 2007 09:00:28) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with Zend Extension Manager v1.2.0, Copyright (c) 2003-2006, by Zend Technol ogies with Zend Optimizer v3.2.2, Copyright (c) 1998-2006, by Zend Technologies Segmentation fault (core dumped) Actual result: -- %php -n -v PHP 5.2.4 (cli) (built: Oct 30 2007 09:00:28) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies -- Edit this bug report at http://bugs.php.net/?id=43135&edit=1
#43128 [Ana]: Long name cause seg. fault
ID: 43128
Updated by: [EMAIL PROTECTED]
Reported By: felipensp at gmail dot com
Status: Analyzed
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 5.3CVS-2007-10-29 (snap)
New Comment:
That would already allocate 64kb on the stack, I doubt that will work
on all systems. I would suggest a somewhat smaller limit, say 1024?
Previous Comments:
[2007-10-30 10:37:39] crrodriguez at suse dot de
Index: Zend/zend_execute_API.c
===
RCS file: /repository/ZendEngine2/zend_execute_API.c,v
retrieving revision 1.331.2.20.2.24.2.8
diff -u -p -r1.331.2.20.2.24.2.8 zend_execute_API.c
--- Zend/zend_execute_API.c 7 Oct 2007 05:22:03 -
1.331.2.20.2.24.2.8
+++ Zend/zend_execute_API.c 30 Oct 2007 10:14:29 -
@@ -1073,6 +1073,10 @@ ZEND_API int zend_lookup_class_ex(const
if (name == NULL || !name_length) {
return FAILURE;
}
+
+ if(name_length >= ZEND_MAX_CLASSNAME_LEN) {
+ zend_error(E_ERROR, "Class name cannot be longer than
%d", ZEND_MAX_CLASSNAME_LEN);
+ }
lc_free = lc_name = do_alloca(name_length + 1);
zend_str_tolower_copy(lc_name, name, name_length);
Index: Zend/zend.h
===
RCS file: /repository/ZendEngine2/zend.h,v
retrieving revision 1.293.2.11.2.9.2.7
diff -u -p -r1.293.2.11.2.9.2.7 zend.h
--- Zend/zend.h 7 Oct 2007 05:22:02 - 1.293.2.11.2.9.2.7
+++ Zend/zend.h 30 Oct 2007 10:14:29 -
@@ -712,7 +712,7 @@ END_EXTERN_C()
#define ZEND_MAX_RESERVED_RESOURCES4
-
+#define ZEND_MAX_CLASSNAME_LEN 65535
#include "zend_operators.h"
#include "zend_variables.h"
ZEND_MAX_CLASSNAME_LEN being the same as java, not to mention that I
dont see any reason why such insane long naming will be useful :-)
HTH.
[2007-10-30 08:21:08] [EMAIL PROTECTED]
Segfaults for me too, looks like a stack smash with valgrind:
==7344== Warning: client switching stacks? SP change: 0x7FEFFD9A0 -->
0x7FE674310
==7344== to suppress, use: --max-stackframe=1016 or
greater
==7344== Invalid write of size 8
==7344==at 0x85D4D3: zend_lookup_class_ex
(zend_execute_API.c:1046)
==7344== Address 0x7FE674308 is on thread 1's stack
==7344==
==7344== Process terminating with default action of signal 11
(SIGSEGV)
==7344== Access not within mapped region at address 0x7FE674308
==7344==at 0x85D4D3: zend_lookup_class_ex
(zend_execute_API.c:1046)
==7344==
==7344== Invalid write of size 8
==7344==at 0x4A1E310: _vgnU_freeres (vg_preloaded.c:56)
==7344== Address 0x7FE674300 is on thread 1's stack
==7344==
==7344== Process terminating with default action of signal 11
(SIGSEGV)
==7344== Access not within mapped region at address 0x7FE674300
Which makes sense, as lc_name in
zend_lookup_class_ex() is allocated on line 1045 with:
lc_name = do_alloca(name_length + 1);
zend_str_tolower_copy(lc_name, name, name_length);
SPL and Reflection have the same problem in the files:
ext/spl/php_spl.c
ext/reflection/php_reflection.c
A possible fix would be to set an arbitrary limit on the name of
classes here...
[2007-10-30 00:14:09] crrodriguez at suse dot de
Always reproducible on linux64 bit hosts.
[2007-10-29 23:46:15] felipensp at gmail dot com
PHP 5.2.5RC2-dev (cli) (built: Oct 29 2007 21:22:10):
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1211684448 (LWP 31245)]
zend_lookup_class_ex (name=0xb722e018 'a' ...,
name_length=1000, use_autoload=0, ce=0xbfa0c498)
at /home/felipe/php5.2-200710292130/Zend/zend_execute_API.c:1046
1046zend_str_tolower_copy(lc_name, name, name_length);
[2007-10-29 22:24:54] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
I've tried both PHP 5.2 and 5.3 and cannot reproduce the crash.
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/43128
--
Edit this bug report at http://bugs.php.net/?id=43128&edit=1
#43128 [Com]: Long name cause seg. fault
ID: 43128
Comment by: crrodriguez at suse dot de
Reported By: felipensp at gmail dot com
Status: Analyzed
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 5.3CVS-2007-10-29 (snap)
New Comment:
Index: Zend/zend_execute_API.c
===
RCS file: /repository/ZendEngine2/zend_execute_API.c,v
retrieving revision 1.331.2.20.2.24.2.8
diff -u -p -r1.331.2.20.2.24.2.8 zend_execute_API.c
--- Zend/zend_execute_API.c 7 Oct 2007 05:22:03 -
1.331.2.20.2.24.2.8
+++ Zend/zend_execute_API.c 30 Oct 2007 10:14:29 -
@@ -1073,6 +1073,10 @@ ZEND_API int zend_lookup_class_ex(const
if (name == NULL || !name_length) {
return FAILURE;
}
+
+ if(name_length >= ZEND_MAX_CLASSNAME_LEN) {
+ zend_error(E_ERROR, "Class name cannot be longer than
%d", ZEND_MAX_CLASSNAME_LEN);
+ }
lc_free = lc_name = do_alloca(name_length + 1);
zend_str_tolower_copy(lc_name, name, name_length);
Index: Zend/zend.h
===
RCS file: /repository/ZendEngine2/zend.h,v
retrieving revision 1.293.2.11.2.9.2.7
diff -u -p -r1.293.2.11.2.9.2.7 zend.h
--- Zend/zend.h 7 Oct 2007 05:22:02 - 1.293.2.11.2.9.2.7
+++ Zend/zend.h 30 Oct 2007 10:14:29 -
@@ -712,7 +712,7 @@ END_EXTERN_C()
#define ZEND_MAX_RESERVED_RESOURCES4
-
+#define ZEND_MAX_CLASSNAME_LEN 65535
#include "zend_operators.h"
#include "zend_variables.h"
ZEND_MAX_CLASSNAME_LEN being the same as java, not to mention that I
dont see any reason why such insane long naming will be useful :-)
HTH.
Previous Comments:
[2007-10-30 08:21:08] [EMAIL PROTECTED]
Segfaults for me too, looks like a stack smash with valgrind:
==7344== Warning: client switching stacks? SP change: 0x7FEFFD9A0 -->
0x7FE674310
==7344== to suppress, use: --max-stackframe=1016 or
greater
==7344== Invalid write of size 8
==7344==at 0x85D4D3: zend_lookup_class_ex
(zend_execute_API.c:1046)
==7344== Address 0x7FE674308 is on thread 1's stack
==7344==
==7344== Process terminating with default action of signal 11
(SIGSEGV)
==7344== Access not within mapped region at address 0x7FE674308
==7344==at 0x85D4D3: zend_lookup_class_ex
(zend_execute_API.c:1046)
==7344==
==7344== Invalid write of size 8
==7344==at 0x4A1E310: _vgnU_freeres (vg_preloaded.c:56)
==7344== Address 0x7FE674300 is on thread 1's stack
==7344==
==7344== Process terminating with default action of signal 11
(SIGSEGV)
==7344== Access not within mapped region at address 0x7FE674300
Which makes sense, as lc_name in
zend_lookup_class_ex() is allocated on line 1045 with:
lc_name = do_alloca(name_length + 1);
zend_str_tolower_copy(lc_name, name, name_length);
SPL and Reflection have the same problem in the files:
ext/spl/php_spl.c
ext/reflection/php_reflection.c
A possible fix would be to set an arbitrary limit on the name of
classes here...
[2007-10-30 00:14:09] crrodriguez at suse dot de
Always reproducible on linux64 bit hosts.
[2007-10-29 23:46:15] felipensp at gmail dot com
PHP 5.2.5RC2-dev (cli) (built: Oct 29 2007 21:22:10):
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1211684448 (LWP 31245)]
zend_lookup_class_ex (name=0xb722e018 'a' ...,
name_length=1000, use_autoload=0, ce=0xbfa0c498)
at /home/felipe/php5.2-200710292130/Zend/zend_execute_API.c:1046
1046zend_str_tolower_copy(lc_name, name, name_length);
[2007-10-29 22:24:54] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
I've tried both PHP 5.2 and 5.3 and cannot reproduce the crash.
[2007-10-29 17:25:28] felipensp at gmail dot com
Description:
Long names cause segmentation fault in 'instanceof' and 'new'
operators.
Reproduce code:
---
$a(); // Fatal error
if ($a instanceof $a); // Segmentation fault
new $a;// Segmentation fault
Expected result:
Warning / Fatal error
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1214703296 (LWP 4538)]
zend_lookup_class_ex (name=0xb6f4d018 'a' ...,
name_length=1000, use_autoload=0, ce=0xbf9644d8)
at /home/felipe/php5.3-200710261430/Zend/zend_execute_A
#41350 [Com]: Error in my_thread_global_end()
ID: 41350 Comment by: chris at crgs dot co dot uk Reported By: graham at directhostinguk dot com Status: Feedback Bug Type: MySQL related Operating System: Windows 2003 PHP Version: 5.2.3 New Comment: Scott, am having this issue on both XP and Server 2003. What spec machine are you testing on? Can you try this on another machine, or in a virtual machine? Previous Comments: [2007-10-25 17:25:34] rburghol at vt dot edu My apologies as well, the fix DID work, even though I had disabled mysql in php.ini, and no mysql presence was shown in the phpinfo() output, for some reason, mysql stuff must have been loaded anyhow! (perhaps it is precompiled somewhere in the win executable???) Woohoo! My ajax is now responsive!!! [2007-10-25 16:06:28] rburghol at vt dot edu Error occurs with Postgresql, but only if I instantiate a database connection (using pg_connect). Even if I do nothing with the connection AND if I explicitly close the connection (pg_close). Removing the pg_connect makes the error go away, and avoids the ~5 second delay. I would submit that this is not mysql related, since I have disabled the mysql dll. PHP Version: 5.2.4 Via FastCGI System Specs: Windows XP Service Pack 2 Intel P4 2.8 GHz [2007-10-25 13:54:39] noto at ardentsolutions dot co dot za My appologies to you all. The fix works great! I'm running MySQL 4.1 and PHP 5.2.4 on XP. My issue was that IE 7 kind of waits for ajax code to finish executing before leaving a page, which is dumb... [2007-10-25 12:28:05] noto at ardentsolutions dot co dot za I tried this and it's not really helping much hey... I also noticed that this causes the pages to load slower (on IE, IE7). On firefox the pages load quicker but the error is there... [2007-10-25 10:35:00] [EMAIL PROTECTED] I can't reproduce this on XP which is the only Windows environment I have for testing. Are the people still experiencing problems on Windows 2000 or 2003? 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/41350 -- Edit this bug report at http://bugs.php.net/?id=41350&edit=1
#43137 [Opn]: rmdir() does not clear statcache
ID: 43137 User updated by: [EMAIL PROTECTED] -Summary: rmdri() does not clear statcache Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Directory function related Operating System: Linux 2.6.21 PHP Version: 5.2.5RC1 New Comment: Fixed bug title. Previous Comments: [2007-10-30 10:04:04] [EMAIL PROTECTED] Description: rmdir() does not clear the statcache like unlink() does. Reproduce code: --- #!/usr/bin/env php Expected result: bool(true) bool(false) bool(false) Actual result: -- bool(true) bool(true) bool(false) -- Edit this bug report at http://bugs.php.net/?id=43137&edit=1
#43137 [NEW]: rmdri() does not clear statcache
From: [EMAIL PROTECTED] Operating system: Linux 2.6.21 PHP version: 5.2.5RC1 PHP Bug Type: Directory function related Bug description: rmdri() does not clear statcache Description: rmdir() does not clear the statcache like unlink() does. Reproduce code: --- #!/usr/bin/env php Expected result: bool(true) bool(false) bool(false) Actual result: -- bool(true) bool(true) bool(false) -- Edit bug report at http://bugs.php.net/?id=43137&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43137&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43137&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43137&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43137&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43137&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43137&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43137&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43137&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43137&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43137&r=support Expected behavior:http://bugs.php.net/fix.php?id=43137&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43137&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43137&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43137&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43137&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43137&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43137&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43137&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43137&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43137&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43137&r=mysqlcfg
#43130 [Csd]: bind parameter cannot contain dashes
ID: 43130
Updated by: [EMAIL PROTECTED]
Reported By: joel at purerave dot com
Status: Closed
Bug Type: PDO related
Operating System: Windows XP Home
PHP Version: 5.2.4
Assigned To: iliaa
New Comment:
I disagree with the decision to allow "-" in parameter names. Parameter
names should consist of [a-zA-Z] and nothing else. "-" is an operator in
most databases.
For BC compatibility I'm also fine with the old pattern
[:][a-zA-Z0-9_]+ . Though I must say, that I'd prefer
[:][a-zA-Z]+[a-zA-Z0-9_]+, don't allow ":0". ":0" looks a bit like
"operator" + "number"...
However, the underlying problem here is that there is absolutely no
specification for PDO. This makes PDO a guessing game and error prone.
Previous Comments:
[2007-10-29 22:37:51] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2007-10-29 18:07:00] joel at purerave dot com
Description:
Parameters to bind in a prepared statement cannot contain dashes (-) in
the name. It probably assumes that "-value" should be another variable.
If this cannot be fixed, then at least update the documentation to make
it clear what names can and cannot be used. Using {} around the variable
name would be nice too!
Reproduce code:
---
$db = new PDO("mysql:host=localhost;dbname=testing", '', '');
$stmt = $db->prepare("SELECT id FROM testing WHERE id=:id-value");
$stmt->bindParam(':id-value', $id);
$id = 1;
$stmt->execute();
var_dump($stmt->fetch());
Expected result:
array(2) { ["id"]=> string(1) "1" [0]=> string(1) "1" }
Actual result:
--
Warning: PDOStatement::execute() [function.PDOStatement-execute]:
SQLSTATE[HY093]: Invalid parameter number: parameter was not defined in
C:\htdocs\test.php on line 8
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=43130&edit=1
#43136 [Opn->Asn]: possible crash on script execution timeout
ID: 43136 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: Scripting Engine problem Operating System: Linux 64bit PHP Version: 4.4.7 -Assigned To: +Assigned To: dmitry New Comment: Assigning to Dmitry at his request. Previous Comments: [2007-10-30 08:45:23] [EMAIL PROTECTED] Description: The crash is really rare, but seems to be possible. According to the core, it happened when script execution timed out and active_opline pointer was NULL at that moment, so zend_get_executed_lineno() tried to dereference NULL ptr. Even though the backtrace mentions Zend Opimizer, it doesn't seem to be required to reproduce the crash and it is not PHP4 specific. Reproduce code: --- . Expected result: . Actual result: -- (gdb) bt #0 0x0052d7d1 in zend_get_executed_lineno () at /shared/misc/standard/php.src/php-4.4.7/Zend/zend_execute_API.c:269 #1 0x00536c4b in zend_error (type=1, format=0x6ce4b8 "Maximum execution time of %d second%s exceeded") at /shared/misc/standard/php.src/php-4.4.7/Zend/zend.c:760 #2 #3 0x002a97194f2b in zend_optimizer_set_oe_ex () from /local/Zend/lib/php-4.4.x/ZendOptimizer.so #4 0x002a97194f16 in zend_optimizer_set_oe_ex () from /local/Zend/lib/php-4.4.x/ZendOptimizer.so #5 0x002a97194f16 in zend_optimizer_set_oe_ex () from /local/Zend/lib/php-4.4.x/ZendOptimizer.so #6 0x002a97194f16 in zend_optimizer_set_oe_ex () from /local/Zend/lib/php-4.4.x/ZendOptimizer.so #7 0x002a97194f16 in zend_optimizer_set_oe_ex () from /local/Zend/lib/php-4.4.x/ZendOptimizer.so #8 0x005365bf in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /shared/misc/standard/php.src/php-4.4.7/Zend/zend.c:939 #9 0x004fe699 in php_execute_script (primary_file=0x7fbb20) at /shared/misc/standard/php.src/php-4.4.7/main/main.c:1784 #10 0x00557bfd in main (argc=5, argv=0x7fbc78) at /shared/misc/standard/php.src/php-4.4.7/sapi/cgi/cgi_main.c:2236 Further investigation has shown that active_opline is NULL: (gdb) f 0 #0 0x0052d7d1 in zend_get_executed_lineno () at /shared/misc/standard/php.src/php-4.4.7/Zend/zend_execute_API.c:269 269 /shared/misc/standard/php.src/php-4.4.7/Zend/zend_execute_API.c: No such file or directory. in /shared/misc/standard/php.src/php-4.4.7/Zend/zend_execute_API.c (gdb) p executor_globals.opline_ptr $3 = (zend_op **) 0x7fbfff9510 (gdb) p *executor_globals.opline_ptr $4 = (zend_op *) 0x0 -- Edit this bug report at http://bugs.php.net/?id=43136&edit=1
#43136 [NEW]: possible crash on script execution timeout
From: [EMAIL PROTECTED] Operating system: Linux 64bit PHP version: 4.4.7 PHP Bug Type: Scripting Engine problem Bug description: possible crash on script execution timeout Description: The crash is really rare, but seems to be possible. According to the core, it happened when script execution timed out and active_opline pointer was NULL at that moment, so zend_get_executed_lineno() tried to dereference NULL ptr. Even though the backtrace mentions Zend Opimizer, it doesn't seem to be required to reproduce the crash and it is not PHP4 specific. Reproduce code: --- . Expected result: . Actual result: -- (gdb) bt #0 0x0052d7d1 in zend_get_executed_lineno () at /shared/misc/standard/php.src/php-4.4.7/Zend/zend_execute_API.c:269 #1 0x00536c4b in zend_error (type=1, format=0x6ce4b8 "Maximum execution time of %d second%s exceeded") at /shared/misc/standard/php.src/php-4.4.7/Zend/zend.c:760 #2 #3 0x002a97194f2b in zend_optimizer_set_oe_ex () from /local/Zend/lib/php-4.4.x/ZendOptimizer.so #4 0x002a97194f16 in zend_optimizer_set_oe_ex () from /local/Zend/lib/php-4.4.x/ZendOptimizer.so #5 0x002a97194f16 in zend_optimizer_set_oe_ex () from /local/Zend/lib/php-4.4.x/ZendOptimizer.so #6 0x002a97194f16 in zend_optimizer_set_oe_ex () from /local/Zend/lib/php-4.4.x/ZendOptimizer.so #7 0x002a97194f16 in zend_optimizer_set_oe_ex () from /local/Zend/lib/php-4.4.x/ZendOptimizer.so #8 0x005365bf in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /shared/misc/standard/php.src/php-4.4.7/Zend/zend.c:939 #9 0x004fe699 in php_execute_script (primary_file=0x7fbb20) at /shared/misc/standard/php.src/php-4.4.7/main/main.c:1784 #10 0x00557bfd in main (argc=5, argv=0x7fbc78) at /shared/misc/standard/php.src/php-4.4.7/sapi/cgi/cgi_main.c:2236 Further investigation has shown that active_opline is NULL: (gdb) f 0 #0 0x0052d7d1 in zend_get_executed_lineno () at /shared/misc/standard/php.src/php-4.4.7/Zend/zend_execute_API.c:269 269 /shared/misc/standard/php.src/php-4.4.7/Zend/zend_execute_API.c: No such file or directory. in /shared/misc/standard/php.src/php-4.4.7/Zend/zend_execute_API.c (gdb) p executor_globals.opline_ptr $3 = (zend_op **) 0x7fbfff9510 (gdb) p *executor_globals.opline_ptr $4 = (zend_op *) 0x0 -- Edit bug report at http://bugs.php.net/?id=43136&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43136&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43136&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43136&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43136&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43136&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43136&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43136&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43136&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43136&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43136&r=support Expected behavior:http://bugs.php.net/fix.php?id=43136&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43136&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43136&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43136&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43136&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43136&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43136&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43136&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43136&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43136&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43136&r=mysqlcfg
#43128 [Opn->Ana]: Long name cause seg. fault
ID: 43128 Updated by: [EMAIL PROTECTED] Reported By: felipensp at gmail dot com -Status: Open +Status: Analyzed Bug Type: Reproducible crash Operating System: Linux PHP Version: 5.3CVS-2007-10-29 (snap) New Comment: Segfaults for me too, looks like a stack smash with valgrind: ==7344== Warning: client switching stacks? SP change: 0x7FEFFD9A0 --> 0x7FE674310 ==7344== to suppress, use: --max-stackframe=1016 or greater ==7344== Invalid write of size 8 ==7344==at 0x85D4D3: zend_lookup_class_ex (zend_execute_API.c:1046) ==7344== Address 0x7FE674308 is on thread 1's stack ==7344== ==7344== Process terminating with default action of signal 11 (SIGSEGV) ==7344== Access not within mapped region at address 0x7FE674308 ==7344==at 0x85D4D3: zend_lookup_class_ex (zend_execute_API.c:1046) ==7344== ==7344== Invalid write of size 8 ==7344==at 0x4A1E310: _vgnU_freeres (vg_preloaded.c:56) ==7344== Address 0x7FE674300 is on thread 1's stack ==7344== ==7344== Process terminating with default action of signal 11 (SIGSEGV) ==7344== Access not within mapped region at address 0x7FE674300 Which makes sense, as lc_name in zend_lookup_class_ex() is allocated on line 1045 with: lc_name = do_alloca(name_length + 1); zend_str_tolower_copy(lc_name, name, name_length); SPL and Reflection have the same problem in the files: ext/spl/php_spl.c ext/reflection/php_reflection.c A possible fix would be to set an arbitrary limit on the name of classes here... Previous Comments: [2007-10-30 00:14:09] crrodriguez at suse dot de Always reproducible on linux64 bit hosts. [2007-10-29 23:46:15] felipensp at gmail dot com PHP 5.2.5RC2-dev (cli) (built: Oct 29 2007 21:22:10): Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1211684448 (LWP 31245)] zend_lookup_class_ex (name=0xb722e018 'a' ..., name_length=1000, use_autoload=0, ce=0xbfa0c498) at /home/felipe/php5.2-200710292130/Zend/zend_execute_API.c:1046 1046zend_str_tolower_copy(lc_name, name, name_length); [2007-10-29 22:24:54] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi I've tried both PHP 5.2 and 5.3 and cannot reproduce the crash. [2007-10-29 17:25:28] felipensp at gmail dot com Description: Long names cause segmentation fault in 'instanceof' and 'new' operators. Reproduce code: --- $a(); // Fatal error if ($a instanceof $a); // Segmentation fault new $a;// Segmentation fault Expected result: Warning / Fatal error Actual result: -- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1214703296 (LWP 4538)] zend_lookup_class_ex (name=0xb6f4d018 'a' ..., name_length=1000, use_autoload=0, ce=0xbf9644d8) at /home/felipe/php5.3-200710261430/Zend/zend_execute_API.c:1078 1078in /home/felipe/php5.3-200710261430/Zend/zend_execute_API.c Backtrace: -- #0 zend_lookup_class_ex (name=0xb6ece018 'a' ..., name_length=1000, use_autoload=0, ce=0xbfb896f8) at /home/felipe/php5.3-200710261430/Zend/zend_execute_API.c:1078 #1 0x08277d9f in zend_fetch_class ( class_name=0xb6ece018 'a' ..., class_name_len=1000, fetch_type=132) at /home/felipe/php5.3-200710261430/Zend/zend_execute_API.c:1548 #2 0x082c26c9 in ZEND_FETCH_CLASS_SPEC_CV_HANDLER (execute_data=0xbfb8982c) at /home/felipe/php5.3-200710261430/Zend/zend_vm_execute.h:1065 #3 0x0829ef1b in execute (op_array=0x84a6900) at /home/felipe/php5.3-200710261430/Zend/zend_vm_execute.h:87 #4 0x08281952 in zend_execute_scripts (type=8, retval=, file_count=3) at /home/felipe/php5.3-200710261430/Zend/zend.c:1137 #5 0x0823d841 in php_execute_script (primary_file=0xbfb8bbcc) at /home/felipe/php5.3-200710261430/main/main.c:2007 #6 0x08301c65 in main (argc=2, argv=0xbfb8bce4) at /home/felipe/php5.3-200710261430/sapi/cli/php_cli.c:1140 -- Edit this bug report at http://bugs.php.net/?id=43128&edit=1
#43133 [Opn->Fbk]: Mktime bug
ID: 43133 Updated by: [EMAIL PROTECTED] Reported By: machineextractor at yahoo dot com -Status: Open +Status: Feedback Bug Type: PHP options/info functions Operating System: Windows Xp PHP Version: 5.2.4 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2007-10-30 00:14:32] carsten_sttgt at gmx dot de "mktime(0, 0, 0, 3, 0, 2040)" is out of the range of a valid unix timestamp. This call returns FALSE here (PHP-CLI 5.2.4 /XP), which is correct. You are using more functions then mktime()? Regards, Carsten [2007-10-29 23:39:07] machineextractor at yahoo dot com Description: The function maketime has a bug If i want to know how many days are in february 2040 the function return 31. february does not have more than 29 days -- Edit this bug report at http://bugs.php.net/?id=43133&edit=1
