#38988 [NEW]: Chaning mssql.datetimeconvert has no effect
From: wiggum24 at gmail dot com Operating system: Redhat Enterprise Linux PHP version: 5.1.6 PHP Bug Type: MSSQL related Bug description: Chaning mssql.datetimeconvert has no effect Description: Trying to set mssql.datetimeconvert to Off in php.ini doesn't work. phpinfo() reports it as On, and the behaviour of the recordset reflects the same. I've confirmed php is picking up the correct php.ini, and my php.ini contains no errors. Calling ini_set(mssql.datetimeconvert,Off); before I do the query will set the value and the queries will return correctly. Reproduce code: --- No errors, the setting just doesn't apply. Expected result: datetimes should appear as: 2006-07-20 16:32:00 Actual result: -- datetimes appear as: Jul 20 2006 04:32PM -- Edit bug report at http://bugs.php.net/?id=38988edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38988r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38988r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38988r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38988r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38988r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38988r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38988r=needscript Try newer version:http://bugs.php.net/fix.php?id=38988r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38988r=support Expected behavior:http://bugs.php.net/fix.php?id=38988r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38988r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38988r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38988r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38988r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38988r=dst IIS Stability:http://bugs.php.net/fix.php?id=38988r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38988r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38988r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38988r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38988r=mysqlcfg
#38989 [NEW]: Absolute path with slash at beginning doesn't work
From: info at xboot dot de Operating system: Windows 2003 SP1 PHP version: 5CVS-2006-09-29 (snap) PHP Bug Type: Filesystem function related Bug description: Absolute path with slash at beginning doesn't work Description: System: Win 2003 SP1 IIS 6 PHP 5.2.0RC5-dev (29.09.2006) File operations with slash at the beginning (absolute path) don't work. It doesn't matter which kind of function i use. include(), fopen(), SPL-functions, ... don't work if i pass a filename with a slash at the beginning. If i add the drive letter it works correct. The same script works fine with PHP 5.1.2. Reproduce code: --- ?php echo $_SERVER['PHP_SELF'] . 'br /'; $handle = fopen($_SERVER['PHP_SELF'], r); // this is the same file, but it works: // $handle = fopen(D:\Intranet\path.php, r); echo $handle; ? Expected result: Result with PHP 5.1.2: /intranet/path.php Resource id #2 Actual result: -- Result with PHP Version 5.2.0RC5-dev (29.09.2006): /intranet/path.php Warning: fopen(/intranet/path.php) [function.fopen]: failed to open stream: No such file or directory in D:\Intranet\path.php on line 5 -- Edit bug report at http://bugs.php.net/?id=38989edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38989r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38989r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38989r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38989r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38989r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38989r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38989r=needscript Try newer version:http://bugs.php.net/fix.php?id=38989r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38989r=support Expected behavior:http://bugs.php.net/fix.php?id=38989r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38989r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38989r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38989r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38989r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38989r=dst IIS Stability:http://bugs.php.net/fix.php?id=38989r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38989r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38989r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38989r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38989r=mysqlcfg
#38989 [Opn]: Absolute path with slash at beginning doesn't work
ID: 38989 User updated by: info at xboot dot de Reported By: info at xboot dot de Status: Open Bug Type: Filesystem function related Operating System: Windows 2003 SP1 PHP Version: 5CVS-2006-09-29 (snap) New Comment: PHP runs as ISAPI Previous Comments: [2006-09-29 07:45:59] info at xboot dot de Description: System: Win 2003 SP1 IIS 6 PHP 5.2.0RC5-dev (29.09.2006) File operations with slash at the beginning (absolute path) don't work. It doesn't matter which kind of function i use. include(), fopen(), SPL-functions, ... don't work if i pass a filename with a slash at the beginning. If i add the drive letter it works correct. The same script works fine with PHP 5.1.2. Reproduce code: --- ?php echo $_SERVER['PHP_SELF'] . 'br /'; $handle = fopen($_SERVER['PHP_SELF'], r); // this is the same file, but it works: // $handle = fopen(D:\Intranet\path.php, r); echo $handle; ? Expected result: Result with PHP 5.1.2: /intranet/path.php Resource id #2 Actual result: -- Result with PHP Version 5.2.0RC5-dev (29.09.2006): /intranet/path.php Warning: fopen(/intranet/path.php) [function.fopen]: failed to open stream: No such file or directory in D:\Intranet\path.php on line 5 -- Edit this bug report at http://bugs.php.net/?id=38989edit=1
#38990 [NEW]: Pear doesn't install
From: bailemoselbimbo at gmail dot com Operating system: Solaris 9 PHP version: 4.4.4 PHP Bug Type: *Compile Issues Bug description: Pear doesn't install Description: The config script detects that i don't want to install pear, despite i don't put --without-pear in any moment, in the output it says that it does'nt have to ve installed This is the configure # ./configure --prefix=/aplicacions/php-4.4.4 --enable-fastcgi --enable-force-cgi-redirect --enable-discard-path --with -pear=/aplicacions/php-4.4.4/pear --disable-cli --with-zlib --enable-exif --with-jpeg-dir=/usr/local/lib --with-png-dir= /usr/local/lib --with-pgsql=/aplicacions/postgres --with-openssl=/usr/local/ssl --enable-calendar --enable-ftp --with-gn u-ld --with-gd --with-dom=/usr/local --with-dom-xslt=/usr/local --with-domxml --enable-mbstring --with-mysql=/aplicacion s/mysql And on the output: ^[[1mConfiguring PEAR^[[m checking whether to install PEAR... no In the error output, only a warning not related to this: configure: warning: You will need bison 1.28 PEAR installs as default i think ... The binary for pear is not on the final compilation result -- Edit bug report at http://bugs.php.net/?id=38990edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38990r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38990r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38990r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38990r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38990r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38990r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38990r=needscript Try newer version:http://bugs.php.net/fix.php?id=38990r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38990r=support Expected behavior:http://bugs.php.net/fix.php?id=38990r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38990r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38990r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38990r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38990r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38990r=dst IIS Stability:http://bugs.php.net/fix.php?id=38990r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38990r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38990r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38990r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38990r=mysqlcfg
#38882 [Fbk-Opn]: ldap_connect causes Segmentation fault
ID: 38882 User updated by: d dot wynne at ljmu dot ac dot uk Reported By: d dot wynne at ljmu dot ac dot uk -Status: Feedback +Status: Open Bug Type: LDAP related Operating System: SuSE 10.1 x86_64 PHP Version: 4.4.4 New Comment: This is my php-4.4.4 --without-mysql variant. The production apache module I normally use obviously has MySQL support Using browser to test MySQL connections PEAR DB Error: extension not found Standard Fatal error: Call to undefined function: mysql_connect() in /home/ftpserver/www/homepage/staff/cmsdwynn/php/mysqlconn.php on line 2 Backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47225668576928 (LWP 31755)] 0x2af39405c481 in ldap_unbind_ext () from /usr/lib64/libldap-2.3.so.0 (gdb)bt #0 0x2af39405c481 in ldap_unbind_ext () from /usr/lib64/libldap-2.3.so.0 #1 0x2af396202c9e in _close_ldap_link (rsrc=value optimized out) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/ldap/ldap.c:175 #2 0x2af3962c46fe in list_entry_destructor (ptr=value optimized out) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_list.c:177 #3 0x2af3962c403a in zend_hash_del_key_or_index (ht=0x2af396449268, arKey=0x0, nKeyLength=0, h=6, flag=value optimized out) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_hash.c:529 #4 0x2af3962c4907 in _zend_list_delete (id=value optimized out) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_list.c:56 #5 0x2af3962b4a76 in _zval_ptr_dtor (zval_ptr=0x55931330) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_execute_API.c:289 #6 0x2af3962c2688 in zend_hash_clean (ht=0x559030e8) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_hash.c:584 #7 0x2af3962d2d69 in execute (op_array=0x55911b98) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_execute.c:1736 #8 0x2af3962d0a29 in execute (op_array=0x558e3ff8) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_execute.c:1719 #9 0x2af3962bd2a9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend.c:934 #10 0x2af39628ee57 in php_execute_script (primary_file=0x7fff16f175d0) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/main/main.c:1752 #11 0x2af3962dafc1 in php_handler (r=0x558e81d8) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/sapi/apache2handler/sapi_apache2.c:581 #12 0x5558c6ba in ap_run_handler () from /usr/sbin/httpd2-prefork #13 0x5558faa2 in ap_invoke_handler () from /usr/sbin/httpd2-prefork #14 0x5559a1c8 in ap_process_request () from /usr/sbin/httpd2-prefork #15 0x55597409 in ap_register_input_filter () from /usr/sbin/httpd2-prefork #16 0x55593772 in ap_run_process_connection () from /usr/sbin/httpd2-prefork #17 0x5559dc09 in ap_graceful_stop_signalled () from /usr/sbin/httpd2-prefork #18 0x5559de0e in ap_graceful_stop_signalled () from /usr/sbin/httpd2-prefork #19 0x5559e911 in ap_mpm_run () from /usr/sbin/httpd2-prefork #20 0x55579cb8 in main () from /usr/sbin/httpd2-prefork (gdb) Previous Comments: [2006-09-28 16:16:36] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2006-09-28 16:08:29] d dot wynne at ljmu dot ac dot uk Now I've implicitly rebuilt php-4.4.4 --without-mysql. Installed and tested that indeed MySQL connections fail, and they do. Still Segmentation fault on ldap_connect. [2006-09-27 16:16:17] d dot wynne at ljmu dot ac dot uk Right I've now compiled MySQL from source code. I'm using the mysql-5.0.18-src RPM as this matches exacly the binary RPM that comes with SuSE 10.1. Configure MySQL: ./configure --prefix=/usr --without-yassl --enable-thread-safe-client --with-gnu-ld --without-server --with-named-curses-libs=/usr/lib64/curses/libcurses.a --without-yassl I believe is the significant part. Built installed Checked the libraries header files are in the right place: ldconfig Re-built php from scratch. Configure as before. Installed restarted Apache2. Same result. Segmentation fault on ldap_connect. Please help. [2006-09-20 09:54:42] d dot wynne at ljmu dot ac dot uk Upgraded all 3 MySQl packages
#38988 [Opn-Fbk]: Chaning mssql.datetimeconvert has no effect
ID: 38988 Updated by: [EMAIL PROTECTED] Reported By: wiggum24 at gmail dot com -Status: Open +Status: Feedback Bug Type: MSSQL related Operating System: Redhat Enterprise Linux PHP Version: 5.1.6 New Comment: Trying to set mssql.datetimeconvert to Off in php.ini doesn't work. phpinfo() reports it as On, and the behaviour of the recordset reflects the same. Which php.ini is used by PHP according to phpinfo()? Which php.ini did you change? Did you restart the web-server? Previous Comments: [2006-09-29 06:47:39] wiggum24 at gmail dot com Description: Trying to set mssql.datetimeconvert to Off in php.ini doesn't work. phpinfo() reports it as On, and the behaviour of the recordset reflects the same. I've confirmed php is picking up the correct php.ini, and my php.ini contains no errors. Calling ini_set(mssql.datetimeconvert,Off); before I do the query will set the value and the queries will return correctly. Reproduce code: --- No errors, the setting just doesn't apply. Expected result: datetimes should appear as: 2006-07-20 16:32:00 Actual result: -- datetimes appear as: Jul 20 2006 04:32PM -- Edit this bug report at http://bugs.php.net/?id=38988edit=1
#38990 [Opn-Bgs]: Pear doesn't install
ID: 38990 Updated by: [EMAIL PROTECTED] Reported By: bailemoselbimbo at gmail dot com -Status: Open +Status: Bogus Bug Type: *Compile Issues Operating System: Solaris 9 PHP Version: 4.4.4 New Comment: ./configure --help: .. --disable-cli Disable building CLI version of PHP (this forces --without-pear). Previous Comments: [2006-09-29 08:48:54] bailemoselbimbo at gmail dot com Description: The config script detects that i don't want to install pear, despite i don't put --without-pear in any moment, in the output it says that it does'nt have to ve installed This is the configure # ./configure --prefix=/aplicacions/php-4.4.4 --enable-fastcgi --enable-force-cgi-redirect --enable-discard-path --with -pear=/aplicacions/php-4.4.4/pear --disable-cli --with-zlib --enable-exif --with-jpeg-dir=/usr/local/lib --with-png-dir= /usr/local/lib --with-pgsql=/aplicacions/postgres --with-openssl=/usr/local/ssl --enable-calendar --enable-ftp --with-gn u-ld --with-gd --with-dom=/usr/local --with-dom-xslt=/usr/local --with-domxml --enable-mbstring --with-mysql=/aplicacion s/mysql And on the output: ^[[1mConfiguring PEAR^[[m checking whether to install PEAR... no In the error output, only a warning not related to this: configure: warning: You will need bison 1.28 PEAR installs as default i think ... The binary for pear is not on the final compilation result -- Edit this bug report at http://bugs.php.net/?id=38990edit=1
#38882 [Opn-Fbk]: ldap_connect causes Segmentation fault
ID: 38882 Updated by: [EMAIL PROTECTED] Reported By: d dot wynne at ljmu dot ac dot uk -Status: Open +Status: Feedback Bug Type: LDAP related Operating System: SuSE 10.1 x86_64 PHP Version: 4.4.4 New Comment: Does valgrind show you anything useful? A segfault somewhere in OpenLDAP doesn't look like PHP problem so far. Previous Comments: [2006-09-29 08:53:59] d dot wynne at ljmu dot ac dot uk This is my php-4.4.4 --without-mysql variant. The production apache module I normally use obviously has MySQL support Using browser to test MySQL connections PEAR DB Error: extension not found Standard Fatal error: Call to undefined function: mysql_connect() in /home/ftpserver/www/homepage/staff/cmsdwynn/php/mysqlconn.php on line 2 Backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47225668576928 (LWP 31755)] 0x2af39405c481 in ldap_unbind_ext () from /usr/lib64/libldap-2.3.so.0 (gdb)bt #0 0x2af39405c481 in ldap_unbind_ext () from /usr/lib64/libldap-2.3.so.0 #1 0x2af396202c9e in _close_ldap_link (rsrc=value optimized out) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/ldap/ldap.c:175 #2 0x2af3962c46fe in list_entry_destructor (ptr=value optimized out) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_list.c:177 #3 0x2af3962c403a in zend_hash_del_key_or_index (ht=0x2af396449268, arKey=0x0, nKeyLength=0, h=6, flag=value optimized out) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_hash.c:529 #4 0x2af3962c4907 in _zend_list_delete (id=value optimized out) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_list.c:56 #5 0x2af3962b4a76 in _zval_ptr_dtor (zval_ptr=0x55931330) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_execute_API.c:289 #6 0x2af3962c2688 in zend_hash_clean (ht=0x559030e8) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_hash.c:584 #7 0x2af3962d2d69 in execute (op_array=0x55911b98) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_execute.c:1736 #8 0x2af3962d0a29 in execute (op_array=0x558e3ff8) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_execute.c:1719 #9 0x2af3962bd2a9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend.c:934 #10 0x2af39628ee57 in php_execute_script (primary_file=0x7fff16f175d0) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/main/main.c:1752 #11 0x2af3962dafc1 in php_handler (r=0x558e81d8) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/sapi/apache2handler/sapi_apache2.c:581 #12 0x5558c6ba in ap_run_handler () from /usr/sbin/httpd2-prefork #13 0x5558faa2 in ap_invoke_handler () from /usr/sbin/httpd2-prefork #14 0x5559a1c8 in ap_process_request () from /usr/sbin/httpd2-prefork #15 0x55597409 in ap_register_input_filter () from /usr/sbin/httpd2-prefork #16 0x55593772 in ap_run_process_connection () from /usr/sbin/httpd2-prefork #17 0x5559dc09 in ap_graceful_stop_signalled () from /usr/sbin/httpd2-prefork #18 0x5559de0e in ap_graceful_stop_signalled () from /usr/sbin/httpd2-prefork #19 0x5559e911 in ap_mpm_run () from /usr/sbin/httpd2-prefork #20 0x55579cb8 in main () from /usr/sbin/httpd2-prefork (gdb) [2006-09-28 16:16:36] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2006-09-28 16:08:29] d dot wynne at ljmu dot ac dot uk Now I've implicitly rebuilt php-4.4.4 --without-mysql. Installed and tested that indeed MySQL connections fail, and they do. Still Segmentation fault on ldap_connect. [2006-09-27 16:16:17] d dot wynne at ljmu dot ac dot uk Right I've now compiled MySQL from source code. I'm using the mysql-5.0.18-src RPM as this matches exacly the binary RPM that comes with SuSE 10.1. Configure MySQL: ./configure --prefix=/usr --without-yassl --enable-thread-safe-client --with-gnu-ld --without-server --with-named-curses-libs=/usr/lib64/curses/libcurses.a --without-yassl I believe is the significant part. Built installed Checked the libraries header files are in the right place: ldconfig Re-built php from scratch. Configure as before. Installed restarted
#38990 [Bgs]: Pear doesn't install
ID: 38990 User updated by: bailemoselbimbo at gmail dot com Reported By: bailemoselbimbo at gmail dot com Status: Bogus Bug Type: *Compile Issues Operating System: Solaris 9 PHP Version: 4.4.4 New Comment: Ops! Sorry by the inconvenience :( Previous Comments: [2006-09-29 09:12:14] [EMAIL PROTECTED] ./configure --help: .. --disable-cli Disable building CLI version of PHP (this forces --without-pear). [2006-09-29 08:48:54] bailemoselbimbo at gmail dot com Description: The config script detects that i don't want to install pear, despite i don't put --without-pear in any moment, in the output it says that it does'nt have to ve installed This is the configure # ./configure --prefix=/aplicacions/php-4.4.4 --enable-fastcgi --enable-force-cgi-redirect --enable-discard-path --with -pear=/aplicacions/php-4.4.4/pear --disable-cli --with-zlib --enable-exif --with-jpeg-dir=/usr/local/lib --with-png-dir= /usr/local/lib --with-pgsql=/aplicacions/postgres --with-openssl=/usr/local/ssl --enable-calendar --enable-ftp --with-gn u-ld --with-gd --with-dom=/usr/local --with-dom-xslt=/usr/local --with-domxml --enable-mbstring --with-mysql=/aplicacion s/mysql And on the output: ^[[1mConfiguring PEAR^[[m checking whether to install PEAR... no In the error output, only a warning not related to this: configure: warning: You will need bison 1.28 PEAR installs as default i think ... The binary for pear is not on the final compilation result -- Edit this bug report at http://bugs.php.net/?id=38990edit=1
#38882 [Fbk-Opn]: ldap_connect causes Segmentation fault
ID: 38882 User updated by: d dot wynne at ljmu dot ac dot uk Reported By: d dot wynne at ljmu dot ac dot uk -Status: Feedback +Status: Open Bug Type: LDAP related Operating System: SuSE 10.1 x86_64 PHP Version: 4.4.4 New Comment: Not used valgrind at all, but I've done a bit of searching I've found someone else with exactly the same problme as I'm having. The exact version of PHP is not mentioned, but the same backtrace including: #0 0x2b1f2151 in ldap_unbind_ext () from /usr/lib64/libldap-2.3.so.0 is. Also it's 64 bit linux and the same version of Apache ( 2.2.0 ). He claims that the code works using the PHP CLI. I have tested this with: #! /usr/bin/php ?php $ldapServer = bydc1.jmu.ac.uk; echo pConnecting/p\n; $ds=ldap_connect($ldapServer); echo pDisconnecting/p\n; ldap_close($ds); ? and indeed it does. No Segmentatio fault. Does that mean that PHP / MySQL / LDAP are all red herringd and the culprit could be Apache, as the CLI version works, and the problem only occurs when running it through a browser ? Previous Comments: [2006-09-29 09:13:51] [EMAIL PROTECTED] Does valgrind show you anything useful? A segfault somewhere in OpenLDAP doesn't look like PHP problem so far. [2006-09-29 08:53:59] d dot wynne at ljmu dot ac dot uk This is my php-4.4.4 --without-mysql variant. The production apache module I normally use obviously has MySQL support Using browser to test MySQL connections PEAR DB Error: extension not found Standard Fatal error: Call to undefined function: mysql_connect() in /home/ftpserver/www/homepage/staff/cmsdwynn/php/mysqlconn.php on line 2 Backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47225668576928 (LWP 31755)] 0x2af39405c481 in ldap_unbind_ext () from /usr/lib64/libldap-2.3.so.0 (gdb)bt #0 0x2af39405c481 in ldap_unbind_ext () from /usr/lib64/libldap-2.3.so.0 #1 0x2af396202c9e in _close_ldap_link (rsrc=value optimized out) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/ldap/ldap.c:175 #2 0x2af3962c46fe in list_entry_destructor (ptr=value optimized out) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_list.c:177 #3 0x2af3962c403a in zend_hash_del_key_or_index (ht=0x2af396449268, arKey=0x0, nKeyLength=0, h=6, flag=value optimized out) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_hash.c:529 #4 0x2af3962c4907 in _zend_list_delete (id=value optimized out) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_list.c:56 #5 0x2af3962b4a76 in _zval_ptr_dtor (zval_ptr=0x55931330) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_execute_API.c:289 #6 0x2af3962c2688 in zend_hash_clean (ht=0x559030e8) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_hash.c:584 #7 0x2af3962d2d69 in execute (op_array=0x55911b98) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_execute.c:1736 #8 0x2af3962d0a29 in execute (op_array=0x558e3ff8) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_execute.c:1719 #9 0x2af3962bd2a9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend.c:934 #10 0x2af39628ee57 in php_execute_script (primary_file=0x7fff16f175d0) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/main/main.c:1752 #11 0x2af3962dafc1 in php_handler (r=0x558e81d8) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/sapi/apache2handler/sapi_apache2.c:581 #12 0x5558c6ba in ap_run_handler () from /usr/sbin/httpd2-prefork #13 0x5558faa2 in ap_invoke_handler () from /usr/sbin/httpd2-prefork #14 0x5559a1c8 in ap_process_request () from /usr/sbin/httpd2-prefork #15 0x55597409 in ap_register_input_filter () from /usr/sbin/httpd2-prefork #16 0x55593772 in ap_run_process_connection () from /usr/sbin/httpd2-prefork #17 0x5559dc09 in ap_graceful_stop_signalled () from /usr/sbin/httpd2-prefork #18 0x5559de0e in ap_graceful_stop_signalled () from /usr/sbin/httpd2-prefork #19 0x5559e911 in ap_mpm_run () from /usr/sbin/httpd2-prefork #20 0x55579cb8 in main () from /usr/sbin/httpd2-prefork (gdb) [2006-09-28 16:16:36] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better.
#38991 [NEW]: Can not post HTML-Tags
From: info at optima-software dot de
Operating system: Linux version 2.6.17-gentoo-r4
PHP version: 5.1.6
PHP Bug Type: *Configuration Issues
Bug description: Can not post HTML-Tags
Description:
Since the last php-update I can not POST html-tags inside a string. If I
create a simple form within a textarea, after submit var_dump($_POST)
outputs just plain-text without the html-tags. As a result of that, all
CMS on my server don't work anymore.
See what I did inside the code-area.
PHP Version 5.1.6-pl4-gentoo
configure command
'./configure' '--prefix=/usr/lib/php5' '--host=i686-pc-linux-gnu'
'--mandir=/usr/lib/php5/man' '--infodir=/usr/lib/php5/info'
'--sysconfdir=/etc' '--cache-file=./config.cache' '--disable-cli'
'--with-apxs2=/usr/sbin/apxs2'
'--with-config-file-path=/etc/php/apache2-php5'
'--with-config-file-scan-dir=/etc/php/apache2-php5/ext-active'
'--without-pear' '--enable-bcmath' '--with-bz2' '--enable-calendar'
'--disable-ctype' '--with-curl' '--without-curlwrappers' '--disable-dbase'
'--disable-exif' '--without-fbsql' '--without-fdftk' '--disable-filepro'
'--enable-ftp' '--with-gettext' '--with-gmp' '--disable-hash'
'--without-hwapi' '--without-informix' '--without-kerberos'
'--enable-mbstring' '--with-mcrypt' '--disable-memory-limit'
'--without-mhash' '--without-ming' '--without-msql' '--without-mssql'
'--with-ncurses' '--with-openssl' '--with-openssl-dir=/usr'
'--disable-pcntl' '--with-pgsql' '--disable-posix' '--without-pspell'
'--without-recode' '--disable-simplexml' '--disable-shmop'
'--without-snmp' '--enable-soap' '--enable-sockets' '--without-sybase'
'--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem'
'--disable-sysvshm' '--with-tidy' '--disable-tokenizer' '--disable-wddx'
'--with-xmlrpc' '--without-xsl' '--with-zlib' '--disable-debug'
'--enable-dba' '--without-cdb' '--with-db4' '--without-flatfile'
'--with-gdbm' '--with-inifile' '--without-qdbm' '--with-freetype-dir=/usr'
'--with-t1lib=/usr' '--disable-gd-jis-conv' '--enable-gd-native-ttf'
'--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr/X11R6'
'--with-gd' '--with-mysql=/usr/lib/mysql'
'--with-mysql-sock=/var/run/mysqld/mysqld.sock'
'--with-mysqli=/usr/bin/mysql_config' '--without-pdo-dblib'
'--with-pdo-mysql=/usr' '--without-pdo-odbc' '--with-pdo-pgsql'
'--with-pdo-sqlite=/usr' '--with-readline' '--without-libedit'
'--without-mm' '--with-sqlite=/usr' '--enable-sqlite-utf8'
Reproduce code:
---
form action=# method=post
fieldset style=width: 300px; margin: auto;
legendA simple form/legend
label for=id_textareaInput some text with html-tags
here/labelbr /
textarea id=id_textarea name=text rows=10
cols=50/textareabr /
input type=submit name=name value=Submit/
/fieldset
/form
br /
?php
if ( isset ($_POST['text']) ){
$output = 'div' . \r\n;
$output .= \t . 'h2The output of $_POST inside a pre-tag/h2' .
\r\n;
$output .= \t . 'pre style=border: 1px solid #ccc; padding:
5px;';
$output .= $_POST['text'];
$output .= '/pre' . \r\n;
$output .= '/div' . \r\n;
echo($output);
}
?
Expected result:
Output of the string I sent.
Actual result:
--
Output of plain-text without html-tags
--
Edit bug report at http://bugs.php.net/?id=38991edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38991r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38991r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38991r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38991r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38991r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38991r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38991r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38991r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38991r=support
Expected behavior:http://bugs.php.net/fix.php?id=38991r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38991r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38991r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38991r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38991r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38991r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38991r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38991r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38991r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38991r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38991r=mysqlcfg
#38991 [Opn-Bgs]: Can not post HTML-Tags
ID: 38991
Updated by: [EMAIL PROTECTED]
Reported By: info at optima-software dot de
-Status: Open
+Status: Bogus
Bug Type: *Configuration Issues
Operating System: Linux version 2.6.17-gentoo-r4
PHP Version: 5.1.6
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Previous Comments:
[2006-09-29 10:31:34] info at optima-software dot de
Description:
Since the last php-update I can not POST html-tags inside a string. If
I create a simple form within a textarea, after submit var_dump($_POST)
outputs just plain-text without the html-tags. As a result of that, all
CMS on my server don't work anymore.
See what I did inside the code-area.
PHP Version 5.1.6-pl4-gentoo
configure command
'./configure' '--prefix=/usr/lib/php5' '--host=i686-pc-linux-gnu'
'--mandir=/usr/lib/php5/man' '--infodir=/usr/lib/php5/info'
'--sysconfdir=/etc' '--cache-file=./config.cache' '--disable-cli'
'--with-apxs2=/usr/sbin/apxs2'
'--with-config-file-path=/etc/php/apache2-php5'
'--with-config-file-scan-dir=/etc/php/apache2-php5/ext-active'
'--without-pear' '--enable-bcmath' '--with-bz2' '--enable-calendar'
'--disable-ctype' '--with-curl' '--without-curlwrappers'
'--disable-dbase' '--disable-exif' '--without-fbsql' '--without-fdftk'
'--disable-filepro' '--enable-ftp' '--with-gettext' '--with-gmp'
'--disable-hash' '--without-hwapi' '--without-informix'
'--without-kerberos' '--enable-mbstring' '--with-mcrypt'
'--disable-memory-limit' '--without-mhash' '--without-ming'
'--without-msql' '--without-mssql' '--with-ncurses' '--with-openssl'
'--with-openssl-dir=/usr' '--disable-pcntl' '--with-pgsql'
'--disable-posix' '--without-pspell' '--without-recode'
'--disable-simplexml' '--disable-shmop' '--without-snmp'
'--enable-soap' '--enable-sockets' '--without-sybase'
'--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem'
'--disable-sysvshm' '--with-tidy' '--disable-tokenizer'
'--disable-wddx' '--with-xmlrpc' '--without-xsl' '--with-zlib'
'--disable-debug' '--enable-dba' '--without-cdb' '--with-db4'
'--without-flatfile' '--with-gdbm' '--with-inifile' '--without-qdbm'
'--with-freetype-dir=/usr' '--with-t1lib=/usr' '--disable-gd-jis-conv'
'--enable-gd-native-ttf' '--with-jpeg-dir=/usr' '--with-png-dir=/usr'
'--with-xpm-dir=/usr/X11R6' '--with-gd' '--with-mysql=/usr/lib/mysql'
'--with-mysql-sock=/var/run/mysqld/mysqld.sock'
'--with-mysqli=/usr/bin/mysql_config' '--without-pdo-dblib'
'--with-pdo-mysql=/usr' '--without-pdo-odbc' '--with-pdo-pgsql'
'--with-pdo-sqlite=/usr' '--with-readline' '--without-libedit'
'--without-mm' '--with-sqlite=/usr' '--enable-sqlite-utf8'
Reproduce code:
---
form action=# method=post
fieldset style=width: 300px; margin: auto;
legendA simple form/legend
label for=id_textareaInput some text with html-tags
here/labelbr /
textarea id=id_textarea name=text rows=10
cols=50/textareabr /
input type=submit name=name value=Submit/
/fieldset
/form
br /
?php
if ( isset ($_POST['text']) ){
$output = 'div' . \r\n;
$output .= \t . 'h2The output of $_POST inside a pre-tag/h2'
. \r\n;
$output .= \t . 'pre style=border: 1px solid #ccc; padding:
5px;';
$output .= $_POST['text'];
$output .= '/pre' . \r\n;
$output .= '/div' . \r\n;
echo($output);
}
?
Expected result:
Output of the string I sent.
Actual result:
--
Output of plain-text without html-tags
--
Edit this bug report at http://bugs.php.net/?id=38991edit=1
#38882 [Opn-Fbk]: ldap_connect causes Segmentation fault
ID: 38882 Updated by: [EMAIL PROTECTED] Reported By: d dot wynne at ljmu dot ac dot uk -Status: Open +Status: Feedback Bug Type: LDAP related Operating System: SuSE 10.1 x86_64 PHP Version: 4.4.4 New Comment: Well, you can also try to compile PHP CLI with --enable-experimental-zts and see if it works for you OR (I'd prefer this one) use Apache 1.x for tests. Previous Comments: [2006-09-29 10:29:41] d dot wynne at ljmu dot ac dot uk Not used valgrind at all, but I've done a bit of searching I've found someone else with exactly the same problme as I'm having. The exact version of PHP is not mentioned, but the same backtrace including: #0 0x2b1f2151 in ldap_unbind_ext () from /usr/lib64/libldap-2.3.so.0 is. Also it's 64 bit linux and the same version of Apache ( 2.2.0 ). He claims that the code works using the PHP CLI. I have tested this with: #! /usr/bin/php ?php $ldapServer = bydc1.jmu.ac.uk; echo pConnecting/p\n; $ds=ldap_connect($ldapServer); echo pDisconnecting/p\n; ldap_close($ds); ? and indeed it does. No Segmentatio fault. Does that mean that PHP / MySQL / LDAP are all red herringd and the culprit could be Apache, as the CLI version works, and the problem only occurs when running it through a browser ? [2006-09-29 09:13:51] [EMAIL PROTECTED] Does valgrind show you anything useful? A segfault somewhere in OpenLDAP doesn't look like PHP problem so far. [2006-09-29 08:53:59] d dot wynne at ljmu dot ac dot uk This is my php-4.4.4 --without-mysql variant. The production apache module I normally use obviously has MySQL support Using browser to test MySQL connections PEAR DB Error: extension not found Standard Fatal error: Call to undefined function: mysql_connect() in /home/ftpserver/www/homepage/staff/cmsdwynn/php/mysqlconn.php on line 2 Backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47225668576928 (LWP 31755)] 0x2af39405c481 in ldap_unbind_ext () from /usr/lib64/libldap-2.3.so.0 (gdb)bt #0 0x2af39405c481 in ldap_unbind_ext () from /usr/lib64/libldap-2.3.so.0 #1 0x2af396202c9e in _close_ldap_link (rsrc=value optimized out) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/ldap/ldap.c:175 #2 0x2af3962c46fe in list_entry_destructor (ptr=value optimized out) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_list.c:177 #3 0x2af3962c403a in zend_hash_del_key_or_index (ht=0x2af396449268, arKey=0x0, nKeyLength=0, h=6, flag=value optimized out) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_hash.c:529 #4 0x2af3962c4907 in _zend_list_delete (id=value optimized out) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_list.c:56 #5 0x2af3962b4a76 in _zval_ptr_dtor (zval_ptr=0x55931330) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_execute_API.c:289 #6 0x2af3962c2688 in zend_hash_clean (ht=0x559030e8) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_hash.c:584 #7 0x2af3962d2d69 in execute (op_array=0x55911b98) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_execute.c:1736 #8 0x2af3962d0a29 in execute (op_array=0x558e3ff8) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_execute.c:1719 #9 0x2af3962bd2a9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend.c:934 #10 0x2af39628ee57 in php_execute_script (primary_file=0x7fff16f175d0) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/main/main.c:1752 #11 0x2af3962dafc1 in php_handler (r=0x558e81d8) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/sapi/apache2handler/sapi_apache2.c:581 #12 0x5558c6ba in ap_run_handler () from /usr/sbin/httpd2-prefork #13 0x5558faa2 in ap_invoke_handler () from /usr/sbin/httpd2-prefork #14 0x5559a1c8 in ap_process_request () from /usr/sbin/httpd2-prefork #15 0x55597409 in ap_register_input_filter () from /usr/sbin/httpd2-prefork #16 0x55593772 in ap_run_process_connection () from /usr/sbin/httpd2-prefork #17 0x5559dc09 in ap_graceful_stop_signalled () from /usr/sbin/httpd2-prefork #18 0x5559de0e in ap_graceful_stop_signalled () from /usr/sbin/httpd2-prefork #19 0x5559e911 in ap_mpm_run () from /usr/sbin/httpd2-prefork #20 0x55579cb8 in main () from /usr/sbin/httpd2-prefork (gdb) [2006-09-28 16:16:36] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read
#38992 [NEW]: ReflectionMethod::invoke() and ::invokeArgs() static method calls should match
From: matthew at zend dot com
Operating system: Debian SID on i686
PHP version: 5.1.6
PHP Bug Type: Feature/Change Request
Bug description: ReflectionMethod::invoke() and ::invokeArgs() static method
calls should match
Description:
ReflectionMethod::invoke() and ReflectionMethod::invokeArgs()
implementations currently do not support the same functionality.
Currently, ReflectionMethod::invoke() can be called using a string class
name as the first argument *if* the method is declared static. However,
ReflectionMethod::invokeArgs(), called the same way, raises a warning and
does not invoke the method:
Warning: ReflectionMethod::invokeArgs() expects parameter 1 to be
object, string given
Calling with a string class name is undocumented currently, but a useful
feature to have. I'd request that invokeArgs() be made to match the
current invoke() functionality, and the documentation updated to indicate
this usage.
Reproduce code:
---
?php
class MyClass
{
public static function doSomething()
{
echo Did it!\n;
}
}
$r = new ReflectionMethod('MyClass', 'doSomething');
$args = array();
$r-invoke('MyClass', array());
$r-invokeArgs('MyClass', $args);
Expected result:
Did it!
Did it!
Actual result:
--
Did it!
Warning: ReflectionMethod::invokeArgs() expects parameter 1 to be object,
string given in ... line 13
--
Edit bug report at http://bugs.php.net/?id=38992edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38992r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38992r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38992r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38992r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38992r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38992r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38992r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38992r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38992r=support
Expected behavior:http://bugs.php.net/fix.php?id=38992r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38992r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38992r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38992r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38992r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38992r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38992r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38992r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38992r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38992r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38992r=mysqlcfg
#38882 [Fbk-Opn]: ldap_connect causes Segmentation fault
ID: 38882 User updated by: d dot wynne at ljmu dot ac dot uk Reported By: d dot wynne at ljmu dot ac dot uk -Status: Feedback +Status: Open Bug Type: LDAP related Operating System: SuSE 10.1 x86_64 PHP Version: 4.4.4 New Comment: Now I'm stuck: a) The PHP build fails if I do --enable-experimental-zts b) SuSE 10.1 only ships with apache2 binary RPM's. I downloaded apache 1.3 source and compiled / installed ran, but httpd just dies, no errors in the loge either. In any case a downgrade to apache 1.3 isn't an option as I have other apache 2.x only modules that I besides PHP. c) No updates on the SuSE update server for either apache2 or openldap. Problem appears to point to OpenLDAP, so all I can think of next is to compile / install the latest build. Maybe this is an anomaly with 64 bit machines, which is why it's reporing is not more widespread. Previous Comments: [2006-09-29 10:43:08] [EMAIL PROTECTED] Well, you can also try to compile PHP CLI with --enable-experimental-zts and see if it works for you OR (I'd prefer this one) use Apache 1.x for tests. [2006-09-29 10:29:41] d dot wynne at ljmu dot ac dot uk Not used valgrind at all, but I've done a bit of searching I've found someone else with exactly the same problme as I'm having. The exact version of PHP is not mentioned, but the same backtrace including: #0 0x2b1f2151 in ldap_unbind_ext () from /usr/lib64/libldap-2.3.so.0 is. Also it's 64 bit linux and the same version of Apache ( 2.2.0 ). He claims that the code works using the PHP CLI. I have tested this with: #! /usr/bin/php ?php $ldapServer = bydc1.jmu.ac.uk; echo pConnecting/p\n; $ds=ldap_connect($ldapServer); echo pDisconnecting/p\n; ldap_close($ds); ? and indeed it does. No Segmentatio fault. Does that mean that PHP / MySQL / LDAP are all red herringd and the culprit could be Apache, as the CLI version works, and the problem only occurs when running it through a browser ? [2006-09-29 09:13:51] [EMAIL PROTECTED] Does valgrind show you anything useful? A segfault somewhere in OpenLDAP doesn't look like PHP problem so far. [2006-09-29 08:53:59] d dot wynne at ljmu dot ac dot uk This is my php-4.4.4 --without-mysql variant. The production apache module I normally use obviously has MySQL support Using browser to test MySQL connections PEAR DB Error: extension not found Standard Fatal error: Call to undefined function: mysql_connect() in /home/ftpserver/www/homepage/staff/cmsdwynn/php/mysqlconn.php on line 2 Backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47225668576928 (LWP 31755)] 0x2af39405c481 in ldap_unbind_ext () from /usr/lib64/libldap-2.3.so.0 (gdb)bt #0 0x2af39405c481 in ldap_unbind_ext () from /usr/lib64/libldap-2.3.so.0 #1 0x2af396202c9e in _close_ldap_link (rsrc=value optimized out) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/ldap/ldap.c:175 #2 0x2af3962c46fe in list_entry_destructor (ptr=value optimized out) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_list.c:177 #3 0x2af3962c403a in zend_hash_del_key_or_index (ht=0x2af396449268, arKey=0x0, nKeyLength=0, h=6, flag=value optimized out) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_hash.c:529 #4 0x2af3962c4907 in _zend_list_delete (id=value optimized out) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_list.c:56 #5 0x2af3962b4a76 in _zval_ptr_dtor (zval_ptr=0x55931330) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_execute_API.c:289 #6 0x2af3962c2688 in zend_hash_clean (ht=0x559030e8) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_hash.c:584 #7 0x2af3962d2d69 in execute (op_array=0x55911b98) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_execute.c:1736 #8 0x2af3962d0a29 in execute (op_array=0x558e3ff8) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_execute.c:1719 #9 0x2af3962bd2a9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend.c:934 #10 0x2af39628ee57 in php_execute_script (primary_file=0x7fff16f175d0) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/main/main.c:1752 #11 0x2af3962dafc1 in php_handler (r=0x558e81d8) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/sapi/apache2handler/sapi_apache2.c:581 #12 0x5558c6ba in ap_run_handler () from /usr/sbin/httpd2-prefork #13 0x5558faa2 in ap_invoke_handler () from /usr/sbin/httpd2-prefork #14 0x5559a1c8 in ap_process_request () from /usr/sbin/httpd2-prefork #15 0x55597409 in ap_register_input_filter () from
#38882 [Opn-Fbk]: ldap_connect causes Segmentation fault
ID: 38882 Updated by: [EMAIL PROTECTED] Reported By: d dot wynne at ljmu dot ac dot uk -Status: Open +Status: Feedback Bug Type: LDAP related Operating System: SuSE 10.1 x86_64 PHP Version: 4.4.4 New Comment: a) The PHP build fails if I do --enable-experimental-zts Please elaborate. Previous Comments: [2006-09-29 14:00:00] d dot wynne at ljmu dot ac dot uk Now I'm stuck: a) The PHP build fails if I do --enable-experimental-zts b) SuSE 10.1 only ships with apache2 binary RPM's. I downloaded apache 1.3 source and compiled / installed ran, but httpd just dies, no errors in the loge either. In any case a downgrade to apache 1.3 isn't an option as I have other apache 2.x only modules that I besides PHP. c) No updates on the SuSE update server for either apache2 or openldap. Problem appears to point to OpenLDAP, so all I can think of next is to compile / install the latest build. Maybe this is an anomaly with 64 bit machines, which is why it's reporing is not more widespread. [2006-09-29 10:43:08] [EMAIL PROTECTED] Well, you can also try to compile PHP CLI with --enable-experimental-zts and see if it works for you OR (I'd prefer this one) use Apache 1.x for tests. [2006-09-29 10:29:41] d dot wynne at ljmu dot ac dot uk Not used valgrind at all, but I've done a bit of searching I've found someone else with exactly the same problme as I'm having. The exact version of PHP is not mentioned, but the same backtrace including: #0 0x2b1f2151 in ldap_unbind_ext () from /usr/lib64/libldap-2.3.so.0 is. Also it's 64 bit linux and the same version of Apache ( 2.2.0 ). He claims that the code works using the PHP CLI. I have tested this with: #! /usr/bin/php ?php $ldapServer = bydc1.jmu.ac.uk; echo pConnecting/p\n; $ds=ldap_connect($ldapServer); echo pDisconnecting/p\n; ldap_close($ds); ? and indeed it does. No Segmentatio fault. Does that mean that PHP / MySQL / LDAP are all red herringd and the culprit could be Apache, as the CLI version works, and the problem only occurs when running it through a browser ? [2006-09-29 09:13:51] [EMAIL PROTECTED] Does valgrind show you anything useful? A segfault somewhere in OpenLDAP doesn't look like PHP problem so far. [2006-09-29 08:53:59] d dot wynne at ljmu dot ac dot uk This is my php-4.4.4 --without-mysql variant. The production apache module I normally use obviously has MySQL support Using browser to test MySQL connections PEAR DB Error: extension not found Standard Fatal error: Call to undefined function: mysql_connect() in /home/ftpserver/www/homepage/staff/cmsdwynn/php/mysqlconn.php on line 2 Backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47225668576928 (LWP 31755)] 0x2af39405c481 in ldap_unbind_ext () from /usr/lib64/libldap-2.3.so.0 (gdb)bt #0 0x2af39405c481 in ldap_unbind_ext () from /usr/lib64/libldap-2.3.so.0 #1 0x2af396202c9e in _close_ldap_link (rsrc=value optimized out) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/ldap/ldap.c:175 #2 0x2af3962c46fe in list_entry_destructor (ptr=value optimized out) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_list.c:177 #3 0x2af3962c403a in zend_hash_del_key_or_index (ht=0x2af396449268, arKey=0x0, nKeyLength=0, h=6, flag=value optimized out) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_hash.c:529 #4 0x2af3962c4907 in _zend_list_delete (id=value optimized out) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_list.c:56 #5 0x2af3962b4a76 in _zval_ptr_dtor (zval_ptr=0x55931330) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_execute_API.c:289 #6 0x2af3962c2688 in zend_hash_clean (ht=0x559030e8) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_hash.c:584 #7 0x2af3962d2d69 in execute (op_array=0x55911b98) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_execute.c:1736 #8 0x2af3962d0a29 in execute (op_array=0x558e3ff8) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend_execute.c:1719 #9 0x2af3962bd2a9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/Zend/zend.c:934 #10 0x2af39628ee57 in php_execute_script (primary_file=0x7fff16f175d0) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/main/main.c:1752 #11 0x2af3962dafc1 in php_handler (r=0x558e81d8) at /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/sapi/apache2handler/sapi_apache2.c:581 #12 0x5558c6ba in ap_run_handler () from /usr/sbin/httpd2-prefork #13 0x5558faa2 in
#38993 [NEW]: Extra options in session.save_path cause verification on update to fail
From: roel at qsp dot nl
Operating system: FreeBSD 6
PHP version: 5.1.6
PHP Bug Type: Session related
Bug description: Extra options in session.save_path cause verification on
update to fail
Description:
Introduction
The file based session handler uses the session.save_path ini variable to
determine where to write it's session files.
However, it also attempts to parse two other bits of information out of
session.save_path, iff session.save_path contains one or two semi-colons.
The format is:
[x;[y;]]pathname
Where both x and y are optional and x is a directory hashing depth for
session files (defaults to 0) and y is the create mode for new session
files, defaults to 0700.
Whenever session.save_path is updated, a verification function is called.
For this variable, this is the funtion static
PHP_INI_MH(OnUpdateSaveDir) contained in ext/session/session.c.
There is no verification in this function if PHP is running in regular
mode. However, when in safe-mode, this function performs two
verifications. First, it attempts to check ownership of the directory, and
secondly, it does a php_check_open_basedir() on the path supplied.
Problem description
---
In this function, OnUpdateSaveDir() in ext/session/session.c, no attempt
is made to recognize and take out the optional parameters contained in the
supplied new session.save_path value.
So, when setting session.save_path to 0;0707;/whatever, PHP will supply
php_checkuid() and php_check_open_basedir with the entire string, not just
with /whatever. This causes the check to fail.
Patch
--
The following patch should be applied to ext/session/session.c to fix this
problem:
*** ext/session/session.orig.c Fri Sep 29 11:35:05 2006
--- ext/session/session.c Fri Sep 29 12:39:26 2006
***
*** 133,145
static PHP_INI_MH(OnUpdateSaveDir)
{
/* Only do the safemode/open_basedir check at runtime */
if (stage == PHP_INI_STAGE_RUNTIME) {
! if (PG(safe_mode) (!php_checkuid(new_value, NULL,
CHECKUID_ALLOW_ONLY_DIR))) {
return FAILURE;
}
! if (php_check_open_basedir(new_value TSRMLS_CC)) {
return FAILURE;
}
}
--- 133,150
static PHP_INI_MH(OnUpdateSaveDir)
{
+ char *p, *q;
+ int i;
/* Only do the safemode/open_basedir check at runtime */
if (stage == PHP_INI_STAGE_RUNTIME) {
! /* Parse out optional hash level file mode */
! for (i=0, q=new_value; i2 (p=strchr(q, ';'))!=NULL;
q=p+1, i++);
!
! if (PG(safe_mode) (!php_checkuid(q, NULL,
CHECKUID_ALLOW_ONLY_DIR))) {
return FAILURE;
}
! if (php_check_open_basedir(q TSRMLS_CC)) {
return FAILURE;
}
}
Remarks
Both parameters are, at least for the most part, undocumented. It would
not be a bad idea to update
the session.save_path description with information about these two
variables.
Submitted: 29/9/2006
Patch author: Roel Bouwman [EMAIL PROTECTED]
Reproduce code:
---
?php
/* Preconditions:
* - server running in safe mode
* - /whatever and this script owned by samed user.
*/
ini_set(session.save_path,0;0707;/whatever);
?
Expected result:
1. PHP checking wether /whatever is owned by script owner.
2. PHP performing basepath check for /whatever
3. session.save_path set to 0;0707;/whatever.
Actual result:
--
PHP will produce an error claiming that it cannot open the save_path
directory as the uid check is performed not just for /whatever, but for
the entire string.
Result is that session.save_path will not be modified.
--
Edit bug report at http://bugs.php.net/?id=38993edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38993r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38993r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38993r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38993r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38993r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38993r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38993r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38993r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38993r=support
Expected behavior:http://bugs.php.net/fix.php?id=38993r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38993r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38993r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38993r=globals
PHP 3 support discontinued:
#38882 [Fbk-Opn]: ldap_connect causes Segmentation fault
ID: 38882 User updated by: d dot wynne at ljmu dot ac dot uk Reported By: d dot wynne at ljmu dot ac dot uk -Status: Feedback +Status: Open Bug Type: LDAP related Operating System: SuSE 10.1 x86_64 PHP Version: 4.4.4 New Comment: . Zend/zend_sprintf.lo Zend/zend_ini.lo Zend/zend_qsort.lo Zend/zend_multibyte.lo Zend/zend_strtod.lo Zend/zend_execute.lo sapi/cli/php_cli.lo sapi/cli/getopt.lo main/internal_functions_cli.lo -lcrypt -lcrypt -lsybdb -lldap -llber -lresolv - lm -ldl -lnsl -lssl -lcrypto -ldl -ldl -lm -lnsl -lirc -lclntsh -lcrypt -lcrypt -o sapi/cli/php ext/standard/info.lo: In function `php_info_print_table_header': /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:756: undefined refere nce to `ts_resource_ex' ext/standard/info.lo: In function `php_info_print_table_row': /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:800: undefined refere nce to `ts_resource_ex' ext/standard/info.lo: In function `php_print_gpcse_array': /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:119: undefined refere nce to `executor_globals_id' ext/standard/info.lo: In function `php_info_write_wrapper': /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:67: undefined referen ce to `ts_resource_ex' ext/standard/info.lo: In function `php_print_info': /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:624: undefined refere nce to `executor_globals_id' /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:554: undefined refere nce to `sapi_globals_id' Previous Comments: [2006-09-29 14:06:23] [EMAIL PROTECTED] a) The PHP build fails if I do --enable-experimental-zts Please elaborate. [2006-09-29 14:00:00] d dot wynne at ljmu dot ac dot uk Now I'm stuck: a) The PHP build fails if I do --enable-experimental-zts b) SuSE 10.1 only ships with apache2 binary RPM's. I downloaded apache 1.3 source and compiled / installed ran, but httpd just dies, no errors in the loge either. In any case a downgrade to apache 1.3 isn't an option as I have other apache 2.x only modules that I besides PHP. c) No updates on the SuSE update server for either apache2 or openldap. Problem appears to point to OpenLDAP, so all I can think of next is to compile / install the latest build. Maybe this is an anomaly with 64 bit machines, which is why it's reporing is not more widespread. [2006-09-29 10:43:08] [EMAIL PROTECTED] Well, you can also try to compile PHP CLI with --enable-experimental-zts and see if it works for you OR (I'd prefer this one) use Apache 1.x for tests. [2006-09-29 10:29:41] d dot wynne at ljmu dot ac dot uk Not used valgrind at all, but I've done a bit of searching I've found someone else with exactly the same problme as I'm having. The exact version of PHP is not mentioned, but the same backtrace including: #0 0x2b1f2151 in ldap_unbind_ext () from /usr/lib64/libldap-2.3.so.0 is. Also it's 64 bit linux and the same version of Apache ( 2.2.0 ). He claims that the code works using the PHP CLI. I have tested this with: #! /usr/bin/php ?php $ldapServer = bydc1.jmu.ac.uk; echo pConnecting/p\n; $ds=ldap_connect($ldapServer); echo pDisconnecting/p\n; ldap_close($ds); ? and indeed it does. No Segmentatio fault. Does that mean that PHP / MySQL / LDAP are all red herringd and the culprit could be Apache, as the CLI version works, and the problem only occurs when running it through a browser ? [2006-09-29 09:13:51] [EMAIL PROTECTED] Does valgrind show you anything useful? A segfault somewhere in OpenLDAP doesn't look like PHP problem so far. 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/38882 -- Edit this bug report at http://bugs.php.net/?id=38882edit=1
#38882 [Opn-Fbk]: ldap_connect causes Segmentation fault
ID: 38882 Updated by: [EMAIL PROTECTED] Reported By: d dot wynne at ljmu dot ac dot uk -Status: Open +Status: Feedback Bug Type: LDAP related Operating System: SuSE 10.1 x86_64 PHP Version: 4.4.4 New Comment: `make clean` is required. Previous Comments: [2006-09-29 14:44:04] d dot wynne at ljmu dot ac dot uk . Zend/zend_sprintf.lo Zend/zend_ini.lo Zend/zend_qsort.lo Zend/zend_multibyte.lo Zend/zend_strtod.lo Zend/zend_execute.lo sapi/cli/php_cli.lo sapi/cli/getopt.lo main/internal_functions_cli.lo -lcrypt -lcrypt -lsybdb -lldap -llber -lresolv - lm -ldl -lnsl -lssl -lcrypto -ldl -ldl -lm -lnsl -lirc -lclntsh -lcrypt -lcrypt -o sapi/cli/php ext/standard/info.lo: In function `php_info_print_table_header': /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:756: undefined refere nce to `ts_resource_ex' ext/standard/info.lo: In function `php_info_print_table_row': /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:800: undefined refere nce to `ts_resource_ex' ext/standard/info.lo: In function `php_print_gpcse_array': /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:119: undefined refere nce to `executor_globals_id' ext/standard/info.lo: In function `php_info_write_wrapper': /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:67: undefined referen ce to `ts_resource_ex' ext/standard/info.lo: In function `php_print_info': /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:624: undefined refere nce to `executor_globals_id' /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:554: undefined refere nce to `sapi_globals_id' [2006-09-29 14:06:23] [EMAIL PROTECTED] a) The PHP build fails if I do --enable-experimental-zts Please elaborate. [2006-09-29 14:00:00] d dot wynne at ljmu dot ac dot uk Now I'm stuck: a) The PHP build fails if I do --enable-experimental-zts b) SuSE 10.1 only ships with apache2 binary RPM's. I downloaded apache 1.3 source and compiled / installed ran, but httpd just dies, no errors in the loge either. In any case a downgrade to apache 1.3 isn't an option as I have other apache 2.x only modules that I besides PHP. c) No updates on the SuSE update server for either apache2 or openldap. Problem appears to point to OpenLDAP, so all I can think of next is to compile / install the latest build. Maybe this is an anomaly with 64 bit machines, which is why it's reporing is not more widespread. [2006-09-29 10:43:08] [EMAIL PROTECTED] Well, you can also try to compile PHP CLI with --enable-experimental-zts and see if it works for you OR (I'd prefer this one) use Apache 1.x for tests. [2006-09-29 10:29:41] d dot wynne at ljmu dot ac dot uk Not used valgrind at all, but I've done a bit of searching I've found someone else with exactly the same problme as I'm having. The exact version of PHP is not mentioned, but the same backtrace including: #0 0x2b1f2151 in ldap_unbind_ext () from /usr/lib64/libldap-2.3.so.0 is. Also it's 64 bit linux and the same version of Apache ( 2.2.0 ). He claims that the code works using the PHP CLI. I have tested this with: #! /usr/bin/php ?php $ldapServer = bydc1.jmu.ac.uk; echo pConnecting/p\n; $ds=ldap_connect($ldapServer); echo pDisconnecting/p\n; ldap_close($ds); ? and indeed it does. No Segmentatio fault. Does that mean that PHP / MySQL / LDAP are all red herringd and the culprit could be Apache, as the CLI version works, and the problem only occurs when running it through a browser ? 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/38882 -- Edit this bug report at http://bugs.php.net/?id=38882edit=1
#38988 [Fbk-Bgs]: Chaning mssql.datetimeconvert has no effect
ID: 38988 Updated by: [EMAIL PROTECTED] Reported By: wiggum24 at gmail dot com -Status: Feedback +Status: Bogus Bug Type: MSSQL related Operating System: Redhat Enterprise Linux PHP Version: 5.1.6 New Comment: Works fine here. Did you remove ; in front of the line? Previous Comments: [2006-09-29 09:09:28] [EMAIL PROTECTED] Trying to set mssql.datetimeconvert to Off in php.ini doesn't work. phpinfo() reports it as On, and the behaviour of the recordset reflects the same. Which php.ini is used by PHP according to phpinfo()? Which php.ini did you change? Did you restart the web-server? [2006-09-29 06:47:39] wiggum24 at gmail dot com Description: Trying to set mssql.datetimeconvert to Off in php.ini doesn't work. phpinfo() reports it as On, and the behaviour of the recordset reflects the same. I've confirmed php is picking up the correct php.ini, and my php.ini contains no errors. Calling ini_set(mssql.datetimeconvert,Off); before I do the query will set the value and the queries will return correctly. Reproduce code: --- No errors, the setting just doesn't apply. Expected result: datetimes should appear as: 2006-07-20 16:32:00 Actual result: -- datetimes appear as: Jul 20 2006 04:32PM -- Edit this bug report at http://bugs.php.net/?id=38988edit=1
#38882 [Fbk-Opn]: ldap_connect causes Segmentation fault
ID: 38882 User updated by: d dot wynne at ljmu dot ac dot uk Reported By: d dot wynne at ljmu dot ac dot uk -Status: Feedback +Status: Open Bug Type: LDAP related Operating System: SuSE 10.1 x86_64 PHP Version: 4.4.4 New Comment: OK, Built installed. Presumably now there's some new options or statements to the /usr/bin/php CLI script with the ldap_connect statement. Previous Comments: [2006-09-29 14:45:19] [EMAIL PROTECTED] `make clean` is required. [2006-09-29 14:44:04] d dot wynne at ljmu dot ac dot uk . Zend/zend_sprintf.lo Zend/zend_ini.lo Zend/zend_qsort.lo Zend/zend_multibyte.lo Zend/zend_strtod.lo Zend/zend_execute.lo sapi/cli/php_cli.lo sapi/cli/getopt.lo main/internal_functions_cli.lo -lcrypt -lcrypt -lsybdb -lldap -llber -lresolv - lm -ldl -lnsl -lssl -lcrypto -ldl -ldl -lm -lnsl -lirc -lclntsh -lcrypt -lcrypt -o sapi/cli/php ext/standard/info.lo: In function `php_info_print_table_header': /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:756: undefined refere nce to `ts_resource_ex' ext/standard/info.lo: In function `php_info_print_table_row': /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:800: undefined refere nce to `ts_resource_ex' ext/standard/info.lo: In function `php_print_gpcse_array': /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:119: undefined refere nce to `executor_globals_id' ext/standard/info.lo: In function `php_info_write_wrapper': /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:67: undefined referen ce to `ts_resource_ex' ext/standard/info.lo: In function `php_print_info': /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:624: undefined refere nce to `executor_globals_id' /home/cmstechs/cmsdwynn/SuSE/php-4.4.4/ext/standard/info.c:554: undefined refere nce to `sapi_globals_id' [2006-09-29 14:06:23] [EMAIL PROTECTED] a) The PHP build fails if I do --enable-experimental-zts Please elaborate. [2006-09-29 14:00:00] d dot wynne at ljmu dot ac dot uk Now I'm stuck: a) The PHP build fails if I do --enable-experimental-zts b) SuSE 10.1 only ships with apache2 binary RPM's. I downloaded apache 1.3 source and compiled / installed ran, but httpd just dies, no errors in the loge either. In any case a downgrade to apache 1.3 isn't an option as I have other apache 2.x only modules that I besides PHP. c) No updates on the SuSE update server for either apache2 or openldap. Problem appears to point to OpenLDAP, so all I can think of next is to compile / install the latest build. Maybe this is an anomaly with 64 bit machines, which is why it's reporing is not more widespread. [2006-09-29 10:43:08] [EMAIL PROTECTED] Well, you can also try to compile PHP CLI with --enable-experimental-zts and see if it works for you OR (I'd prefer this one) use Apache 1.x for tests. 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/38882 -- Edit this bug report at http://bugs.php.net/?id=38882edit=1
#38994 [NEW]: bugs in mktime() - easy to confirm
From: naox at yum dot pl Operating system: centos 4 PHP version: 5.1.6 PHP Bug Type: Scripting Engine problem Bug description: bugs in mktime() - easy to confirm Description: there is problem with mktime. it caclulates badly seconds in pedroids 27-28 march in some years like 2005. Possibly some other pedroids are affected. this is just example to make bug search easier. Reproduce code: --- ? $a1 = mktime(0,0,0,3,27,2005); $a2 = mktime(0,0,0,3,28,2005); $w = ($a2 - $a1) / 60 / 60 / 24; echo $w; echo br\n; $a1 = mktime(0,0,0,3,27,2006); $a2 = mktime(0,0,0,3,28,2006); $w = ($a2 - $a1) / 60 / 60 / 24; echo $w; ? Expected result: 1 1 Actual result: -- will show: 0.958333 1 -- Edit bug report at http://bugs.php.net/?id=38994edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38994r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38994r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38994r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38994r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38994r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38994r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38994r=needscript Try newer version:http://bugs.php.net/fix.php?id=38994r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38994r=support Expected behavior:http://bugs.php.net/fix.php?id=38994r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38994r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38994r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38994r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38994r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38994r=dst IIS Stability:http://bugs.php.net/fix.php?id=38994r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38994r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38994r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38994r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38994r=mysqlcfg
#38994 [Opn-Bgs]: bugs in mktime() - easy to confirm
ID: 38994 Updated by: [EMAIL PROTECTED] Reported By: naox at yum dot pl -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: centos 4 PHP Version: 5.1.6 New Comment: We are happy to tell you that you just discovered Daylight Savings Time. For more information see: http://webexhibits.org/daylightsaving/b.html Instead of using mktime/date consider using gmmktime and gmdate which do not suffer from DST. Previous Comments: [2006-09-29 15:12:26] naox at yum dot pl Description: there is problem with mktime. it caclulates badly seconds in pedroids 27-28 march in some years like 2005. Possibly some other pedroids are affected. this is just example to make bug search easier. Reproduce code: --- ? $a1 = mktime(0,0,0,3,27,2005); $a2 = mktime(0,0,0,3,28,2005); $w = ($a2 - $a1) / 60 / 60 / 24; echo $w; echo br\n; $a1 = mktime(0,0,0,3,27,2006); $a2 = mktime(0,0,0,3,28,2006); $w = ($a2 - $a1) / 60 / 60 / 24; echo $w; ? Expected result: 1 1 Actual result: -- will show: 0.958333 1 -- Edit this bug report at http://bugs.php.net/?id=38994edit=1
#38991 [Bgs]: Can not post HTML-Tags
ID: 38991
User updated by: info at optima-software dot de
Reported By: info at optima-software dot de
Status: Bogus
Bug Type: *Configuration Issues
Operating System: Linux version 2.6.17-gentoo-r4
PHP Version: 5.1.6
New Comment:
I found it, and imho this is a real BUG. But not a PHP rather than a
pecl bug.
It is already documented:
http://pecl.php.net/bugs/bug.php?id=7571
WORKAROUND:
Inside the /ext dir you can find a filter.ini
Uncomment the one and only line:
;extension=filter.so
Previous Comments:
[2006-09-29 10:42:04] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
[2006-09-29 10:31:34] info at optima-software dot de
Description:
Since the last php-update I can not POST html-tags inside a string. If
I create a simple form within a textarea, after submit var_dump($_POST)
outputs just plain-text without the html-tags. As a result of that, all
CMS on my server don't work anymore.
See what I did inside the code-area.
PHP Version 5.1.6-pl4-gentoo
configure command
'./configure' '--prefix=/usr/lib/php5' '--host=i686-pc-linux-gnu'
'--mandir=/usr/lib/php5/man' '--infodir=/usr/lib/php5/info'
'--sysconfdir=/etc' '--cache-file=./config.cache' '--disable-cli'
'--with-apxs2=/usr/sbin/apxs2'
'--with-config-file-path=/etc/php/apache2-php5'
'--with-config-file-scan-dir=/etc/php/apache2-php5/ext-active'
'--without-pear' '--enable-bcmath' '--with-bz2' '--enable-calendar'
'--disable-ctype' '--with-curl' '--without-curlwrappers'
'--disable-dbase' '--disable-exif' '--without-fbsql' '--without-fdftk'
'--disable-filepro' '--enable-ftp' '--with-gettext' '--with-gmp'
'--disable-hash' '--without-hwapi' '--without-informix'
'--without-kerberos' '--enable-mbstring' '--with-mcrypt'
'--disable-memory-limit' '--without-mhash' '--without-ming'
'--without-msql' '--without-mssql' '--with-ncurses' '--with-openssl'
'--with-openssl-dir=/usr' '--disable-pcntl' '--with-pgsql'
'--disable-posix' '--without-pspell' '--without-recode'
'--disable-simplexml' '--disable-shmop' '--without-snmp'
'--enable-soap' '--enable-sockets' '--without-sybase'
'--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem'
'--disable-sysvshm' '--with-tidy' '--disable-tokenizer'
'--disable-wddx' '--with-xmlrpc' '--without-xsl' '--with-zlib'
'--disable-debug' '--enable-dba' '--without-cdb' '--with-db4'
'--without-flatfile' '--with-gdbm' '--with-inifile' '--without-qdbm'
'--with-freetype-dir=/usr' '--with-t1lib=/usr' '--disable-gd-jis-conv'
'--enable-gd-native-ttf' '--with-jpeg-dir=/usr' '--with-png-dir=/usr'
'--with-xpm-dir=/usr/X11R6' '--with-gd' '--with-mysql=/usr/lib/mysql'
'--with-mysql-sock=/var/run/mysqld/mysqld.sock'
'--with-mysqli=/usr/bin/mysql_config' '--without-pdo-dblib'
'--with-pdo-mysql=/usr' '--without-pdo-odbc' '--with-pdo-pgsql'
'--with-pdo-sqlite=/usr' '--with-readline' '--without-libedit'
'--without-mm' '--with-sqlite=/usr' '--enable-sqlite-utf8'
Reproduce code:
---
form action=# method=post
fieldset style=width: 300px; margin: auto;
legendA simple form/legend
label for=id_textareaInput some text with html-tags
here/labelbr /
textarea id=id_textarea name=text rows=10
cols=50/textareabr /
input type=submit name=name value=Submit/
/fieldset
/form
br /
?php
if ( isset ($_POST['text']) ){
$output = 'div' . \r\n;
$output .= \t . 'h2The output of $_POST inside a pre-tag/h2'
. \r\n;
$output .= \t . 'pre style=border: 1px solid #ccc; padding:
5px;';
$output .= $_POST['text'];
$output .= '/pre' . \r\n;
$output .= '/div' . \r\n;
echo($output);
}
?
Expected result:
Output of the string I sent.
Actual result:
--
Output of plain-text without html-tags
--
Edit this bug report at http://bugs.php.net/?id=38991edit=1
#37209 [Com]: mssql_execute with non fatal errors
ID: 37209
Comment by: issvar at hotmail dot com
Reported By: netvbonline at yahoo dot co dot uk
Status: Assigned
Bug Type: MSSQL related
Operating System: Win XP Pro
PHP Version: 5.1.2
Assigned To: fmk
New Comment:
This is caused by php stopping processing when dbsqlok() returns FAIL.
Microsoft db-library for c manual states that even if dbsqlok() returns
FAIL there could be results, so results and return values and output
parameters should be processed.
So in ext/mssql/php_mssql.c there should be changed the following part
in PHP_FUNCTION(mssql_execute):
if (dbrpcexec(mssql_ptr-link)==FAIL ||
dbsqlok(mssql_ptr-link)==FAIL) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, stored procedure
execution failed);
dbcancel(mssql_ptr-link);
RETURN_FALSE;
}
this should be changed to:
if (dbrpcexec(mssql_ptr-link)==FAIL) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, stored procedure
execution failed);
dbcancel(mssql_ptr-link);
RETURN_FALSE;
}
if (dbsqlok(mssql_ptr-link)==FAIL) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, stored procedure
execution failed);
}
Previous Comments:
[2006-07-27 00:03:22] [EMAIL PROTECTED]
Frank, there's the feedback now. :)
[2006-05-02 08:24:19] netvbonline at yahoo dot co dot uk
*
[Description]
Procedure handles the process of either fetching or inserting a
forename, this procedure must never update existing name otherwise it
would affect all other person FK's
*/
CREATE PROCEDURE usp_fetch_or_insert_forename
@Forename [varchar](50),
@ForenameID [int] OUTPUT
AS
DECLARE @err int -- needed as the global @@ERROR is reset after each
statement, even logical comparison
-- reduce network traffic
SET NOCOUNT ON
-- first do common validation and checks
BEGIN
INSERT INTO [dbtest].[dbo].[Forename] ( [Forename] )
VALUES ( @Forename )
SET @err=@@ERROR
print 'non fatal error ...'
IF (@err = 2627)
BEGIN
RAISERROR('myMessage:test', 2, 1) WITH SETERROR
END
IF (@err=0)
BEGIN
-- explicitly retrieve the identity of row just inserted
from
above statement
SET @ForenameID=SCOPE_IDENTITY()
RETURN(0)
END
-- Test for key violation before returning error code
IF (@err=2627 )
BEGIN
print 'Looking up the forename value'
-- I know the name exists, so fetch the PK
SELECT @ForenameID=ForenameID FROM Forename WHERE
[EMAIL PROTECTED]
print 'still here .. and forenameid is ' + str(@ForenameID)
RETURN(0)
END
-- There was an error in the insert statement, not
related to unique key violation constraint so return error code
RETURN(@err)
END
GO
Hope this is ok, as you can see it contains various debug messages.
[2006-04-29 03:13:35] [EMAIL PROTECTED]
Please provide a short example of the procedure used to generate this.
The current implementation will handle multiple results from a storred
procedure and it will skip all results without column.
[2006-04-26 14:34:02] netvbonline at yahoo dot co dot uk
SORRY, BIG TYPO
The mssql_execute method SHOULD NOT fail on execution (but in anycase
should still have populated output parameters).
[2006-04-26 14:32:23] netvbonline at yahoo dot co dot uk
Description:
Using the extension php_mssql.dll and mssql_execute method to execute a
stored procedure within SQL Server 2000.
Basically, if the stored procedure generates a non-fatal message, for
example trying to insert a duplicate value into a table before doing a
big seek then output parameters are still available to Query analyser.
However when using the mssql_execute method, the execution fails.. even
though stored procedure is returning a successful execution value of 0.
Its possible to have a stored procedure with 10 statements, and 5
#38995 [NEW]: Update PHP OpenSSL Files
From: dj02 dot net at nbl dot fi Operating system: Windows XP 5.1.2600 PHP version: 5.1.6 PHP Bug Type: OpenSSL related Bug description: Update PHP OpenSSL Files Description: Hi, I am running PHP 5.1.6. Could you update OpenSSL Files: libeay32.dll, ssleay32.dll and Extension: php_openssl.dll to OpenSSL Version: 0.9.8d, Please. Files: libeay32.dll and ssleay32.dll i updated from other openssl official place but i couldn't find php_openssl.dll for OpenSSL 0.9.8d and so my phpinfo shows still version: 0.9.8a even libeay32.dll and ssleay32.dll are 0.9.8d. OpenSSL 0.9.8c and earlier versions security holes: This release fixes four security vulnerabilities, CVE-2006-2937, CVE-2006-2940, CVE-2006-3738, CVE-2006-4343. See www.openssl.org/news/secadv_20060928.txt -- Edit bug report at http://bugs.php.net/?id=38995edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38995r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38995r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38995r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38995r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38995r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38995r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38995r=needscript Try newer version:http://bugs.php.net/fix.php?id=38995r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38995r=support Expected behavior:http://bugs.php.net/fix.php?id=38995r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38995r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38995r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38995r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38995r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38995r=dst IIS Stability:http://bugs.php.net/fix.php?id=38995r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38995r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38995r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38995r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38995r=mysqlcfg
#38995 [Opn]: Update PHP OpenSSL Files
ID: 38995 User updated by: dj02 dot net at nbl dot fi Reported By: dj02 dot net at nbl dot fi Status: Open Bug Type: OpenSSL related Operating System: Windows XP 5.1.2600 PHP Version: 5.1.6 New Comment: I have copied libeay32.dll (Version: 0.9.8d) and ssleay32.dll (Version: 0.9.8d) files in to: C:\WINDOWS\system32\ -location too. Previous Comments: [2006-09-29 17:28:14] dj02 dot net at nbl dot fi Description: Hi, I am running PHP 5.1.6. Could you update OpenSSL Files: libeay32.dll, ssleay32.dll and Extension: php_openssl.dll to OpenSSL Version: 0.9.8d, Please. Files: libeay32.dll and ssleay32.dll i updated from other openssl official place but i couldn't find php_openssl.dll for OpenSSL 0.9.8d and so my phpinfo shows still version: 0.9.8a even libeay32.dll and ssleay32.dll are 0.9.8d. OpenSSL 0.9.8c and earlier versions security holes: This release fixes four security vulnerabilities, CVE-2006-2937, CVE-2006-2940, CVE-2006-3738, CVE-2006-4343. See www.openssl.org/news/secadv_20060928.txt -- Edit this bug report at http://bugs.php.net/?id=38995edit=1
#38934 [Com]: move_uploaded_file() cannot read uploaded file outside of open_basedir
ID: 38934
Comment by: moron at industrial dot org
Reported By: phpbugs at thequod dot de
Status: Feedback
Bug Type: Safe Mode/open_basedir
Operating System: Ubuntu Linux
PHP Version: 5.1.6
New Comment:
Exact same behaviour with 4.4.4 under FreeBSD 6.1.
Frustrating as this bug has appeared before.
Previous Comments:
[2006-09-25 12:54:21] [EMAIL PROTECTED]
Cannot reproduce with both 5.1.6 and latest CVS.
With upload_tmp_dir not set (aka /tmp) and open_basedir=/www, I get
this: File is valid, and was successfully uploaded.
[2006-09-25 11:19:58] Bjorn dot Wiberg at its dot uu dot se
Same result on IBM AIX 5.2 ML8, although I'm using PHP 5.1.5 (no big
difference) and have php_admin_value upload_tmp_dir none set (so it
defaults to /tmp).
---8---
Warning: move_uploaded_file(): open_basedir restriction in effect.
File(/tmp/phpP5moMa) is not within the allowed path(s):
(.:/apache/php/lib/php/:/apache/htdocs/bwiberg/) in
/apache/htdocs/bwiberg/test/safemode/upload.php on line 9
---8---
As you can see, /tmp is not within open_basedir, but I think it should
not need to be...
---8---
?php
// In PHP versions earlier than 4.1.0, $HTTP_POST_FILES should be used
instead
// of $_FILES.
$uploaddir = '/apache/htdocs/bwiberg/test/safemode/';
$uploadfile = $uploaddir . basename($_FILES['userfile']['name']);
echo 'pre';
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile))
{
echo File is valid, and was successfully uploaded.\n;
} else {
echo Possible file upload attack!\n;
}
echo 'Here is some more debugging info:';
print_r($_FILES);
print /pre;
?
---8---
Best regards,
Björn
[2006-09-23 11:36:40] phpbugs at thequod dot de
Description:
According to the documentation PHP should be able to read
the uploaded file, although it's outside the open_basedir
directories:
Note: move_uploaded_file() is both safe mode and
open_basedir aware. However, restrictions are placed only
on the destination path as to allow the moving of uploaded
files in which filename may conflict with such
restrictions. move_uploaded_file() ensures the safety of
this operation by allowing only those files uploaded
through PHP to be moved.
However, I have to add /tmp to open_basedir - which is bad
in terms of users would be allowed to access the files
there!
I've not explicitely set the upload_tmp_dir directive, so
the default /tmp gets used.
See also these old bugs, where it seems to have been
fixed, but now is broken again:
http://bugs.php.net/bug.php?id=21885
http://bugs.php.net/bug.php?id=27559
Reproduce code:
---
upload.php file:
?php
error_reporting(E_ALL);
ini_set('display_errors', 'on');
if( empty($_FILES) )
{
?
!-- The data encoding type, enctype, MUST be specified as below --
form enctype=multipart/form-data action=upload.php method=POST
!-- MAX_FILE_SIZE must precede the file input field --
input type=hidden name=MAX_FILE_SIZE value=3 /
!-- Name of input element determines name in $_FILES array --
Send this file: input name=userfile type=file /
input type=submit value=Send File /
/form
?php
}
else
{
$uploadfile = dirname(__FILE__).'/upload_file.test';
echo 'pre';
if (move_uploaded_file($_FILES['userfile']['tmp_name'],
$uploadfile)) {
echo File is valid, and was successfully
uploaded.\n;
} else {
echo Possible file upload attack!\n;
}
echo 'Here is some more debugging info:';
print_r($_FILES);
print /pre;
}
?
Expected result:
File upload.
Actual result:
--
Warning: move_uploaded_file()
[function.move-uploaded-file]: open_basedir restriction in
effect. File(/tmp/phpoNSKDN) is not within the allowed
path(s): (/XXX) in ...
--
Edit this bug report at http://bugs.php.net/?id=38934edit=1
#38934 [Com]: move_uploaded_file() cannot read uploaded file outside of open_basedir
ID: 38934
Comment by: moron at industrial dot org
Reported By: phpbugs at thequod dot de
Status: Feedback
Bug Type: Safe Mode/open_basedir
Operating System: Ubuntu Linux
PHP Version: 5.1.6
New Comment:
Sorry, forgot to note that in our case, upload_tmp_dir is explicitly
set.
Previous Comments:
[2006-09-29 18:12:05] moron at industrial dot org
Exact same behaviour with 4.4.4 under FreeBSD 6.1.
Frustrating as this bug has appeared before.
[2006-09-25 12:54:21] [EMAIL PROTECTED]
Cannot reproduce with both 5.1.6 and latest CVS.
With upload_tmp_dir not set (aka /tmp) and open_basedir=/www, I get
this: File is valid, and was successfully uploaded.
[2006-09-25 11:19:58] Bjorn dot Wiberg at its dot uu dot se
Same result on IBM AIX 5.2 ML8, although I'm using PHP 5.1.5 (no big
difference) and have php_admin_value upload_tmp_dir none set (so it
defaults to /tmp).
---8---
Warning: move_uploaded_file(): open_basedir restriction in effect.
File(/tmp/phpP5moMa) is not within the allowed path(s):
(.:/apache/php/lib/php/:/apache/htdocs/bwiberg/) in
/apache/htdocs/bwiberg/test/safemode/upload.php on line 9
---8---
As you can see, /tmp is not within open_basedir, but I think it should
not need to be...
---8---
?php
// In PHP versions earlier than 4.1.0, $HTTP_POST_FILES should be used
instead
// of $_FILES.
$uploaddir = '/apache/htdocs/bwiberg/test/safemode/';
$uploadfile = $uploaddir . basename($_FILES['userfile']['name']);
echo 'pre';
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile))
{
echo File is valid, and was successfully uploaded.\n;
} else {
echo Possible file upload attack!\n;
}
echo 'Here is some more debugging info:';
print_r($_FILES);
print /pre;
?
---8---
Best regards,
Björn
[2006-09-23 11:36:40] phpbugs at thequod dot de
Description:
According to the documentation PHP should be able to read
the uploaded file, although it's outside the open_basedir
directories:
Note: move_uploaded_file() is both safe mode and
open_basedir aware. However, restrictions are placed only
on the destination path as to allow the moving of uploaded
files in which filename may conflict with such
restrictions. move_uploaded_file() ensures the safety of
this operation by allowing only those files uploaded
through PHP to be moved.
However, I have to add /tmp to open_basedir - which is bad
in terms of users would be allowed to access the files
there!
I've not explicitely set the upload_tmp_dir directive, so
the default /tmp gets used.
See also these old bugs, where it seems to have been
fixed, but now is broken again:
http://bugs.php.net/bug.php?id=21885
http://bugs.php.net/bug.php?id=27559
Reproduce code:
---
upload.php file:
?php
error_reporting(E_ALL);
ini_set('display_errors', 'on');
if( empty($_FILES) )
{
?
!-- The data encoding type, enctype, MUST be specified as below --
form enctype=multipart/form-data action=upload.php method=POST
!-- MAX_FILE_SIZE must precede the file input field --
input type=hidden name=MAX_FILE_SIZE value=3 /
!-- Name of input element determines name in $_FILES array --
Send this file: input name=userfile type=file /
input type=submit value=Send File /
/form
?php
}
else
{
$uploadfile = dirname(__FILE__).'/upload_file.test';
echo 'pre';
if (move_uploaded_file($_FILES['userfile']['tmp_name'],
$uploadfile)) {
echo File is valid, and was successfully
uploaded.\n;
} else {
echo Possible file upload attack!\n;
}
echo 'Here is some more debugging info:';
print_r($_FILES);
print /pre;
}
?
Expected result:
File upload.
Actual result:
--
Warning: move_uploaded_file()
[function.move-uploaded-file]: open_basedir restriction in
effect. File(/tmp/phpoNSKDN) is not within the allowed
path(s): (/XXX) in ...
--
Edit this bug report at http://bugs.php.net/?id=38934edit=1
#38503 [Com]: Can't load UTF-8 CLOBS
ID: 38503
Comment by: peter dot oulman at uponor-usa dot com
Reported By: thomas dot adams at interone dot de
Status: No Feedback
Bug Type: OCI8 related
Operating System: Ubuntu 4.0.3-1
PHP Version: 5.1.5
New Comment:
We are experiencing the same issue with PHP v. 5.1.6 on the Linux
platform. We also confirmed that downgrading to v. 5.1.2 resolved the
problem.
Previous Comments:
[2006-08-26 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2006-08-18 20:35:13] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-08-18 16:26:33] thomas dot adams at interone dot de
Description:
Versions of PHP newer than 5.1.2
(5.1.3/4/5) failed at loading a CLOB in a UTF-8 Oracle
Database (tested with Oracle 10.2).
There are neither exceptions thrown nor
any other error messages are shown.
The statement echo $row[0]-load(); returns simply no
output. Downgrading to version 5.1.2 resolves this, so this might be
bug.
Kind regards
Thomas Adams
Reproduce code:
---
$sql='select ID, TEXT from TEST_CLOB'; // where Text is CLOB
$stmt = oci_parse($connection, $sql);
oci_execute($stmt)
or die (Unable to execute query\n);
$i=0;
while ( $row = oci_fetch_array($stmt,OCI_NUM) ) {
echo ($i+1) .. $row[0] . : ;
print $row[1]-load();
print ... this is . (is_object($row[1])? an object : not an
object );
print ... object is . (is_a($row[1],'OCI-Lob')?a OCI-Lob
:not a OCI-Lob );
print ... class name of object is . get_class($row[1]);
print ... vardump is ;
var_dump($row);
print 'br /';
$i++;
}
Expected result:
The print $row[1]-load(); line should return
the actual values from the select statement.
Actual result:
--
row[1]-load() returns nothing.
--
Edit this bug report at http://bugs.php.net/?id=38503edit=1
#38996 [NEW]: PDO persistant connection breaks on mysql restart
From: fifthnormal at hotmail dot com Operating system: Linux PHP version: 5.1.6 PHP Bug Type: PDO related Bug description: PDO persistant connection breaks on mysql restart Description: Hello, I am using PDO as a database layer to connect to MySQL. I add the attribute to use a persistant connection. This works as expected If the MySQL server is restarted, then PHP responds with this error message: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away From this point on the connection won't work. This error message will only go away after httpd has been restarted. Thanks, Daniel Burge Reproduce code: --- ? //Run this to ensure that the connection is being made and persisted, then restart your mysql database $dbh = new PDO(mysql:host=dbserver;dbname=databasename,username,password, array(PDO::ATTR_PERSISTENT = true)); ? Expected result: I would expect that PDO would reestablish the connection if it drops. Actual result: -- PDO returns the error message: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away -- Edit bug report at http://bugs.php.net/?id=38996edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38996r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38996r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38996r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38996r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38996r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38996r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38996r=needscript Try newer version:http://bugs.php.net/fix.php?id=38996r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38996r=support Expected behavior:http://bugs.php.net/fix.php?id=38996r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38996r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38996r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38996r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38996r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38996r=dst IIS Stability:http://bugs.php.net/fix.php?id=38996r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38996r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38996r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38996r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38996r=mysqlcfg
#38997 [NEW]: Cannot configure PHP for cross-compilation with Apache 2.2.3
From: lstefani at fortresstech dot com Operating system: Linux 2.6.12 PHP version: 5.1.6 PHP Bug Type: *Configuration Issues Bug description: Cannot configure PHP for cross-compilation with Apache 2.2.3 Description: After successfully cross-compiling Apache 2.2.3 on Linux x86 machine for MIPS target, PHP fails to configure properly with --with-apxs2= flag. The reason for the failure is that PHP configure executes apxs utility, which executes httpd, but that binary was cross-compiled, so it fails to execute. Reproduce code: --- env ac_cv_func_fopencookie=no ac_cv_func_getaddrinfo=yes ac_cv_func_utime_null=yes ac_cv_func_waitpid=yes ac_cv_pread=yes ac_cv_pwrite=yes ac_cv_sizeof_long=4 ac_cv_php_xml2_config_path=/usr/apache/bin/xml2-config PKG_CONFIG_PATH=/usr/apache/lib/pkgconfig ac_cv_prog_CC=/buildtools/gcc-3.3.2-glibc-2.3.2/mips-linux/bin/mips-linux-gcc ./configure --host=mips-linux --target=mips-linux --without-iconv --without-mysql --without-pear --enable-sigchild --enable-bcmath --with-apxs2=/usr/apache/bin/apxs --with-libxml-dir=/usr/apache --prefix=/usr/apache Expected result: Successful configuration of PHP for subsequent make operation. When configuring for cross-compilation, PHP configure should not be dependent on natively executing binaries that were built for other targets. What information does PHP configure require of apxs and httpd? Is there an alternative way to retrieve it? Actual result: -- Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... no checking for Apache 1.x module support... no checking for mod_charset compatibility option... no checking for Apache 2.0 filter-module support via DSO through APXS... no checking for Apache 2.0 handler-module support via DSO through APXS... Sorry, I cannot run apxs. Possible reasons follow: 1. Perl is not installed 2. apxs was not found. Try to pass the path using --with-apxs2=/path/to/apxs 3. Apache was not built using --enable-so (the apxs usage page is displayed) The output of /usr/apache/bin/apxs follows: sh: /usr/apache/bin/httpd: cannot execute binary file apxs:Error: Sorry, no shared object support for Apache. apxs:Error: available under your platform. Make sure. apxs:Error: the Apache module mod_so is compiled into. apxs:Error: your server binary `/usr/apache/bin/httpd'.. configure: error: Aborting -- Edit bug report at http://bugs.php.net/?id=38997edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38997r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38997r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38997r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38997r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38997r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38997r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38997r=needscript Try newer version:http://bugs.php.net/fix.php?id=38997r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38997r=support Expected behavior:http://bugs.php.net/fix.php?id=38997r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38997r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38997r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38997r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38997r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38997r=dst IIS Stability:http://bugs.php.net/fix.php?id=38997r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38997r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38997r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38997r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38997r=mysqlcfg
#38995 [Opn-Asn]: Update PHP OpenSSL Files
ID: 38995 Updated by: [EMAIL PROTECTED] Reported By: dj02 dot net at nbl dot fi -Status: Open +Status: Assigned Bug Type: OpenSSL related Operating System: Windows XP 5.1.2600 PHP Version: 5.1.6 -Assigned To: +Assigned To: edink Previous Comments: [2006-09-29 17:35:25] dj02 dot net at nbl dot fi I have copied libeay32.dll (Version: 0.9.8d) and ssleay32.dll (Version: 0.9.8d) files in to: C:\WINDOWS\system32\ -location too. [2006-09-29 17:28:14] dj02 dot net at nbl dot fi Description: Hi, I am running PHP 5.1.6. Could you update OpenSSL Files: libeay32.dll, ssleay32.dll and Extension: php_openssl.dll to OpenSSL Version: 0.9.8d, Please. Files: libeay32.dll and ssleay32.dll i updated from other openssl official place but i couldn't find php_openssl.dll for OpenSSL 0.9.8d and so my phpinfo shows still version: 0.9.8a even libeay32.dll and ssleay32.dll are 0.9.8d. OpenSSL 0.9.8c and earlier versions security holes: This release fixes four security vulnerabilities, CVE-2006-2937, CVE-2006-2940, CVE-2006-3738, CVE-2006-4343. See www.openssl.org/news/secadv_20060928.txt -- Edit this bug report at http://bugs.php.net/?id=38995edit=1
#38997 [Opn-Bgs]: Cannot configure PHP for cross-compilation with Apache 2.2.3
ID: 38997 Updated by: [EMAIL PROTECTED] Reported By: lstefani at fortresstech dot com -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: Linux 2.6.12 PHP Version: 5.1.6 New Comment: PHP _does_ need to execute apxs to get correct compilation flags, paths etc. required to compile Apache module. There is nothing we can do about it. Previous Comments: [2006-09-29 19:18:28] lstefani at fortresstech dot com Description: After successfully cross-compiling Apache 2.2.3 on Linux x86 machine for MIPS target, PHP fails to configure properly with --with-apxs2= flag. The reason for the failure is that PHP configure executes apxs utility, which executes httpd, but that binary was cross-compiled, so it fails to execute. Reproduce code: --- env ac_cv_func_fopencookie=no ac_cv_func_getaddrinfo=yes ac_cv_func_utime_null=yes ac_cv_func_waitpid=yes ac_cv_pread=yes ac_cv_pwrite=yes ac_cv_sizeof_long=4 ac_cv_php_xml2_config_path=/usr/apache/bin/xml2-config PKG_CONFIG_PATH=/usr/apache/lib/pkgconfig ac_cv_prog_CC=/buildtools/gcc-3.3.2-glibc-2.3.2/mips-linux/bin/mips-linux-gcc ./configure --host=mips-linux --target=mips-linux --without-iconv --without-mysql --without-pear --enable-sigchild --enable-bcmath --with-apxs2=/usr/apache/bin/apxs --with-libxml-dir=/usr/apache --prefix=/usr/apache Expected result: Successful configuration of PHP for subsequent make operation. When configuring for cross-compilation, PHP configure should not be dependent on natively executing binaries that were built for other targets. What information does PHP configure require of apxs and httpd? Is there an alternative way to retrieve it? Actual result: -- Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... no checking for Apache 1.x module support... no checking for mod_charset compatibility option... no checking for Apache 2.0 filter-module support via DSO through APXS... no checking for Apache 2.0 handler-module support via DSO through APXS... Sorry, I cannot run apxs. Possible reasons follow: 1. Perl is not installed 2. apxs was not found. Try to pass the path using --with-apxs2=/path/to/apxs 3. Apache was not built using --enable-so (the apxs usage page is displayed) The output of /usr/apache/bin/apxs follows: sh: /usr/apache/bin/httpd: cannot execute binary file apxs:Error: Sorry, no shared object support for Apache. apxs:Error: available under your platform. Make sure. apxs:Error: the Apache module mod_so is compiled into. apxs:Error: your server binary `/usr/apache/bin/httpd'.. configure: error: Aborting -- Edit this bug report at http://bugs.php.net/?id=38997edit=1
#38997 [Bgs]: Cannot configure PHP for cross-compilation with Apache 2.2.3
ID: 38997 User updated by: lstefani at fortresstech dot com Reported By: lstefani at fortresstech dot com Status: Bogus Bug Type: *Configuration Issues Operating System: Linux 2.6.12 PHP Version: 5.1.6 New Comment: Hi Tony, Thanks for the quick response. OK, so apxs and (indirectly) httpd must be executable. Am I correct in assuming that if I were to temporarily install a native (X86) httpd to make PHP configure happy, I'd be in trouble because the native compilation flags are (obviously) different for the cross-compiled build? Do you recommend that I attack this problem by removing the apxs dependency and pass in all of the compilation flags, paths, etc. that PHP needs to build the Apache module? I'm highly motivated to make cross-compilation work because the alternative is to install all of the source trees, toolchains, etc. on the target platform and build natively. That's just not practical for my development environment. Thanks, Larry Stefani Previous Comments: [2006-09-29 20:29:02] [EMAIL PROTECTED] PHP _does_ need to execute apxs to get correct compilation flags, paths etc. required to compile Apache module. There is nothing we can do about it. [2006-09-29 19:18:28] lstefani at fortresstech dot com Description: After successfully cross-compiling Apache 2.2.3 on Linux x86 machine for MIPS target, PHP fails to configure properly with --with-apxs2= flag. The reason for the failure is that PHP configure executes apxs utility, which executes httpd, but that binary was cross-compiled, so it fails to execute. Reproduce code: --- env ac_cv_func_fopencookie=no ac_cv_func_getaddrinfo=yes ac_cv_func_utime_null=yes ac_cv_func_waitpid=yes ac_cv_pread=yes ac_cv_pwrite=yes ac_cv_sizeof_long=4 ac_cv_php_xml2_config_path=/usr/apache/bin/xml2-config PKG_CONFIG_PATH=/usr/apache/lib/pkgconfig ac_cv_prog_CC=/buildtools/gcc-3.3.2-glibc-2.3.2/mips-linux/bin/mips-linux-gcc ./configure --host=mips-linux --target=mips-linux --without-iconv --without-mysql --without-pear --enable-sigchild --enable-bcmath --with-apxs2=/usr/apache/bin/apxs --with-libxml-dir=/usr/apache --prefix=/usr/apache Expected result: Successful configuration of PHP for subsequent make operation. When configuring for cross-compilation, PHP configure should not be dependent on natively executing binaries that were built for other targets. What information does PHP configure require of apxs and httpd? Is there an alternative way to retrieve it? Actual result: -- Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... no checking for Apache 1.x module support... no checking for mod_charset compatibility option... no checking for Apache 2.0 filter-module support via DSO through APXS... no checking for Apache 2.0 handler-module support via DSO through APXS... Sorry, I cannot run apxs. Possible reasons follow: 1. Perl is not installed 2. apxs was not found. Try to pass the path using --with-apxs2=/path/to/apxs 3. Apache was not built using --enable-so (the apxs usage page is displayed) The output of /usr/apache/bin/apxs follows: sh: /usr/apache/bin/httpd: cannot execute binary file apxs:Error: Sorry, no shared object support for Apache. apxs:Error: available under your platform. Make sure. apxs:Error: the Apache module mod_so is compiled into. apxs:Error: your server binary `/usr/apache/bin/httpd'.. configure: error: Aborting -- Edit this bug report at http://bugs.php.net/?id=38997edit=1
#38998 [NEW]: wrong default values in constructor
From: camka at email dot ee Operating system: win 2000 PHP version: 5.1.6 PHP Bug Type: MySQLi related Bug description: wrong default values in constructor Description: If passing NULL parameters in mysqli::__construct, as they are by default, the values are not actually taken from php.ini (or apache conf) file. Tested with both 5.1.6 and 5.2 latest snapshot. Reproduce code: --- virtual host conf: php_admin_value mysqli.default_host zorro php_admin_value mysqli.default_user rootf php_admin_value mysqli.default_pw ff ? $m = new mysqli(); echo mysqli_connect_error(), \n; $m = new mysqli(null); echo mysqli_connect_error(), \n; $m = new mysqli(null, null); echo mysqli_connect_error(), \n; $m = new mysqli(null, null, null); echo mysqli_connect_error(), \n; ? Expected result: Access denied for user 'rootf'@'zorro' (using password: YES) Access denied for user 'rootf'@'zorro' (using password: YES) Access denied for user 'rootf'@'zorro' (using password: YES) Access denied for user 'rootf'@'zorro' (using password: YES) Actual result: -- [empty] Access denied for user 'rootf'@'localhost' (using password: YES) Access denied for user 'ODBC'@'localhost' (using password: YES) Access denied for user 'ODBC'@'localhost' (using password: NO) -- Edit bug report at http://bugs.php.net/?id=38998edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38998r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38998r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38998r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38998r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38998r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38998r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38998r=needscript Try newer version:http://bugs.php.net/fix.php?id=38998r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38998r=support Expected behavior:http://bugs.php.net/fix.php?id=38998r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38998r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38998r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38998r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38998r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38998r=dst IIS Stability:http://bugs.php.net/fix.php?id=38998r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38998r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38998r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38998r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38998r=mysqlcfg
#37527 [Opn]: Crash - odbc_exec on closed pconnect
ID: 37527
User updated by: bhines at alumni dot ucsd dot edu
Reported By: bhines at alumni dot ucsd dot edu
Status: Open
Bug Type: ODBC related
Operating System: Windows XP
-PHP Version: 5.1.4
+PHP Version: 5.1.6
New Comment:
Still occurs in 5.1.6
Previous Comments:
[2006-05-20 21:44:33] bhines at alumni dot ucsd dot edu
odbc32.dll!74355a16()
odbc32.dll!7432139f()
odbc32.dll!74322c5d()
odbc32.dll!74325fa0()
odbc32.dll!7432740e()
php5ts.dll!zif_odbc_exec(int ht=17437576, _zval_struct *
return_value=0x010af6f0, _zval_struct * * return_value_ptr=0x,
_zval_struct * this_ptr=0x, int return_value_used=1, void * * *
tsrm_ls=0x00032608) Line 1285 C
php5ts.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data *
execute_data=0x00c0fae8, void * * * tsrm_ls=0x00032608) Line 200 +
0x35C
php5ts.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER(_zend_execute_data *
execute_data=0x, void * * * tsrm_ls=0x00032608) Line 1644 +
0xe C
php5ts.dll!execute(_zend_op_array * op_array=0x, void * * *
tsrm_ls=0x010abb40) Line 92 + 0xc C
php5ts.dll!_efree(void * ptr=0x011d5f60) Line 275 + 0xcC
php5ts.dll!zend_llist_del_element(_zend_llist * l=0x010ad080, void *
element=0x00032608, int (void *, void *)* compare=0x) Line 99
+ 0x5 C
php5ts.dll!zend_execute_scripts(int type=2009252809, void * * *
tsrm_ls=0x0003, _zval_struct * * retval=0x, int
file_count=2009252814, ...) Line 1100 C
ntdll.dll!7c9106eb()
msvcrt.dll!77c2c3ce()
msvcrt.dll!77c2c3e7()
msvcrt.dll!77c2c42e()
php5ts.dll!_zend_hash_add_or_update(_hashtable * ht=0x000d, char
* arKey=0x010abb30, unsigned int nKeyLength=268473042, void *
pData=0x, unsigned int nDataSize=206344, void * *
pDest=0x010abb18, int flag=268473024) Line 248 + 0x2e C
php5ts.dll!ts_resource_ex(int id=12648368, unsigned long *
th_id=0x) Line 331 C
php5ts.dll!php_execute_script(_zend_file_handle *
primary_file=0x00c0fedc, void * * * tsrm_ls=0x00032608) Line 1682 +
0x31C
php.exe!main(int argc=2, char * * argv=0x000325c8) Line 1094 C
php.exe!_mainCRTStartup() + 0xe3
kernel32.dll!7c816d4f()
kernel32.dll!7c8399f3()
[2006-05-20 13:58:28] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
[2006-05-19 20:06:48] bhines at alumni dot ucsd dot edu
Description:
php crashes if i connect to a closed ODBC pconnect. I know this is
very bad code below, but php should probably not crash.
I reproed this with both 5.1.4 and today's 5.2 snapshot.
Reproduce code:
---
?php
$mydb = NULL;
printPage();
function pdb_Connect()
{
global $mydb;
if($mydb == NULL)
{ /* To repro, you need to supply a valid DSN and user/pass here.
Only crashes with pconnect here, not connect. */
$mydb = odbc_pconnect(YourDSN, YourUser, YourPass,
SQL_CUR_USE_ODBC) or die(odbc_errormsg() );
}
return $mydb;
}
function printPage()
{
$mydb = pdb_Connect();
odbc_close($mydb);
print Possibly Crashing now... ;
$results = odbc_exec($mydb, 'SELECT * FROM _PDB_Access');
}
?
Expected result:
With warnings on, i'd expect something like:
Possibly Crashing now...
Warning: odbc_exec(): supplied argument is not a valid ODBC-Link
resource in d:\inetpub\wwwroot\include\test\testcrash.php on line 20
Actual result:
--
Possibly Crashing now... PHP has encountered an Access Violation at
7C901010
--
Edit this bug report at http://bugs.php.net/?id=37527edit=1
#38934 [Com]: move_uploaded_file() cannot read uploaded file outside of open_basedir
ID: 38934
Comment by: moron at industrial dot org
Reported By: phpbugs at thequod dot de
Status: Feedback
Bug Type: Safe Mode/open_basedir
Operating System: Ubuntu Linux
PHP Version: 5.1.6
New Comment:
Sorry for the flurry. In our case it turned out that the error message
was just misleading. A simple permissions issue on the target directory
was the cause (arrgh) but the error message explicitly stated that the
problem was the open_basedir setting of the upload_tmp directory. So
more of an annoyance than a show stopper in our case.
Previous Comments:
[2006-09-29 18:13:11] moron at industrial dot org
Sorry, forgot to note that in our case, upload_tmp_dir is explicitly
set.
[2006-09-29 18:12:05] moron at industrial dot org
Exact same behaviour with 4.4.4 under FreeBSD 6.1.
Frustrating as this bug has appeared before.
[2006-09-25 12:54:21] [EMAIL PROTECTED]
Cannot reproduce with both 5.1.6 and latest CVS.
With upload_tmp_dir not set (aka /tmp) and open_basedir=/www, I get
this: File is valid, and was successfully uploaded.
[2006-09-25 11:19:58] Bjorn dot Wiberg at its dot uu dot se
Same result on IBM AIX 5.2 ML8, although I'm using PHP 5.1.5 (no big
difference) and have php_admin_value upload_tmp_dir none set (so it
defaults to /tmp).
---8---
Warning: move_uploaded_file(): open_basedir restriction in effect.
File(/tmp/phpP5moMa) is not within the allowed path(s):
(.:/apache/php/lib/php/:/apache/htdocs/bwiberg/) in
/apache/htdocs/bwiberg/test/safemode/upload.php on line 9
---8---
As you can see, /tmp is not within open_basedir, but I think it should
not need to be...
---8---
?php
// In PHP versions earlier than 4.1.0, $HTTP_POST_FILES should be used
instead
// of $_FILES.
$uploaddir = '/apache/htdocs/bwiberg/test/safemode/';
$uploadfile = $uploaddir . basename($_FILES['userfile']['name']);
echo 'pre';
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile))
{
echo File is valid, and was successfully uploaded.\n;
} else {
echo Possible file upload attack!\n;
}
echo 'Here is some more debugging info:';
print_r($_FILES);
print /pre;
?
---8---
Best regards,
Björn
[2006-09-23 11:36:40] phpbugs at thequod dot de
Description:
According to the documentation PHP should be able to read
the uploaded file, although it's outside the open_basedir
directories:
Note: move_uploaded_file() is both safe mode and
open_basedir aware. However, restrictions are placed only
on the destination path as to allow the moving of uploaded
files in which filename may conflict with such
restrictions. move_uploaded_file() ensures the safety of
this operation by allowing only those files uploaded
through PHP to be moved.
However, I have to add /tmp to open_basedir - which is bad
in terms of users would be allowed to access the files
there!
I've not explicitely set the upload_tmp_dir directive, so
the default /tmp gets used.
See also these old bugs, where it seems to have been
fixed, but now is broken again:
http://bugs.php.net/bug.php?id=21885
http://bugs.php.net/bug.php?id=27559
Reproduce code:
---
upload.php file:
?php
error_reporting(E_ALL);
ini_set('display_errors', 'on');
if( empty($_FILES) )
{
?
!-- The data encoding type, enctype, MUST be specified as below --
form enctype=multipart/form-data action=upload.php method=POST
!-- MAX_FILE_SIZE must precede the file input field --
input type=hidden name=MAX_FILE_SIZE value=3 /
!-- Name of input element determines name in $_FILES array --
Send this file: input name=userfile type=file /
input type=submit value=Send File /
/form
?php
}
else
{
$uploadfile = dirname(__FILE__).'/upload_file.test';
echo 'pre';
if (move_uploaded_file($_FILES['userfile']['tmp_name'],
$uploadfile)) {
echo File is valid, and was successfully
uploaded.\n;
} else {
echo Possible file upload attack!\n;
}
echo 'Here is some more debugging info:';
print_r($_FILES);
print /pre;
}
?
Expected result:
File upload.
Actual result:
--
Warning: move_uploaded_file()
[function.move-uploaded-file]: open_basedir restriction in
effect. File(/tmp/phpoNSKDN) is not within the allowed
path(s): (/XXX) in ...
--
Edit this bug report at http://bugs.php.net/?id=38934edit=1
#38819 [Opn]: segfault in ldap_get_entries()
ID: 38819 User updated by: madcoder at gmail dot com Reported By: madcoder at gmail dot com Status: Open Bug Type: LDAP related Operating System: 2.6.15-gentoo linux amd64 PHP Version: 5.1.6 New Comment: Any other ideas? This problem is kind of a blocker for me right now... I still don't understand why it works fine inside valgrind, but it segfaults on its own and inside gdb. I know it's segfaulting because of the message Cannot access memory at address 0x55a0bfe0, so the for loop checking vals[i] obviously fails. But what steps can I take to debug this further? It could be a problem in openldap, since the line in php's ldap.c just before it calls the openldap function 'ldap_count_values' is ldap_get_values(), which is what is returning the memory address of 0x55a0bfe0. But if it were in fact a problem with openldap, would the cli ldapsearch fail as well? Previous Comments: [2006-09-26 11:08:50] madcoder at gmail dot com I've tried, but the program doesn't segfault, so it exits normally. I'm not very experienced with gdb, so I'm not sure how to give it a breakpoint of ldap_count_values (I tried 'break ldap_count_values' and 'break ldap_count_values()', and it doesn't break). It does still return the information as expected. [2006-09-26 10:57:53] [EMAIL PROTECTED] Is it possible to perform the same actions using ldapsearch utility in console? [2006-09-26 10:43:23] madcoder at gmail dot com Program received signal SIGSEGV, Segmentation fault. 0x2af2b2e5f0ab in ldap_count_values (vals=0x55a07f90) at getvalues.c:153 153 for ( i = 0; vals[i] != NULL; i++ ) (gdb) p vals $1 = (char **) 0x55a07f90 (gdb) p 0 $2 = 0 (gdb) p vals[0] Cannot access memory at address 0x55a07f90 The memory address is the same. Can't access memory? It seems like its a problem in php's ldap_get_entries still (or further up the stack) because ldap_count_entries(), which calls the same function, works fine and returns '1'. [2006-09-26 10:38:38] [EMAIL PROTECTED] And what is in vals[0] ? (gdb) p vals[0] [2006-09-26 10:28:55] madcoder at gmail dot com I do still get the segfault. This is the output from gdb: (gdb) set args -e test.php (gdb) run Starting program: /root/php-5.1.6/sapi/cli/php -e test.php done searching Count: 1 entries Program received signal SIGSEGV, Segmentation fault. 0x2b92baa9a0ab in ldap_count_values (vals=0x55a07f90) at getvalues.c:153 153 for ( i = 0; vals[i] != NULL; i++ ) (gdb) f 0 #0 0x2b92baa9a0ab in ldap_count_values (vals=0x55a07f90) at getvalues.c:153 153 for ( i = 0; vals[i] != NULL; i++ ) (gdb) p vals $1 = (char **) 0x55a07f90 (gdb) p i $2 = 0 If I'm understanding that correctly, it means the segfault is occuring on the first iteration of the ldap_count_values() for loop. The first thing I notice is that 'vals' is a 32-bit pointer. Would that have any effect on the problem, considering this is a 64-bit system? Should I have 32-bit emulation libraries installed for this? The only reason I haven't installed the libraries so far is because none of the other packages I've installed have specifically said that they are necessary. 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/38819 -- Edit this bug report at http://bugs.php.net/?id=38819edit=1
#39000 [NEW]: Attempting to set a subclass' private property in __set crashes PHP ( Apache)
From: kzantow at gmail dot com
Operating system: Windows XP SP2
PHP version: 5.1.6
PHP Bug Type: Reproducible crash
Bug description: Attempting to set a subclass' private property in __set
crashes PHP ( Apache)
Description:
Attempting to set a subclass' private property in __set causes PHP 5.1.6
(and Apache 2.2.3 using XAMPP 1.5.4) to crash.
Reproduce code:
---
class CrashParent {
public function __set($propertyName, $value) {
$this-$propertyName = $value;
}
}
class CrashChild extends CrashParent {
private $a_property;
}
$instance = new CrashChild();
// Crash here:
$instance-a_property = a new value;
Expected result:
Not sure. Either an error indicating you may not set a subclass' private
property or preferably the property to be set.
Actual result:
--
Crash.
--
Edit bug report at http://bugs.php.net/?id=39000edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39000r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39000r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39000r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39000r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39000r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39000r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39000r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39000r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39000r=support
Expected behavior:http://bugs.php.net/fix.php?id=39000r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39000r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39000r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39000r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39000r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39000r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39000r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39000r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39000r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39000r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39000r=mysqlcfg
#39001 [NEW]: ReflectionProperty returns incorrect declaring class for protected properties
From: kzantow at gmail dot com
Operating system: Windows XP SP2
PHP version: 5.1.6
PHP Bug Type: Class/Object related
Bug description: ReflectionProperty returns incorrect declaring class for
protected properties
Description:
ReflectionProperty returns incorrect declaring class for protected
properties.
Reproduce code:
---
class Parent {
public $publicVar;
protected $protectedVar;
}
class Child extends Parent {
}
$r = new ReflectionClass('Child');
print $r-getProperty('publicVar')-getDeclaringClass()-getName();
print $r-getProperty('protectedVar')-getDeclaringClass()-getName();
Expected result:
ParentClass
ParentClass
Actual result:
--
ParentClass
ChildClass
--
Edit bug report at http://bugs.php.net/?id=39001edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39001r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39001r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39001r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39001r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39001r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39001r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39001r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39001r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39001r=support
Expected behavior:http://bugs.php.net/fix.php?id=39001r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39001r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39001r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39001r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39001r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39001r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39001r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39001r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39001r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39001r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39001r=mysqlcfg
