#38820 [Opn]: chdir(.) and chdir(..) don't work with Apache 2.0+
ID: 38820 User updated by: ras at fyn dot dk Reported By: ras at fyn dot dk Status: Open Bug Type: Directory function related Operating System: Win XP SP2 PHP Version: 5.1.6 New Comment: No, it does not reproduce on Linux, as said, the bug appears to be specific to the Windows port. Previous Comments: [2006-09-25 13:04:23] [EMAIL PROTECTED] Not reproducible on Linux with Apache2.0.55 worker/prefork. [2006-09-14 11:21:56] ras at fyn dot dk Tony, as said - I already tried the current snapshot, downloaded the latest development release yesterday. Unless it was fixed and updated today, I'm sorry, but I don't have time to uninstall, reinstall and reconfigure Apache and PHP again just now. My current Apache 1.3 installation works just fine for me - I only use the Windows release for testing and development on my workstation... [2006-09-14 08:50:01] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-09-14 06:40:02] ras at fyn dot dk Description: When using chdir() with relative folders (e.g. . and ..), under Apache 2.0 or newer, using either the php5 module or the CGI binary, the function changes the current directory to the Apache application folder, rather than a folder relative to the current folder. Tested with PHP 5.1.6, and current 5.2.x-dev, under Apache 2.2.3, 2.0.59 and 2.0.55 - all tested with both the php5 module and the CGI binary, all with same result. Bug appears to be specific to the Windows port of PHP. Apache 1.3.37 exhibits no similar problems. I filed this bug with Apache, but Ruediger Pluem at apache.org says that this is clearly a PHP bug: http://issues.apache.org/bugzilla/show_bug.cgi?id=40496 Reproduce code: --- // create the test folder before running the script! echo getcwd() . br /; chdir(test); echo getcwd() . br /; chdir(..); echo getcwd() . br /; chdir(..); echo getcwd(); Expected result: C:\Web C:\Web\test C:\Web C:\ Actual result: -- C:\Web C:\Web\test C:\Programmer\Apache Group C:\Programmer\Apache Group -- Edit this bug report at http://bugs.php.net/?id=38820edit=1
#38957 [NEW]: multiple prepares DO NOT WORK!
From: xand_smirnov at mail dot ru Operating system: Fedora 5 PHP version: 5.1.6 PHP Bug Type: PDO related Bug description: multiple prepares DO NOT WORK! Description: Second prepare() returns no object so execute() ends with PHP Fatal error: Call to a member function execute() on a non-object in Reproduce code: --- $stmt = $dbh-prepare(SELECT d_pk FROM d WHERE t=1); print_r($stmt); $stmt-execute(); $stmt = $dbh-prepare(SELECT d_pk FROM d WHERE t=2); print_r($stmt); $stmt-execute(); Expected result: PDOStatement Object ( [queryString] = SELECT d_pk FROM d WHERE type=1 ) PDOStatement Object ( [queryString] = SELECT d_pk FROM d WHERE type=2 ) Actual result: -- PDOStatement Object ( [queryString] = SELECT d_pk FROM d WHERE type=1 ) PHP Fatal error: Call to a member function execute() on a non-object in -- Edit bug report at http://bugs.php.net/?id=38957edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38957r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38957r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38957r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38957r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38957r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38957r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38957r=needscript Try newer version:http://bugs.php.net/fix.php?id=38957r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38957r=support Expected behavior:http://bugs.php.net/fix.php?id=38957r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38957r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38957r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38957r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38957r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38957r=dst IIS Stability:http://bugs.php.net/fix.php?id=38957r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38957r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38957r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38957r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38957r=mysqlcfg
#38956 [Opn-Fbk]: seg fault during array_walk due to reallocated stack
ID: 38956 Updated by: [EMAIL PROTECTED] Reported By: jeannielu at hotmail dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Linux 2.6.16-22 PHP Version: 5.1.6 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Previous Comments: [2006-09-26 01:32:58] judas dot iscariote at gmail dot com Looks as a duplicate of 34066 which is fixed in CVS, and will be in 5.2.0 very soon now :) [2006-09-25 22:41:44] jeannielu at hotmail dot com Description: I reliably get a seg fault during execution of array_walk() in our web application. Unfortunately, the seg fault is not reproducible with any simpler test case. gdb shows the death to be here: #0 zend_call_function (fci=0xbfe8bcf0, fci_cache=0xbfe8bd14) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_execute_API.c:859 859 (*fci-params[i])-refcount++; FYI, the call looks like this: array_walk($current_set, array($this, '_format_traffic_data'), $dd ); Where $current_set is a 2-D array of 10x5 elements, $dd another 2-D array of 2x2 elements. Each element is a string of 10-30 characters. However, I don't think the argument details are important. Valgrind shows that zend_call_function died processing the third argument because it referenced memory freed by zend_ptr_stack.h. See attached backtrace. Actual result: -- gdb: #0 zend_call_function (fci=0xbfe8bcf0, fci_cache=0xbfe8bd14) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_execute_API.c:859 #1 0x081bdb35 in php_array_walk (target_hash=0x90472cc, userdata=0x85ebd6c, recursive=0) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/ext/standard/array.c:1099 #2 0x081bdeaf in zif_array_walk (ht=3, return_value=0x904b69c, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/ext/standard/array.c:1159 #3 0x0826af4d in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe8cbd0) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:200 #4 0x0826a6f1 in execute (op_array=0x894b304) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:92 #5 0x0826a928 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe8df80) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:234 #6 0x0826a6f1 in execute (op_array=0x8b12e34) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:92 #7 0x0826a928 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe8f360) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:234 #8 0x0826a6f1 in execute (op_array=0x8ada67c) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:92 #9 0x0826a928 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe90280) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:234 #10 0x0826a6f1 in execute (op_array=0x8ac0bfc) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:92 #11 0x0826a928 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe92240) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:234 #12 0x0826a6f1 in execute (op_array=0x860b9e0) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:92 #13 0x0826a928 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe923b0) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:234 #14 0x0826a6f1 in execute (op_array=0x85f609c) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:92 #15 0x0825471f in zend_execute_scripts (type=8, retval=Variable retval is not available. ) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend.c:1109 #16 0x0822029c in php_execute_script (primary_file=0xbfe947d4) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/main/main.c:1737 #17 0x082ce8ad in main (argc=5, argv=0xbfe94914) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/sapi/cli/php_cli.c:1093 (gdb) print *fci-params[2] $1 = (zval *) 0x39 valgrind: ==7352== LEAK SUMMARY: ==7352==definitely lost: 0 bytes in 0 blocks. ==7352== possibly lost: 1,088 bytes in 1 blocks. ==7352==still reachable: 49,274 bytes in 568 blocks. ==7352== suppressed: 0 bytes in 0 blocks. ==7352== Reachable blocks (those to which a pointer was found) are not shown. ==7352== To see them, rerun with: --show-reachable=yes ==7313== Invalid read of size 4 ==7313==at 0x81BDAF6: php_array_walk (array.c:1090) ==7313==by 0x81BDEAE: zif_array_walk (array.c:1159) ==7313==by 0x826AF4C:
#38819 [Opn-Fbk]: segfault in ldap_get_entries()
ID: 38819 Updated by: [EMAIL PROTECTED] Reported By: madcoder at gmail dot com -Status: Open +Status: Feedback Bug Type: LDAP related Operating System: 2.6.15-gentoo linux amd64 PHP Version: 5.1.6 New Comment: I intentionally said how to reproduce it, not what is the reproduce code. It's clear to me that you're still using the same code, but this code doesn't make much sense to me since I don't have your data, your variables etc. Hence the question - how to reproduce it? Previous Comments: [2006-09-25 23:20:32] madcoder at gmail dot com It's pretty much the same as before... (gdb) bt #0 0x2aae16a8de44 in ldap_count_values (vals=0x559cadc0) at getvalues.c:153 #1 0x555db423 in zif_ldap_get_entries (ht=1436331456, return_value=0x559ca5c0, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1435796224) at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/ext/ldap/ldap.c:1068 #2 0x556e4d20 in zend_do_fcall_common_helper_SPEC ( execute_data=0x7fff942851d0) at zend_vm_execute.h:200 #3 0x556ed112 in ZEND_DO_FCALL_SPEC_CONST_HANDLER ( execute_data=0x7fff942851d0) at zend_vm_execute.h:1640 #4 0x556e43f9 in execute (op_array=0x559c7ae0) at zend_vm_execute.h:92 #5 0x556bf1d8 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/Zend/zend.c:1109 #6 0x55670784 in php_execute_script (primary_file=0x7fff94287790) at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/main/main.c:1737 #7 0x557756f4 in main (argc=3, argv=0x7fff942879c8) at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/sapi/cli/php_cli.c:1093 The ldap code to reproduce the problem is the same as at the beginning of this report... The difference between the code I posted originally and the code that gave me the above output (showing Count: 1), is this: echo done searching\n; echo Count: . ldap_count_entries($_SERVER['ldap'],$r) . entries\n; $info = ldap_get_entries($_SERVER['ldap'], $r); (that is, I added the Count line *after* the original post; everything else is the same) [2006-09-25 21:56:59] [EMAIL PROTECTED] What is the backtrace and how to reproduce it? [2006-09-25 21:42:38] madcoder at gmail dot com I've recompiled PHP with: # emerge -pv php [ebuild R ] dev-lang/php-5.1.6-r4 USE=debug ldap -apache -apache2 -bcmath -berkdb -bzip2 -calendar -cdb -cgi -cjk -cli -concurrentmodphp -crypt -ctype -curl -curlwrappers -db2 -dbase -discard-path -doc -exif -flatfile -force-cgi-redirect -ftp -gd -gd-external -gdbm -gmp -hardenedphp -hash -hyperwave-api -iconv -imap -inifile -interbase -iodbc -ipv6 -java-external -kerberos -libedit -mcve -memlimit -mhash -ming -msql -mssql -mysql -mysqli -ncurses -nls -oci8 -odbc -pcntl -pcre -pdo -pdo-external -pic -posix -postgres -qdbm -readline -recode -reflection -sapdb -sasl -session -sharedext -sharedmem -simplexml -snmp -soap -sockets -spell -spl -sqlite -ssl -sysvipc -threads -tidy -tokenizer -truetype -unicode -vm-goto -vm-switch -wddx -xml -xmlreader -xmlrpc -xmlwriter -xpm -xsl -yaz -zip -zlib (enabling only ldap and debug) It results in the following configure line, as reported by phpinfo(): Configure Command = './configure' '--prefix=/usr/lib64/php5' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/lib64/php5/man' '--infodir=/usr/lib64/php5/info' '--sysconfdir=/etc' '--cache-file=./config.cache' '--with-libdir=lib64' '--enable-cli' '--disable-cgi' '--with-config-file-path=/etc/php/-php5' '--with-config-file-scan-dir=/etc/php/-php5/ext-active' '--without-pear' '--disable-bcmath' '--without-bz2' '--disable-calendar' '--disable-ctype' '--without-curl' '--without-curlwrappers' '--disable-dbase' '--disable-dom' '--disable-exif' '--without-fbsql' '--without-fdftk' '--disable-filepro' '--disable-ftp' '--without-gettext' '--without-gmp' '--disable-hash' '--without-hwapi' '--without-iconv' '--without-informix' '--disable-ipv6' '--without-kerberos' '--disable-libxml' '--disable-mbstring' '--without-mcrypt' '--disable-memory-limit' '--without-mhash' '--without-ming' '--without-msql' '--without-mssql' '--without-ncurses' '--without-openssl' '--without-openssl-dir' '--disable-pcntl' '--without-pcre-regex' '--disable-pdo' '--without-pgsql' '--disable-posix' '--without-pspell' '--without-recode' '--disable-reflection' '--disable-simplexml' '--disable-shmop' '--without-snmp' '--disable-soap' '--disable-sockets' '--disable-spl' '--without-sybase' '--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm' '--without-tidy' '--disable-tokenizer' '--disable-wddx' '--disable-xml' '--disable-xmlreader' '--disable-xmlwriter' '--without-xmlrpc'
#38961 [Fbk-Opn]: Metaphone results in segmentation fault
ID: 38961
User updated by: nikolas dot hagelstein at gmail dot com
Reported By: nikolas dot hagelstein at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Netbsd 3.0.1 AMD64
PHP Version: 5.1.6
New Comment:
So it is eigther a system specific issue (i was able to reproduce it on
2 maschines) or you did not used an utf8 file ;)
Previous Comments:
[2006-09-26 15:32:42] [EMAIL PROTECTED]
Works perfectly fine: string(0)
[2006-09-26 15:16:57] nikolas dot hagelstein at gmail dot com
I can not try that since i am not able to submit real utf8 chars
through my shell.
test.php
?php
echo crash:.metaphone('ö');
?
php test.php
results in a segmentation fault test.php needs to be an UTF8 file.
file -i test.php
test.php: text/plain; charset=utf-8
[2006-09-26 15:09:28] [EMAIL PROTECTED]
./sapi/cli/php -r
'var_dump(metaphone(#1088;#1091;#1089;#1089;#1082;#1080;#1081;
#1103;#1079;#1099;#1082; UTF8));'
string(3) UTF
[2006-09-26 15:06:14] nikolas dot hagelstein at gmail dot com
Starting program: /usr/pkg/bin/php test.php
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x0050c86b in zif_metaphone ()
(gdb) bt
#0 0x0050c86b in zif_metaphone ()
#1 0x0050c761 in zif_metaphone ()
#2 0x0059f489 in execute ()
#3 0x0059ed20 in execute ()
#4 0x00585a06 in zend_execute_scripts ()
#5 0x0054c169 in php_execute_script ()
#6 0x005eac84 in main ()
#7 0x004407a8 in ___start ()
(gdb)
[2006-09-26 14:09:57] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
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/38961
--
Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38961 [Opn-Fbk]: Metaphone results in segmentation fault
ID: 38961
Updated by: [EMAIL PROTECTED]
Reported By: nikolas dot hagelstein at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Netbsd 3.0.1 AMD64
PHP Version: 5.1.6
New Comment:
Can you please try the latest CVS, it has a 64bit fix that may
fix the crash you are experiencing.
Previous Comments:
[2006-09-26 15:35:34] nikolas dot hagelstein at gmail dot com
So it is eigther a system specific issue (i was able to reproduce it on
2 maschines) or you did not used an utf8 file ;)
[2006-09-26 15:32:42] [EMAIL PROTECTED]
Works perfectly fine: string(0)
[2006-09-26 15:16:57] nikolas dot hagelstein at gmail dot com
I can not try that since i am not able to submit real utf8 chars
through my shell.
test.php
?php
echo crash:.metaphone('ö');
?
php test.php
results in a segmentation fault test.php needs to be an UTF8 file.
file -i test.php
test.php: text/plain; charset=utf-8
[2006-09-26 15:09:28] [EMAIL PROTECTED]
./sapi/cli/php -r
'var_dump(metaphone(#1088;#1091;#1089;#1089;#1082;#1080;#1081;
#1103;#1079;#1099;#1082; UTF8));'
string(3) UTF
[2006-09-26 15:06:14] nikolas dot hagelstein at gmail dot com
Starting program: /usr/pkg/bin/php test.php
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x0050c86b in zif_metaphone ()
(gdb) bt
#0 0x0050c86b in zif_metaphone ()
#1 0x0050c761 in zif_metaphone ()
#2 0x0059f489 in execute ()
#3 0x0059ed20 in execute ()
#4 0x00585a06 in zend_execute_scripts ()
#5 0x0054c169 in php_execute_script ()
#6 0x005eac84 in main ()
#7 0x004407a8 in ___start ()
(gdb)
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/38961
--
Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38957 [Opn-Fbk]: multiple prepares DO NOT WORK!
ID: 38957 Updated by: [EMAIL PROTECTED] Reported By: xand_smirnov at mail dot ru -Status: Open +Status: Feedback Bug Type: PDO related Operating System: Fedora 5 PHP Version: 5.1.6 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Previous Comments: [2006-09-26 06:30:27] xand_smirnov at mail dot ru Description: Second prepare() returns no object so execute() ends with PHP Fatal error: Call to a member function execute() on a non-object in Reproduce code: --- $stmt = $dbh-prepare(SELECT d_pk FROM d WHERE t=1); print_r($stmt); $stmt-execute(); $stmt = $dbh-prepare(SELECT d_pk FROM d WHERE t=2); print_r($stmt); $stmt-execute(); Expected result: PDOStatement Object ( [queryString] = SELECT d_pk FROM d WHERE type=1 ) PDOStatement Object ( [queryString] = SELECT d_pk FROM d WHERE type=2 ) Actual result: -- PDOStatement Object ( [queryString] = SELECT d_pk FROM d WHERE type=1 ) PHP Fatal error: Call to a member function execute() on a non-object in -- Edit this bug report at http://bugs.php.net/?id=38957edit=1
#38954 [Opn-Bgs]: PHP cannot connect with MySQL/MySQLi
ID: 38954 Updated by: [EMAIL PROTECTED] Reported By: akaraethon at gmail dot com -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: Windows Server 2003 32bit PHP Version: 5.1.6 New Comment: Still not PHP problem. And I don't see any reasons to post parts of the docs here, it's not a forum. Previous Comments: [2006-09-26 01:31:44] akaraethon at gmail dot com Ok, are you not READING what I write? In my very first post I said I have enabled the DLL file, but PHP will not connect. so why don't we do this, instead of just changing this to bogus (again) lets figure out whats going on, and see if we cant come toan agreement as to the status, if you think its bogus then tell me what to do. [2006-09-25 22:55:25] [EMAIL PROTECTED] www.php.net/mysql MySQL is no longer enabled by default, so the php_mysql.dll DLL must be enabled... [2006-09-25 22:48:05] akaraethon at gmail dot com Well then where is the problem comming from? I HAVE followed ALL the instructions for setup on IIS and MySQL is running fine, so if this isnt a bug then why is it happening? [2006-09-25 20:57:24] [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-25 17:46:08] akaraethon at gmail dot com Description: I have PHP running on Win server ent. ed. 2k3, IIS is my webserver with MySQL as my DB engine, MySQL runs fine, but for some reason PHP cannot connect. I used the PHP.ini-Recomended file, enabled php_mysql.dll, and set up the other basics (webserver root, etc). PHP runs fine, IIS serves pages fine, but any attempt to connect to mysql fails with the error Fatal error: Call to undefined function mysql_connect() in C:\Inetpub\wwwroot\Dragon-Radio\test.php on line 5 I have checked, double checked, tripple checked, and done a complete erase and reinstall of PHP and MySQL, all files are in the correct places, but php just will not connect... Reproduce code: --- URL to page that exemplifies error http://dragon-radio.selfip.net Expected result: PHP should not tell me there is an error Actual result: -- Fatal error: Call to undefined function mysql_connect() in C:\Inetpub\wwwroot\Dragon-Radio\test.php on line 5 -- Edit this bug report at http://bugs.php.net/?id=38954edit=1
#38950 [Opn-Fbk]: script times out long befor reaching max. execution time
ID: 38950
Updated by: [EMAIL PROTECTED]
Reported By: pavel dot stratil-jun at fenix dot cz
-Status: Open
+Status: Feedback
Bug Type: *Encryption and hash functions
Operating System: gentoo (amd64smp)
PHP Version: 5.1.6
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
Previous Comments:
[2006-09-25 15:01:51] pavel dot stratil-jun at fenix dot cz
Description:
when trying to hash large files (cant say yet how large, but a 800MB
file was hashed without problems but a 1300MB file not), the script
times out after about 1 minute even if max. execution time is set to
half an hour. smaller files, such as the 800MB file were successfully
hashed a few times using different hashing methods (in total the script
took about 4 minutes to run).
Reproduce code:
---
// tried both:
$fp = fopen('file.ext', r);
$ctx = hash_init('sha512');
while (!feof($fp)) {
hash_update($ctx, fgets($fp,$bytes));
}
$res_hash = hash_final($ctx); // this would be line 58
fclose($fp);
// and
hash_file('sha512', 'file.ext'); // this would be line 67
// $bytes were set to anywhere from 4kB to 32MB.. same result all the
time
Expected result:
obviously, a hash.
Actual result:
--
Fatal error: Maximum execution time of 1800 seconds exceeded in
/opt/apache/htdocs/hashtest.php on line 58.
or
Fatal error: Maximum execution time of 1800 seconds exceeded in
/opt/apache/htdocs/hashtest.php on line 67.
depending what piece of code was commented.
--
Edit this bug report at http://bugs.php.net/?id=38950edit=1
#38798 [Opn-Asn]: OpenSSL init corrected in php5 but not in php4
ID: 38798 Updated by: [EMAIL PROTECTED] Reported By: fidojones at fidojones dot com -Status: Open +Status: Assigned Bug Type: OpenSSL related Operating System: linux PHP Version: 4.4.4 -Assigned To: +Assigned To: pajoye Previous Comments: [2006-09-12 20:15:47] fidojones at fidojones dot com Description: This bug is corrected in php5, but it's not introduced in php4 an fails exactly as php5. In php 4.4.4 it's not yet. SSL_library_init(); Description: Patch to fix Index: ext/openssl/openssl.c === RCS file: /repository/php-src/ext/openssl/openssl.c,v retrieving revision 1.98.2.1 diff -p -u -r1.98.2.1 openssl.c --- ext/openssl/openssl.c 18 Aug 2005 13:34:37 - 1.98.2.1 +++ ext/openssl/openssl.c 25 Nov 2005 03:03:47 - @@ -584,6 +584,7 @@ PHP_MINIT_FUNCTION(openssl) le_x509 = zend_register_list_destructors_ex(php_x509_free, NULL, OpenSSL X.509, module_number); le_csr = zend_register_list_destructors_ex(php_csr_free, NULL, OpenSSL X.509 CSR, module_number); + SSL_library_init(); OpenSSL_add_all_ciphers(); OpenSSL_add_all_digests(); OpenSSL_add_all_algorithms(); -- Edit this bug report at http://bugs.php.net/?id=38798edit=1
#38949 [Opn-Asn]: Cannot get xmlns value attribute
ID: 38949 Updated by: [EMAIL PROTECTED] Reported By: superruzafa at gmail dot com -Status: Open +Status: Assigned Bug Type: DOM XML related Operating System: Windows XP PHP Version: 5.1.6 -Assigned To: +Assigned To: rrichards Previous Comments: [2006-09-25 14:18:43] superruzafa at gmail dot com Description: Surely this is not a bug, because is too obvious, Perhaps is a fault of W3C spec. I have a xml file, and I try to parse to get xmlns's attributes. Simplely: [test.xml] ?xml version=1.0 encoding=utf-8 ? root xmlns=http://ns; xmlns:ns2=http://ns2; ns2:child / /root Reproduce code: --- $xml=new DOMDocument(); $xml-load(test.xml); echo $xml-documentElement-getAttribute(xmlns); Expected result: http://ns; Actual result: -- -- Edit this bug report at http://bugs.php.net/?id=38949edit=1
#38923 [Opn]: ODBC works through command line but not Apache
ID: 38923
User updated by: matthew dot berry at wolseley dot co dot uk
Reported By: matthew dot berry at wolseley dot co dot uk
Status: Open
Bug Type: ODBC related
Operating System: Unix
PHP Version: 5.1.6
New Comment:
Thought I should just mention that there is no delay in processing the
page through apache. The page is returned within a couple of seconds
(roughly the same length of time taken via cli), almost as if the
connection is dropped immediately (which is not the case as phpinfo
still shows one active connection in odbc at the end of the page). This
is a very irritating problem as we are so desperately close to resolving
this issue.
Previous Comments:
[2006-09-25 08:06:08] matthew dot berry at wolseley dot co dot uk
Settings for Apache are
Timeout 60
KeepAlive On
MaxKeepAliveRequests 200
KeepAliveTimeout 15
StartServers40
ThreadLimit 75
MinSpareThreads 32
MaxSpareThreads 64
MaxClients 300
ThreadsPerChild 75
MaxRequestsPerChild 1
Php.ini are:
max_execution_time = 30 ; Maximum execution time of each script, in
seconds
max_input_time = 60 ; Maximum amount of time each script may spend
parsing request data
memory_limit = 8M ; Maximum amount of memory a script may consume
(8MB)
As stated earlier, the command line returns back and displays row data
in under 2 seconds, but when running through the Apache server, the
code fails to execute. What would cause this difference?
[2006-09-22 15:57:49] [EMAIL PROTECTED]
The warning you're seeing (08S01) is telling you that something
happened with the connection and it was lost. Check your timeouts and
query length to ensure that neither of these is killing the connection.
[2006-09-22 10:52:00] matthew dot berry at wolseley dot co dot uk
Description:
We are using Unix, Apache version 2.0.54 and PHP 5.1.2 to connect to a
database (Northgate Reality) using the Unix ODBC protocol and the
Northgate Unix driver.
When we run the SQL statement shown below through ISQL on the web
server, the expected results are returned.
When we run the PHP page directly on the command line using the PHP
parser, we get the html generated correctly.
When going through Apache we get the following error:
Warning: odbc_do() [function.odbc-do]: SQL error: [Northgate][SNI]
Transport Error : Receive Failure, SQL state 08S01 in SQLExecDirect in
/sites/intranet/wuk/TermsReview/connecttest3.php on line 62
Which is a generic error message.
Part of the code used is shown below:
Reproduce code:
---
$rfp = odbc_connect($rdsn,$ruser,$rpwd);
if($rfp){
echo Connected to .$rdsn.br;
$select = SELECT ACCOUNT_NO, CUSTOMER_NAME FROM
GLOBAL_CUSTOMER_DETAILS WHERE ACCOUNT_NO = '7459C30';
echo $select.br;
$result = ODBC_DO($rfp,$select);
etc etc
Expected result:
The message is produced when it hits the ODBC_DO statement, the
connection to the database succeeds and has been traced.
I have tried several things such as using a persistant connection,
using odbc_prepare before it (which also fails).
When I include phpinfo at the end it shows that there is an active odbc
connection.
I realise that his could be a driver issue (although tracing has shown
otherwise thus far). But the fact that running the exact same page from
the command line works but doesn't through Apache means something ain't
quite right.
--
Edit this bug report at http://bugs.php.net/?id=38923edit=1
#38819 [Fbk-Opn]: segfault in ldap_get_entries()
ID: 38819
User updated by: madcoder at gmail dot com
Reported By: madcoder at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: LDAP related
Operating System: 2.6.15-gentoo linux amd64
PHP Version: 5.1.6
New Comment:
My apologies for misunderstanding...
To reproduce the problem on my system:
1) I connect to the ldap server, which happens to be a Microsoft Active
Directory domain controller, using:
$_SERVER['ldap'] = ldap_connect(ldap://xyzdc02.xyz.acs-inc.com;) or
die(ldap connect failed);
2) Set MSAD-required options:
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($_SERVER['ldap'], LDAP_OPT_REFERRALS, 0);
3) Bind to the LDAP directory with a search user configured with read
access to the directory:
ldap_bind($_SERVER['ldap'], '[EMAIL PROTECTED]', 'some.Pass')
or die('ldap bind failed');
4) Perform a basic search, looking for my User object:
$result = ldap_search($_SERVER['ldap'], 'dc=xyz,dc=acs-inc,dc=com',
'(sAMAccountName=jhansche)',
array('samaccountname','telephonenumber'));
(print a couple of debug messages):
echo done searching\n;
echo Count: . ldap_count_entries($_SERVER['ldap'],$result) .
entries\n;
5) Attempt to fetch the results of the search above:
$info = ldap_get_entries($_SERVER['ldap'], $result);
*** This was the last line to execute before the segfault ***
(print more debugging messages):
echo Done fetching\n;
print_r($info);
==
I then test the script with this command line (ruling out apache as any
part of the problem), and receive these results to stdout/err:
# php -e test.php
done searching
Count: 1 entries
Segmentation fault
==
As a result of that process, running via gdb, I get the backtrace,
which I have posted previously.
==
Running via valgrind, filtering out the valgrind output, the script
*runs fine*, and produces the following output:
# valgrind php -e test.php 2/dev/null
done searching
Count: 1 entries
Done fetching
Array
(
[Full output of the array returned by ldap_get_entries() is
displayed here correctly, but snipped out for brevity's sake]
)
# (end of output)
==
The LDAP server is running Windows Server 2003 SP1. The segmentation
fault occurs when trying to connect to either of the two domain
controllers on the network. The segfault also occurs if I leave off
the LDAP_OPT_REFERRALS = 0 option, and perform a single-level search
directly on the Organizational Unit containing my user account.
==
/etc/openldap/ldap.conf:
BASEdc=xyz,dc=acs-inc,dc=com
URI ldap://xyz.acs-inc.com
TLS_REQCERT never
TLS_CACERT /etc/ssl/certs/xyzdc02.pem
TLS_CACERTDIR /etc/ssl/certs
(note that I am not calling ldap_start_tls() in this test, so the TLS_*
lines are not used)
==
Performing the same query via the command-line 'ldapsearch' utility
from OpenLDAP:
$ ldapsearch -H ldap://xyz.acs-inc.com -D [EMAIL PROTECTED] -w
some.Pass (samaccountname=jhansche) telephonenumber
# LDAPv3
# base with scope subtree
# filter: (samaccountname=jhansche)
# requesting: telephonenumber
# Joe Hansche, Administrators, elp.acs-inc.com
dn: CN=Joe Hansche,OU=Administrators,DC=xyz,DC=acs-inc,DC=com
telephoneNumber: 5492
==
Unfortunately, I don't have another non-MS ldap server to try. It
appears that the search is completed successfully, because the
ldap_count_entries() call returns 1, which is correct. It just
segfaults when trying to retrieve the actual entries with
ldap_get_entries(). I hope that is more informative. If not, please
let me know what additional information I can give you that might help
track this problem down. If you'd like I can try adding some debugging
messages into the ldap portion of the php source to see where it might
be failing, and why?
Thanks, by the way. I appreciate your efforts.
Previous Comments:
[2006-09-26 07:07:20] [EMAIL PROTECTED]
I intentionally said how to reproduce it, not what is the reproduce
code. It's clear to me that you're still using the same code, but this
code doesn't make much sense to me since I don't have your data, your
variables etc.
Hence the question - how to reproduce it?
[2006-09-25 23:20:32] madcoder at gmail dot com
It's pretty much the same as before...
(gdb) bt
#0 0x2aae16a8de44 in ldap_count_values (vals=0x559cadc0)
at getvalues.c:153
#1 0x555db423 in zif_ldap_get_entries (ht=1436331456,
return_value=0x559ca5c0, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1435796224)
at
/var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/ext/ldap/ldap.c:1068
#2 0x556e4d20 in zend_do_fcall_common_helper_SPEC (
execute_data=0x7fff942851d0) at zend_vm_execute.h:200
#3 0x556ed112 in
#38819 [Opn-Fbk]: segfault in ldap_get_entries()
ID: 38819 Updated by: [EMAIL PROTECTED] Reported By: madcoder at gmail dot com -Status: Open +Status: Feedback Bug Type: LDAP related Operating System: 2.6.15-gentoo linux amd64 PHP Version: 5.1.6 New Comment: And what is in vals[0] ? (gdb) p vals[0] Previous Comments: [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. [2006-09-26 10:08:02] [EMAIL PROTECTED] Ok, then please do the following: 1) get OpenLDAP sources from openldap.org (2.3.27 is the current stable version) 2) get PHP 5.1.6 sources from php.net 3) build openldap from the sources with --enable-debug and --prefix=/tmp/openldap 4) build PHP with ./configure --enable-debug --disable-all --with-ldap=/tmp/openldap (no need to run make install, just use CLI binary - ./sapi/cli/php). 5) try to reproduce it again and when/if it segfaults again type the following commands in gdb console: (gdb) f 0 (gdb) p vals (gdb) p i I'd also appreciate if you run it through valgrind and see if there are any errors reported. [2006-09-26 09:48:51] madcoder at gmail dot com No, I'm sorry, it's on a private LAN. A VPN account would be required to gain access to the LAN, and corporate policy won't allow me to grant you that. If you would like to contact me off-bugzilla, I might be able to arrange a different way of accessing the server. [2006-09-26 09:38:39] [EMAIL PROTECTED] Is it possible to get an account @ this server? [2006-09-26 09:36:37] madcoder at gmail dot com Sorry for the extra post... I just tested with different values in ldap_connect. For all values of the hostname parameter that I tried, any that were *NOT* prefixed with ldap://; caused a segmentation fault at line 2: ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3); The various values I tried, all of which resulted in a segfault, were: hostname (xyzdc01 and xyzdc02) IP (172.16.0.50 and 172.16.0.51) FQHN (xyzdc01.xyz.acs-inc.com and xyzdc02.xyz.acs-inc.com) All of the above, when prefixed with ldap://, resulted in the same segfault described initially, at ldap_get_entries(). 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
#38819 [Opn-Fbk]: segfault in ldap_get_entries()
ID: 38819
Updated by: [EMAIL PROTECTED]
Reported By: madcoder at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: LDAP related
Operating System: 2.6.15-gentoo linux amd64
PHP Version: 5.1.6
New Comment:
Is it possible to get an account @ this server?
Previous Comments:
[2006-09-26 09:36:37] madcoder at gmail dot com
Sorry for the extra post... I just tested with different values in
ldap_connect. For all values of the hostname parameter that I tried,
any that were *NOT* prefixed with ldap://; caused a segmentation fault
at line 2:
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
The various values I tried, all of which resulted in a segfault, were:
hostname (xyzdc01 and xyzdc02)
IP (172.16.0.50 and 172.16.0.51)
FQHN (xyzdc01.xyz.acs-inc.com and xyzdc02.xyz.acs-inc.com)
All of the above, when prefixed with ldap://, resulted in the same
segfault described initially, at ldap_get_entries().
[2006-09-26 09:29:47] madcoder at gmail dot com
My apologies for misunderstanding...
To reproduce the problem on my system:
1) I connect to the ldap server, which happens to be a Microsoft Active
Directory domain controller, using:
$_SERVER['ldap'] = ldap_connect(ldap://xyzdc02.xyz.acs-inc.com;) or
die(ldap connect failed);
2) Set MSAD-required options:
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($_SERVER['ldap'], LDAP_OPT_REFERRALS, 0);
3) Bind to the LDAP directory with a search user configured with read
access to the directory:
ldap_bind($_SERVER['ldap'], '[EMAIL PROTECTED]', 'some.Pass')
or die('ldap bind failed');
4) Perform a basic search, looking for my User object:
$result = ldap_search($_SERVER['ldap'], 'dc=xyz,dc=acs-inc,dc=com',
'(sAMAccountName=jhansche)',
array('samaccountname','telephonenumber'));
(print a couple of debug messages):
echo done searching\n;
echo Count: . ldap_count_entries($_SERVER['ldap'],$result) .
entries\n;
5) Attempt to fetch the results of the search above:
$info = ldap_get_entries($_SERVER['ldap'], $result);
*** This was the last line to execute before the segfault ***
(print more debugging messages):
echo Done fetching\n;
print_r($info);
==
I then test the script with this command line (ruling out apache as any
part of the problem), and receive these results to stdout/err:
# php -e test.php
done searching
Count: 1 entries
Segmentation fault
==
As a result of that process, running via gdb, I get the backtrace,
which I have posted previously.
==
Running via valgrind, filtering out the valgrind output, the script
*runs fine*, and produces the following output:
# valgrind php -e test.php 2/dev/null
done searching
Count: 1 entries
Done fetching
Array
(
[Full output of the array returned by ldap_get_entries() is
displayed here correctly, but snipped out for brevity's sake]
)
# (end of output)
==
The LDAP server is running Windows Server 2003 SP1. The segmentation
fault occurs when trying to connect to either of the two domain
controllers on the network. The segfault also occurs if I leave off
the LDAP_OPT_REFERRALS = 0 option, and perform a single-level search
directly on the Organizational Unit containing my user account.
==
/etc/openldap/ldap.conf:
BASEdc=xyz,dc=acs-inc,dc=com
URI ldap://xyz.acs-inc.com
TLS_REQCERT never
TLS_CACERT /etc/ssl/certs/xyzdc02.pem
TLS_CACERTDIR /etc/ssl/certs
(note that I am not calling ldap_start_tls() in this test, so the TLS_*
lines are not used)
==
Performing the same query via the command-line 'ldapsearch' utility
from OpenLDAP:
$ ldapsearch -H ldap://xyz.acs-inc.com -D [EMAIL PROTECTED] -w
some.Pass (samaccountname=jhansche) telephonenumber
# LDAPv3
# base with scope subtree
# filter: (samaccountname=jhansche)
# requesting: telephonenumber
# Joe Hansche, Administrators, elp.acs-inc.com
dn: CN=Joe Hansche,OU=Administrators,DC=xyz,DC=acs-inc,DC=com
telephoneNumber: 5492
==
Unfortunately, I don't have another non-MS ldap server to try. It
appears that the search is completed successfully, because the
ldap_count_entries() call returns 1, which is correct. It just
segfaults when trying to retrieve the actual entries with
ldap_get_entries(). I hope that is more informative. If not, please
let me know what additional information I can give you that might help
track this problem down. If you'd like I can try adding some debugging
messages into the ldap portion of the php source to see where it might
be failing, and why?
Thanks, by the way. I appreciate your efforts.
[2006-09-26 07:07:20] [EMAIL PROTECTED]
I intentionally said how to
#38819 [Fbk-Opn]: segfault in ldap_get_entries()
ID: 38819 User updated by: madcoder at gmail dot com Reported By: madcoder at gmail dot com -Status: Feedback +Status: Open Bug Type: LDAP related Operating System: 2.6.15-gentoo linux amd64 PHP Version: 5.1.6 New Comment: 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. Previous Comments: [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. [2006-09-26 10:08:02] [EMAIL PROTECTED] Ok, then please do the following: 1) get OpenLDAP sources from openldap.org (2.3.27 is the current stable version) 2) get PHP 5.1.6 sources from php.net 3) build openldap from the sources with --enable-debug and --prefix=/tmp/openldap 4) build PHP with ./configure --enable-debug --disable-all --with-ldap=/tmp/openldap (no need to run make install, just use CLI binary - ./sapi/cli/php). 5) try to reproduce it again and when/if it segfaults again type the following commands in gdb console: (gdb) f 0 (gdb) p vals (gdb) p i I'd also appreciate if you run it through valgrind and see if there are any errors reported. 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
#38819 [Opn-Fbk]: segfault in ldap_get_entries()
ID: 38819
Updated by: [EMAIL PROTECTED]
Reported By: madcoder at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: LDAP related
Operating System: 2.6.15-gentoo linux amd64
PHP Version: 5.1.6
New Comment:
Ok, then please do the following:
1) get OpenLDAP sources from openldap.org (2.3.27 is the current stable
version)
2) get PHP 5.1.6 sources from php.net
3) build openldap from the sources with --enable-debug and
--prefix=/tmp/openldap
4) build PHP with ./configure --enable-debug --disable-all
--with-ldap=/tmp/openldap (no need to run make install, just use CLI
binary - ./sapi/cli/php).
5) try to reproduce it again and when/if it segfaults again type the
following commands in gdb console:
(gdb) f 0
(gdb) p vals
(gdb) p i
I'd also appreciate if you run it through valgrind and see if there are
any errors reported.
Previous Comments:
[2006-09-26 09:48:51] madcoder at gmail dot com
No, I'm sorry, it's on a private LAN. A VPN account would be required
to gain access to the LAN, and corporate policy won't allow me to grant
you that. If you would like to contact me off-bugzilla, I might be able
to arrange a different way of accessing the server.
[2006-09-26 09:38:39] [EMAIL PROTECTED]
Is it possible to get an account @ this server?
[2006-09-26 09:36:37] madcoder at gmail dot com
Sorry for the extra post... I just tested with different values in
ldap_connect. For all values of the hostname parameter that I tried,
any that were *NOT* prefixed with ldap://; caused a segmentation fault
at line 2:
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
The various values I tried, all of which resulted in a segfault, were:
hostname (xyzdc01 and xyzdc02)
IP (172.16.0.50 and 172.16.0.51)
FQHN (xyzdc01.xyz.acs-inc.com and xyzdc02.xyz.acs-inc.com)
All of the above, when prefixed with ldap://, resulted in the same
segfault described initially, at ldap_get_entries().
[2006-09-26 09:29:47] madcoder at gmail dot com
My apologies for misunderstanding...
To reproduce the problem on my system:
1) I connect to the ldap server, which happens to be a Microsoft Active
Directory domain controller, using:
$_SERVER['ldap'] = ldap_connect(ldap://xyzdc02.xyz.acs-inc.com;) or
die(ldap connect failed);
2) Set MSAD-required options:
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($_SERVER['ldap'], LDAP_OPT_REFERRALS, 0);
3) Bind to the LDAP directory with a search user configured with read
access to the directory:
ldap_bind($_SERVER['ldap'], '[EMAIL PROTECTED]', 'some.Pass')
or die('ldap bind failed');
4) Perform a basic search, looking for my User object:
$result = ldap_search($_SERVER['ldap'], 'dc=xyz,dc=acs-inc,dc=com',
'(sAMAccountName=jhansche)',
array('samaccountname','telephonenumber'));
(print a couple of debug messages):
echo done searching\n;
echo Count: . ldap_count_entries($_SERVER['ldap'],$result) .
entries\n;
5) Attempt to fetch the results of the search above:
$info = ldap_get_entries($_SERVER['ldap'], $result);
*** This was the last line to execute before the segfault ***
(print more debugging messages):
echo Done fetching\n;
print_r($info);
==
I then test the script with this command line (ruling out apache as any
part of the problem), and receive these results to stdout/err:
# php -e test.php
done searching
Count: 1 entries
Segmentation fault
==
As a result of that process, running via gdb, I get the backtrace,
which I have posted previously.
==
Running via valgrind, filtering out the valgrind output, the script
*runs fine*, and produces the following output:
# valgrind php -e test.php 2/dev/null
done searching
Count: 1 entries
Done fetching
Array
(
[Full output of the array returned by ldap_get_entries() is
displayed here correctly, but snipped out for brevity's sake]
)
# (end of output)
==
The LDAP server is running Windows Server 2003 SP1. The segmentation
fault occurs when trying to connect to either of the two domain
controllers on the network. The segfault also occurs if I leave off
the LDAP_OPT_REFERRALS = 0 option, and perform a single-level search
directly on the Organizational Unit containing my user account.
==
/etc/openldap/ldap.conf:
BASEdc=xyz,dc=acs-inc,dc=com
URI ldap://xyz.acs-inc.com
TLS_REQCERT never
TLS_CACERT /etc/ssl/certs/xyzdc02.pem
TLS_CACERTDIR /etc/ssl/certs
(note that I am not calling ldap_start_tls() in this test, so the TLS_*
lines are not used)
==
Performing the same query via the command-line 'ldapsearch' utility
from OpenLDAP:
$
#38958 [NEW]: bug
From: info at arininav dot ru Operating system: win2003 server PHP version: 5.1.6 PHP Bug Type: Dynamic loading Bug description: bug Description: Hi, Don't load php_oci8.dll from packages 5.1.4, 5, 6. Php_oci8.dll loading if takes it from 5.1.2 only or low. -- Edit bug report at http://bugs.php.net/?id=38958edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38958r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38958r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38958r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38958r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38958r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38958r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38958r=needscript Try newer version:http://bugs.php.net/fix.php?id=38958r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38958r=support Expected behavior:http://bugs.php.net/fix.php?id=38958r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38958r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38958r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38958r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38958r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38958r=dst IIS Stability:http://bugs.php.net/fix.php?id=38958r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38958r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38958r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38958r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38958r=mysqlcfg
#38819 [Fbk-Opn]: segfault in ldap_get_entries()
ID: 38819
User updated by: madcoder at gmail dot com
Reported By: madcoder at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: LDAP related
Operating System: 2.6.15-gentoo linux amd64
PHP Version: 5.1.6
New Comment:
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.
Previous Comments:
[2006-09-26 10:08:02] [EMAIL PROTECTED]
Ok, then please do the following:
1) get OpenLDAP sources from openldap.org (2.3.27 is the current stable
version)
2) get PHP 5.1.6 sources from php.net
3) build openldap from the sources with --enable-debug and
--prefix=/tmp/openldap
4) build PHP with ./configure --enable-debug --disable-all
--with-ldap=/tmp/openldap (no need to run make install, just use CLI
binary - ./sapi/cli/php).
5) try to reproduce it again and when/if it segfaults again type the
following commands in gdb console:
(gdb) f 0
(gdb) p vals
(gdb) p i
I'd also appreciate if you run it through valgrind and see if there are
any errors reported.
[2006-09-26 09:48:51] madcoder at gmail dot com
No, I'm sorry, it's on a private LAN. A VPN account would be required
to gain access to the LAN, and corporate policy won't allow me to grant
you that. If you would like to contact me off-bugzilla, I might be able
to arrange a different way of accessing the server.
[2006-09-26 09:38:39] [EMAIL PROTECTED]
Is it possible to get an account @ this server?
[2006-09-26 09:36:37] madcoder at gmail dot com
Sorry for the extra post... I just tested with different values in
ldap_connect. For all values of the hostname parameter that I tried,
any that were *NOT* prefixed with ldap://; caused a segmentation fault
at line 2:
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
The various values I tried, all of which resulted in a segfault, were:
hostname (xyzdc01 and xyzdc02)
IP (172.16.0.50 and 172.16.0.51)
FQHN (xyzdc01.xyz.acs-inc.com and xyzdc02.xyz.acs-inc.com)
All of the above, when prefixed with ldap://, resulted in the same
segfault described initially, at ldap_get_entries().
[2006-09-26 09:29:47] madcoder at gmail dot com
My apologies for misunderstanding...
To reproduce the problem on my system:
1) I connect to the ldap server, which happens to be a Microsoft Active
Directory domain controller, using:
$_SERVER['ldap'] = ldap_connect(ldap://xyzdc02.xyz.acs-inc.com;) or
die(ldap connect failed);
2) Set MSAD-required options:
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($_SERVER['ldap'], LDAP_OPT_REFERRALS, 0);
3) Bind to the LDAP directory with a search user configured with read
access to the directory:
ldap_bind($_SERVER['ldap'], '[EMAIL PROTECTED]', 'some.Pass')
or die('ldap bind failed');
4) Perform a basic search, looking for my User object:
$result = ldap_search($_SERVER['ldap'], 'dc=xyz,dc=acs-inc,dc=com',
'(sAMAccountName=jhansche)',
array('samaccountname','telephonenumber'));
(print a couple of debug messages):
echo done searching\n;
echo Count: . ldap_count_entries($_SERVER['ldap'],$result) .
entries\n;
5) Attempt to fetch the results of the search above:
$info = ldap_get_entries($_SERVER['ldap'], $result);
*** This was the last line to execute before the segfault ***
(print more debugging messages):
echo Done fetching\n;
print_r($info);
==
I then test the script with this command line (ruling out apache as any
part of the problem), and receive these results to stdout/err:
# php -e test.php
done searching
Count: 1 entries
Segmentation fault
==
As a result of that process,
#38819 [Opn-Fbk]: segfault in ldap_get_entries()
ID: 38819 Updated by: [EMAIL PROTECTED] Reported By: madcoder at gmail dot com -Status: Open +Status: Feedback Bug Type: LDAP related Operating System: 2.6.15-gentoo linux amd64 PHP Version: 5.1.6 New Comment: Is it possible to perform the same actions using ldapsearch utility in console? Previous Comments: [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. [2006-09-26 10:08:02] [EMAIL PROTECTED] Ok, then please do the following: 1) get OpenLDAP sources from openldap.org (2.3.27 is the current stable version) 2) get PHP 5.1.6 sources from php.net 3) build openldap from the sources with --enable-debug and --prefix=/tmp/openldap 4) build PHP with ./configure --enable-debug --disable-all --with-ldap=/tmp/openldap (no need to run make install, just use CLI binary - ./sapi/cli/php). 5) try to reproduce it again and when/if it segfaults again type the following commands in gdb console: (gdb) f 0 (gdb) p vals (gdb) p i I'd also appreciate if you run it through valgrind and see if there are any errors reported. [2006-09-26 09:48:51] madcoder at gmail dot com No, I'm sorry, it's on a private LAN. A VPN account would be required to gain access to the LAN, and corporate policy won't allow me to grant you that. If you would like to contact me off-bugzilla, I might be able to arrange a different way of accessing the server. 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
#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:
Sorry for the extra post... I just tested with different values in
ldap_connect. For all values of the hostname parameter that I tried,
any that were *NOT* prefixed with ldap://; caused a segmentation fault
at line 2:
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
The various values I tried, all of which resulted in a segfault, were:
hostname (xyzdc01 and xyzdc02)
IP (172.16.0.50 and 172.16.0.51)
FQHN (xyzdc01.xyz.acs-inc.com and xyzdc02.xyz.acs-inc.com)
All of the above, when prefixed with ldap://, resulted in the same
segfault described initially, at ldap_get_entries().
Previous Comments:
[2006-09-26 09:29:47] madcoder at gmail dot com
My apologies for misunderstanding...
To reproduce the problem on my system:
1) I connect to the ldap server, which happens to be a Microsoft Active
Directory domain controller, using:
$_SERVER['ldap'] = ldap_connect(ldap://xyzdc02.xyz.acs-inc.com;) or
die(ldap connect failed);
2) Set MSAD-required options:
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($_SERVER['ldap'], LDAP_OPT_REFERRALS, 0);
3) Bind to the LDAP directory with a search user configured with read
access to the directory:
ldap_bind($_SERVER['ldap'], '[EMAIL PROTECTED]', 'some.Pass')
or die('ldap bind failed');
4) Perform a basic search, looking for my User object:
$result = ldap_search($_SERVER['ldap'], 'dc=xyz,dc=acs-inc,dc=com',
'(sAMAccountName=jhansche)',
array('samaccountname','telephonenumber'));
(print a couple of debug messages):
echo done searching\n;
echo Count: . ldap_count_entries($_SERVER['ldap'],$result) .
entries\n;
5) Attempt to fetch the results of the search above:
$info = ldap_get_entries($_SERVER['ldap'], $result);
*** This was the last line to execute before the segfault ***
(print more debugging messages):
echo Done fetching\n;
print_r($info);
==
I then test the script with this command line (ruling out apache as any
part of the problem), and receive these results to stdout/err:
# php -e test.php
done searching
Count: 1 entries
Segmentation fault
==
As a result of that process, running via gdb, I get the backtrace,
which I have posted previously.
==
Running via valgrind, filtering out the valgrind output, the script
*runs fine*, and produces the following output:
# valgrind php -e test.php 2/dev/null
done searching
Count: 1 entries
Done fetching
Array
(
[Full output of the array returned by ldap_get_entries() is
displayed here correctly, but snipped out for brevity's sake]
)
# (end of output)
==
The LDAP server is running Windows Server 2003 SP1. The segmentation
fault occurs when trying to connect to either of the two domain
controllers on the network. The segfault also occurs if I leave off
the LDAP_OPT_REFERRALS = 0 option, and perform a single-level search
directly on the Organizational Unit containing my user account.
==
/etc/openldap/ldap.conf:
BASEdc=xyz,dc=acs-inc,dc=com
URI ldap://xyz.acs-inc.com
TLS_REQCERT never
TLS_CACERT /etc/ssl/certs/xyzdc02.pem
TLS_CACERTDIR /etc/ssl/certs
(note that I am not calling ldap_start_tls() in this test, so the TLS_*
lines are not used)
==
Performing the same query via the command-line 'ldapsearch' utility
from OpenLDAP:
$ ldapsearch -H ldap://xyz.acs-inc.com -D [EMAIL PROTECTED] -w
some.Pass (samaccountname=jhansche) telephonenumber
# LDAPv3
# base with scope subtree
# filter: (samaccountname=jhansche)
# requesting: telephonenumber
# Joe Hansche, Administrators, elp.acs-inc.com
dn: CN=Joe Hansche,OU=Administrators,DC=xyz,DC=acs-inc,DC=com
telephoneNumber: 5492
==
Unfortunately, I don't have another non-MS ldap server to try. It
appears that the search is completed successfully, because the
ldap_count_entries() call returns 1, which is correct. It just
segfaults when trying to retrieve the actual entries with
ldap_get_entries(). I hope that is more informative. If not, please
let me know what additional information I can give you that might help
track this problem down. If you'd like I can try adding some debugging
messages into the ldap portion of the php source to see where it might
be failing, and why?
Thanks, by the way. I appreciate your efforts.
[2006-09-26 07:07:20] [EMAIL PROTECTED]
I intentionally said how to reproduce it, not what is the reproduce
code. It's clear to me that you're still using the same code, but this
code doesn't make much sense to me since I don't have your data, your
variables
#38819 [Fbk-Opn]: segfault in ldap_get_entries()
ID: 38819 User updated by: madcoder at gmail dot com Reported By: madcoder at gmail dot com -Status: Feedback +Status: Open Bug Type: LDAP related Operating System: 2.6.15-gentoo linux amd64 PHP Version: 5.1.6 New Comment: 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'. Previous Comments: [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. [2006-09-26 10:08:02] [EMAIL PROTECTED] Ok, then please do the following: 1) get OpenLDAP sources from openldap.org (2.3.27 is the current stable version) 2) get PHP 5.1.6 sources from php.net 3) build openldap from the sources with --enable-debug and --prefix=/tmp/openldap 4) build PHP with ./configure --enable-debug --disable-all --with-ldap=/tmp/openldap (no need to run make install, just use CLI binary - ./sapi/cli/php). 5) try to reproduce it again and when/if it segfaults again type the following commands in gdb console: (gdb) f 0 (gdb) p vals (gdb) p i I'd also appreciate if you run it through valgrind and see if there are any errors reported. [2006-09-26 09:48:51] madcoder at gmail dot com No, I'm sorry, it's on a private LAN. A VPN account would be required to gain access to the LAN, and corporate policy won't allow me to grant you that. If you would like to contact me off-bugzilla, I might be able to arrange a different way of accessing the server. [2006-09-26 09:38:39] [EMAIL PROTECTED] Is it possible to get an account @ this server? 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
#38960 [Opn-Fbk]: OCI8 failure...
ID: 38960 Updated by: [EMAIL PROTECTED] Reported By: sn4265 at att dot com -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: HPUX 11.11 PHP Version: 5.1.6 New Comment: Does it work for you with Oracle Instant Client - http://www.oracle.com/technology/tech/oci/instantclient/index.html ? Previous Comments: [2006-09-26 12:18:09] sn4265 at att dot com Description: I am attempting to build a working version of Apache 2.0.59 with PHP 5.1.6. I am doing this under HPUX 11.11, and have sucessfully built Apache, and PHP without OCI8 support. The problem is when I attempt to include OCI8 support either in the PHP build directly or by attempting to build the oci8-1.2.2 package after the fact. Here is the attempt buildint OCI8 after the fact. The error is identical when attempting to build PHP with OCI8 support too. Reproduce code: --- [EMAIL PROTECTED]:/www/tmp/oci8-1.2.2 phpize Configuring for: PHP Api Version: 20041225 Zend Module Api No: 20050922 Zend Extension Api No: 220051025 [EMAIL PROTECTED]:/www/tmp/oci8-1.2.2 ./configure checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for a sed that does not truncate output... /usr/bin/sed checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes [EMAIL PROTECTED]:/www/tmp/oci8-1.2.2 make /usr/bin/posix/sh /www/tmp/oci8-1.2.2/libtool --mode=compile gcc -I. -I/www/tmp/oci8-1.2.2 -DPHP_ATOM_INC -I/www/tmp/oci8-1.2.2/include -I/www/tmp/oci8-1.2.2/main -I/www/tmp/oci8-1.2.2 -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -I/usr/local/include/php/ext -I/usr/local/oracle/8.0.6.3/rdbms/demo -I/usr/local/oracle/8.0.6.3/network/public -DHAVE_CONFIG_H -g -O2 -c /www/tmp/oci8-1.2.2/oci8.c -o oci8.lo mkdir .libs gcc -I. -I/www/tmp/oci8-1.2.2 -DPHP_ATOM_INC -I/www/tmp/oci8-1.2.2/include -I/www/tmp/oci8-1.2.2/main -I/www/tmp/oci8-1.2.2 -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -I/usr/local/include/php/ext -I/usr/local/oracle/8.0.6.3/rdbms/demo -I/usr/local/oracle/8.0.6.3/network/public -DHAVE_CONFIG_H -g -O2 -c /www/tmp/oci8-1.2.2/oci8.c -fPIC -DPIC -o .libs/oci8.o /www/tmp/oci8-1.2.2/oci8.c: In function `php_oci_connection_status': /www/tmp/oci8-1.2.2/oci8.c:1429: error: `OCI_ATTR_SERVER_STATUS' undeclared (first use in this function) /www/tmp/oci8-1.2.2/oci8.c:1429: error: (Each undeclared identifier is reported only once /www/tmp/oci8-1.2.2/oci8.c:1429: error: for each function it appears in.) /www/tmp/oci8-1.2.2/oci8.c:1431: error: `OCI_SERVER_NORMAL' undeclared (first use in this function) *** Error exit code 1 Stop. Expected result: Return a sucessful build. Actual result: -- /www/tmp/oci8-1.2.2/oci8.c: In function `php_oci_connection_status': /www/tmp/oci8-1.2.2/oci8.c:1429: error: `OCI_ATTR_SERVER_STATUS' undeclared (first use in this function) /www/tmp/oci8-1.2.2/oci8.c:1429: error: (Each undeclared identifier is reported only once /www/tmp/oci8-1.2.2/oci8.c:1429: error: for each function it appears in.) /www/tmp/oci8-1.2.2/oci8.c:1431: error: `OCI_SERVER_NORMAL' undeclared (first use in this function) *** Error exit code 1 Stop. -- Edit this bug report at http://bugs.php.net/?id=38960edit=1
#38757 [Asn]: MultiPart Form Uploads fail with FastCGI
ID: 38757
User updated by: davidb at pins dot net
Reported By: davidb at pins dot net
Status: Assigned
Bug Type: Apache related
Operating System: Solaris 8
PHP Version: 5.1.6
Assigned To: dmitry
New Comment:
Greetings.
I pulled the file out of CVS and built it. I see that the line you
changed is the struct tv{} stuff. After some testing, it looks like
moving it to 5 seconds helped, but did not fix the problem 100% of the
time.
I moved it to 20 seconds, and that seems to fix the problem for our
developers in Australia who were experiencing it the most. I also
backported this into 5.1.6 (it was only the single line change) and
that seems to work there as well.
Can we put this on closed for now, and I'll reopen it if it doesn't fix
it permenantly?
Previous Comments:
[2006-09-20 14:50:28] davidb at pins dot net
I just downloaded the latest snap php5.2-200609200230, but the poll()
still shows the same thing:
poll(0xFFBEDB18, 1, 1000) = 1
can you please tell me where to get the right stuff to test?
Thanks.
[2006-09-19 20:52:55] davidb at pins dot net
Ummm...well, here's what I installed:
php5.2-200609141630
Does this have what I need? If not, can you tell me what URL to go
look for? I went to the snaps.php.net page for this.
[2006-09-19 20:43:12] [EMAIL PROTECTED]
You have tested the old version, pool(..., 1000) means 1 second
timeout. In new version you should have 5 seconds.
[2006-09-18 21:29:16] davidb at pins dot net
One other thing which we noticed - if we take our sample
(which breaks) and change the multipart-form to a regular
form, the problem does not occur.
This is weird, and I have no idea how it may bear into the
problem. It may be a red herring of some sort. Any ideas on
the next step in debugging?
[2006-09-15 03:51:35] davidb at pins dot net
Greetings.
I tried with the latest 5.2 (downloaded today). It doesn't seem to
make a difference. The poll() still exits with 0, then proceeds to
read everything in anyway. Heres the truss, with timestamps this
time:
94.3878 accept(0, 0xFFBEDC78, 0xFFBEDBC4, 1)= 4
AF_UNIX name =
94.3880 fcntl(0, F_SETLK, 0xFFBEDC50) = 0
typ=F_UNLCK whence=SEEK_SET start=0 len=0
sys=4290697848 pid=2086536
95.3952 poll(0xFFBEDB18, 1, 1000) = 0
fd=4 ev=POLLRDNORM rev=0
95.3959 shutdown(4, 1, 1) = 0
recv(4, 0xFFBEDC50, 8, 0) (sleeping...)
signotifywait() (sleeping...)
lwp_sema_wait(0xFD70DE60) (sleeping...)
sema type: USYNC_THREAD count = 0
103.4047recv(4, 0101\001\0\b\0\0, 8, 0) = 8
103.4050recv(4, \001\0\0\0\0\0\0, 8, 0) = 8
103.4051recv(4, 0104\001\016\0\0, 8, 0) = 8
103.4051recv(4, 0E06 C O N T E N, 8, 0) = 8
103.4052recv(4, T _ L E N G T H, 8, 0) = 8
103.4053recv(4, 1 2 8 9 9 00104, 8, 0) = 8
103.4054recv(4, \001\0 E\0\0\f 7, 8, 0) = 8
103.4055recv(4, C O N T E N T _, 8, 0) = 8
103.4055recv(4, T Y P E m u l t, 8, 0) = 8
I guess the big question is why is poll exiting with 0 when there's a
pile of valid data?
David.
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/38757
--
Edit this bug report at http://bugs.php.net/?id=38757edit=1
#38960 [NEW]: OCI8 failure...
From: sn4265 at att dot com Operating system: HPUX 11.11 PHP version: 5.1.6 PHP Bug Type: Compile Failure Bug description: OCI8 failure... Description: I am attempting to build a working version of Apache 2.0.59 with PHP 5.1.6. I am doing this under HPUX 11.11, and have sucessfully built Apache, and PHP without OCI8 support. The problem is when I attempt to include OCI8 support either in the PHP build directly or by attempting to build the oci8-1.2.2 package after the fact. Here is the attempt buildint OCI8 after the fact. The error is identical when attempting to build PHP with OCI8 support too. Reproduce code: --- [EMAIL PROTECTED]:/www/tmp/oci8-1.2.2 phpize Configuring for: PHP Api Version: 20041225 Zend Module Api No: 20050922 Zend Extension Api No: 220051025 [EMAIL PROTECTED]:/www/tmp/oci8-1.2.2 ./configure checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for a sed that does not truncate output... /usr/bin/sed checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes [EMAIL PROTECTED]:/www/tmp/oci8-1.2.2 make /usr/bin/posix/sh /www/tmp/oci8-1.2.2/libtool --mode=compile gcc -I. -I/www/tmp/oci8-1.2.2 -DPHP_ATOM_INC -I/www/tmp/oci8-1.2.2/include -I/www/tmp/oci8-1.2.2/main -I/www/tmp/oci8-1.2.2 -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -I/usr/local/include/php/ext -I/usr/local/oracle/8.0.6.3/rdbms/demo -I/usr/local/oracle/8.0.6.3/network/public -DHAVE_CONFIG_H -g -O2 -c /www/tmp/oci8-1.2.2/oci8.c -o oci8.lo mkdir .libs gcc -I. -I/www/tmp/oci8-1.2.2 -DPHP_ATOM_INC -I/www/tmp/oci8-1.2.2/include -I/www/tmp/oci8-1.2.2/main -I/www/tmp/oci8-1.2.2 -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -I/usr/local/include/php/ext -I/usr/local/oracle/8.0.6.3/rdbms/demo -I/usr/local/oracle/8.0.6.3/network/public -DHAVE_CONFIG_H -g -O2 -c /www/tmp/oci8-1.2.2/oci8.c -fPIC -DPIC -o .libs/oci8.o /www/tmp/oci8-1.2.2/oci8.c: In function `php_oci_connection_status': /www/tmp/oci8-1.2.2/oci8.c:1429: error: `OCI_ATTR_SERVER_STATUS' undeclared (first use in this function) /www/tmp/oci8-1.2.2/oci8.c:1429: error: (Each undeclared identifier is reported only once /www/tmp/oci8-1.2.2/oci8.c:1429: error: for each function it appears in.) /www/tmp/oci8-1.2.2/oci8.c:1431: error: `OCI_SERVER_NORMAL' undeclared (first use in this function) *** Error exit code 1 Stop. Expected result: Return a sucessful build. Actual result: -- /www/tmp/oci8-1.2.2/oci8.c: In function `php_oci_connection_status': /www/tmp/oci8-1.2.2/oci8.c:1429: error: `OCI_ATTR_SERVER_STATUS' undeclared (first use in this function) /www/tmp/oci8-1.2.2/oci8.c:1429: error: (Each undeclared identifier is reported only once /www/tmp/oci8-1.2.2/oci8.c:1429: error: for each function it appears in.) /www/tmp/oci8-1.2.2/oci8.c:1431: error: `OCI_SERVER_NORMAL' undeclared (first use in this function) *** Error exit code 1 Stop. -- Edit bug report at http://bugs.php.net/?id=38960edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38960r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38960r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38960r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38960r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38960r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38960r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38960r=needscript Try newer version:http://bugs.php.net/fix.php?id=38960r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38960r=support Expected behavior:http://bugs.php.net/fix.php?id=38960r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38960r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38960r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38960r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38960r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38960r=dst IIS Stability:http://bugs.php.net/fix.php?id=38960r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38960r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38960r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38960r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38960r=mysqlcfg
#38950 [Fbk-Opn]: script times out long befor reaching max. execution time
ID: 38950
User updated by: pavel dot stratil-jun at fenix dot cz
Reported By: pavel dot stratil-jun at fenix dot cz
-Status: Feedback
+Status: Open
Bug Type: *Encryption and hash functions
Operating System: gentoo (amd64smp)
PHP Version: 5.1.6
New Comment:
seems that the problem is in
$fp = fopen('test', r);
$ctx = hash_init('sha512');
while (!feof($fp)) {
hash_update($ctx, fgets($fp, 4096));
}
$uplo_mhash = hash_final($ctx);
fclose($fp);
when calling the script from apache. When running from shell the
problem disappears completely. In apache the premature timeout problem
disappeared in the snapshot version, but streaming hashing still fails
on large files (the script timeouts for real after max_execution_time
even on relatively small files, compared to the first tests - i.e.
200MB). Hash_file() seems to work flawlesly. When going towards smaller
files, streaming hashing catches on and is about 60% the speed of
hash_file.
Tried this with apache 2.2.2 and 2.2.3 with modified as well as
distribution configurations with the same result.
tested on
php5.2-200609261030
./configure --prefix=${PHP_PATH} --with-apxs2=${APACHE_PATH}/bin/apxs
gmake # ok
gmake test # failed in 4 tests
# Test for buffering in core functions with implicit flush off
[tests/func/008.phpt]
# Bug #16069 [ext/iconv/tests/bug16069.phpt]
#iconv stream filter [ext/iconv/tests/iconv_stream_filter.phpt]
# Math constants [ext/standard/tests/math/constants.phpt]
ps: dont know how far the development of php 5.2 is but i was getting
many compile failures when trying to build with some common extensions
such as imap (against imap2006) or mysqli (5.1.11).
Previous Comments:
[2006-09-26 09:13:41] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-09-25 15:01:51] pavel dot stratil-jun at fenix dot cz
Description:
when trying to hash large files (cant say yet how large, but a 800MB
file was hashed without problems but a 1300MB file not), the script
times out after about 1 minute even if max. execution time is set to
half an hour. smaller files, such as the 800MB file were successfully
hashed a few times using different hashing methods (in total the script
took about 4 minutes to run).
Reproduce code:
---
// tried both:
$fp = fopen('file.ext', r);
$ctx = hash_init('sha512');
while (!feof($fp)) {
hash_update($ctx, fgets($fp,$bytes));
}
$res_hash = hash_final($ctx); // this would be line 58
fclose($fp);
// and
hash_file('sha512', 'file.ext'); // this would be line 67
// $bytes were set to anywhere from 4kB to 32MB.. same result all the
time
Expected result:
obviously, a hash.
Actual result:
--
Fatal error: Maximum execution time of 1800 seconds exceeded in
/opt/apache/htdocs/hashtest.php on line 58.
or
Fatal error: Maximum execution time of 1800 seconds exceeded in
/opt/apache/htdocs/hashtest.php on line 67.
depending what piece of code was commented.
--
Edit this bug report at http://bugs.php.net/?id=38950edit=1
#38950 [Opn-Fbk]: script times out long befor reaching max. execution time
ID: 38950
Updated by: [EMAIL PROTECTED]
Reported By: pavel dot stratil-jun at fenix dot cz
-Status: Open
+Status: Feedback
Bug Type: *Encryption and hash functions
Operating System: gentoo (amd64smp)
PHP Version: 5.1.6
New Comment:
but streaming hashing still fails on large files (the
script timeouts for real after max_execution_time even on
relatively small files, compared to the first tests - i.e.
200MB)
Please elaborate.
many compile failures when trying to build with some
common extensions such as imap (against imap2006) or
mysqli (5.1.11).
Please report them as separate issues.
Previous Comments:
[2006-09-26 12:45:31] pavel dot stratil-jun at fenix dot cz
seems that the problem is in
$fp = fopen('test', r);
$ctx = hash_init('sha512');
while (!feof($fp)) {
hash_update($ctx, fgets($fp, 4096));
}
$uplo_mhash = hash_final($ctx);
fclose($fp);
when calling the script from apache. When running from shell the
problem disappears completely. In apache the premature timeout problem
disappeared in the snapshot version, but streaming hashing still fails
on large files (the script timeouts for real after max_execution_time
even on relatively small files, compared to the first tests - i.e.
200MB). Hash_file() seems to work flawlesly. When going towards smaller
files, streaming hashing catches on and is about 60% the speed of
hash_file.
Tried this with apache 2.2.2 and 2.2.3 with modified as well as
distribution configurations with the same result.
tested on
php5.2-200609261030
./configure --prefix=${PHP_PATH} --with-apxs2=${APACHE_PATH}/bin/apxs
gmake # ok
gmake test # failed in 4 tests
# Test for buffering in core functions with implicit flush off
[tests/func/008.phpt]
# Bug #16069 [ext/iconv/tests/bug16069.phpt]
#iconv stream filter [ext/iconv/tests/iconv_stream_filter.phpt]
# Math constants [ext/standard/tests/math/constants.phpt]
ps: dont know how far the development of php 5.2 is but i was getting
many compile failures when trying to build with some common extensions
such as imap (against imap2006) or mysqli (5.1.11).
[2006-09-26 09:13:41] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-09-25 15:01:51] pavel dot stratil-jun at fenix dot cz
Description:
when trying to hash large files (cant say yet how large, but a 800MB
file was hashed without problems but a 1300MB file not), the script
times out after about 1 minute even if max. execution time is set to
half an hour. smaller files, such as the 800MB file were successfully
hashed a few times using different hashing methods (in total the script
took about 4 minutes to run).
Reproduce code:
---
// tried both:
$fp = fopen('file.ext', r);
$ctx = hash_init('sha512');
while (!feof($fp)) {
hash_update($ctx, fgets($fp,$bytes));
}
$res_hash = hash_final($ctx); // this would be line 58
fclose($fp);
// and
hash_file('sha512', 'file.ext'); // this would be line 67
// $bytes were set to anywhere from 4kB to 32MB.. same result all the
time
Expected result:
obviously, a hash.
Actual result:
--
Fatal error: Maximum execution time of 1800 seconds exceeded in
/opt/apache/htdocs/hashtest.php on line 58.
or
Fatal error: Maximum execution time of 1800 seconds exceeded in
/opt/apache/htdocs/hashtest.php on line 67.
depending what piece of code was commented.
--
Edit this bug report at http://bugs.php.net/?id=38950edit=1
#38961 [Opn-Fbk]: Metaphone results in segmentation fault
ID: 38961
Updated by: [EMAIL PROTECTED]
Reported By: nikolas dot hagelstein at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Netbsd 3.0.1 AMD64
PHP Version: 5.1.6
New Comment:
./sapi/cli/php -r
'var_dump(metaphone(#1088;#1091;#1089;#1089;#1082;#1080;#1081;
#1103;#1079;#1099;#1082; UTF8));'
string(3) UTF
Previous Comments:
[2006-09-26 15:06:14] nikolas dot hagelstein at gmail dot com
Starting program: /usr/pkg/bin/php test.php
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x0050c86b in zif_metaphone ()
(gdb) bt
#0 0x0050c86b in zif_metaphone ()
#1 0x0050c761 in zif_metaphone ()
#2 0x0059f489 in execute ()
#3 0x0059ed20 in execute ()
#4 0x00585a06 in zend_execute_scripts ()
#5 0x0054c169 in php_execute_script ()
#6 0x005eac84 in main ()
#7 0x004407a8 in ___start ()
(gdb)
[2006-09-26 14:09:57] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2006-09-26 14:01:12] nikolas dot hagelstein at gmail dot com
Description:
Passing utf8 data to metaphone results in a segmentation fault.
Reproduce code:
---
?PHP
//replace xxx with native utf8 chars e.g. copy and paste from
a russian website. The document itself needs to be of ut8 too
echo crash:.metaphone('xxx');
?
--
Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38950 [Opn-Fbk]: script times out long befor reaching max. execution time
ID: 38950
Updated by: [EMAIL PROTECTED]
Reported By: pavel dot stratil-jun at fenix dot cz
-Status: Open
+Status: Feedback
Bug Type: *Encryption and hash functions
Operating System: gentoo (amd64smp)
PHP Version: 5.1.6
New Comment:
on php 5.2 after running for 1800 seconds (checked with a
stopwatch): Fatal error: Maximum execution time of 1800
seconds exceeded
So it does work fine, right?
Previous Comments:
[2006-09-26 15:14:54] pavel dot stratil-jun at fenix dot cz
* Reproduce what?
reproduce the timeout error when trying streaming hashing.
* What is the value of max_execution_time?
1800 seconds
* What is the error message?
on php 5.1.6 after running for about a minute (checked with a
stopwatch): Fatal error: Maximum execution time of 1800 seconds
exceeded in
/opt/apache/htdocs/hashtest.php on line 58.
on php 5.2 after running for 1800 seconds (checked with a stopwatch):
Fatal error: Maximum execution time of 1800 seconds exceeded in
/opt/apache/htdocs/hashtest.php on line 58.
My totally naive guess is that during the while loop the eof might not
be properly recognised (on both versions) or that the loop itself has
some counter which for some reason signals to php that the script timed
out even if it didnt.
[2006-09-26 14:24:44] [EMAIL PROTECTED]
Reproduce what? What is the value of max_execution_time? What is the
error message? What is the real amount of time spent and how did you
measure it?
[2006-09-26 14:19:35] pavel dot stratil-jun at fenix dot cz
I cant find the rule in the problem. I was able to reproduce it always
on files 1.2GB. I could reproduce it sometimes on files ranging from
70MB to 1.2GB and I havent been able to reproduce on files 70MB.
[2006-09-26 12:59:18] [EMAIL PROTECTED]
but streaming hashing still fails on large files (the
script timeouts for real after max_execution_time even on
relatively small files, compared to the first tests - i.e.
200MB)
Please elaborate.
many compile failures when trying to build with some
common extensions such as imap (against imap2006) or
mysqli (5.1.11).
Please report them as separate issues.
[2006-09-26 12:45:31] pavel dot stratil-jun at fenix dot cz
seems that the problem is in
$fp = fopen('test', r);
$ctx = hash_init('sha512');
while (!feof($fp)) {
hash_update($ctx, fgets($fp, 4096));
}
$uplo_mhash = hash_final($ctx);
fclose($fp);
when calling the script from apache. When running from shell the
problem disappears completely. In apache the premature timeout problem
disappeared in the snapshot version, but streaming hashing still fails
on large files (the script timeouts for real after max_execution_time
even on relatively small files, compared to the first tests - i.e.
200MB). Hash_file() seems to work flawlesly. When going towards smaller
files, streaming hashing catches on and is about 60% the speed of
hash_file.
Tried this with apache 2.2.2 and 2.2.3 with modified as well as
distribution configurations with the same result.
tested on
php5.2-200609261030
./configure --prefix=${PHP_PATH} --with-apxs2=${APACHE_PATH}/bin/apxs
gmake # ok
gmake test # failed in 4 tests
# Test for buffering in core functions with implicit flush off
[tests/func/008.phpt]
# Bug #16069 [ext/iconv/tests/bug16069.phpt]
#iconv stream filter [ext/iconv/tests/iconv_stream_filter.phpt]
# Math constants [ext/standard/tests/math/constants.phpt]
ps: dont know how far the development of php 5.2 is but i was getting
many compile failures when trying to build with some common extensions
such as imap (against imap2006) or mysqli (5.1.11).
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/38950
--
Edit this bug report at http://bugs.php.net/?id=38950edit=1
#38963 [NEW]: tempnam bypasses open_basedir
From: manuel at mausz dot at Operating system: Linux/Gentoo PHP version: 4.4.4 PHP Bug Type: Filesystem function related Bug description: tempnam bypasses open_basedir Description: tempnam bypasses open_basedir if dir = false Reproduce code: --- ?php $tempfile = tempnam(false, phptest); ? Expected result: Warning: tempnam() [function.tempnam]: open_basedir restriction in effect. File(/tmp) is not within the allowed path(s): (...) in Actual result: -- # ls /tmp/phptest* /tmp/phptestt4mIOa -- Edit bug report at http://bugs.php.net/?id=38963edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38963r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38963r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38963r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38963r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38963r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38963r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38963r=needscript Try newer version:http://bugs.php.net/fix.php?id=38963r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38963r=support Expected behavior:http://bugs.php.net/fix.php?id=38963r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38963r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38963r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38963r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38963r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38963r=dst IIS Stability:http://bugs.php.net/fix.php?id=38963r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38963r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38963r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38963r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38963r=mysqlcfg
#38960 [Fbk-Opn]: OCI8 failure...
ID: 38960 User updated by: sn4265 at att dot com Reported By: sn4265 at att dot com -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: HPUX 11.11 PHP Version: 5.1.6 New Comment: No clue. I have never used that before. This system has had Oracle 8.0.6.3 on it for years, and has always been what we have built against in the past without any problems. Is this a major change to PHP5? Does it now only work with a more limited set of Oracle clients? Previous Comments: [2006-09-26 12:28:49] [EMAIL PROTECTED] Does it work for you with Oracle Instant Client - http://www.oracle.com/technology/tech/oci/instantclient/index.html ? [2006-09-26 12:18:09] sn4265 at att dot com Description: I am attempting to build a working version of Apache 2.0.59 with PHP 5.1.6. I am doing this under HPUX 11.11, and have sucessfully built Apache, and PHP without OCI8 support. The problem is when I attempt to include OCI8 support either in the PHP build directly or by attempting to build the oci8-1.2.2 package after the fact. Here is the attempt buildint OCI8 after the fact. The error is identical when attempting to build PHP with OCI8 support too. Reproduce code: --- [EMAIL PROTECTED]:/www/tmp/oci8-1.2.2 phpize Configuring for: PHP Api Version: 20041225 Zend Module Api No: 20050922 Zend Extension Api No: 220051025 [EMAIL PROTECTED]:/www/tmp/oci8-1.2.2 ./configure checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for a sed that does not truncate output... /usr/bin/sed checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes [EMAIL PROTECTED]:/www/tmp/oci8-1.2.2 make /usr/bin/posix/sh /www/tmp/oci8-1.2.2/libtool --mode=compile gcc -I. -I/www/tmp/oci8-1.2.2 -DPHP_ATOM_INC -I/www/tmp/oci8-1.2.2/include -I/www/tmp/oci8-1.2.2/main -I/www/tmp/oci8-1.2.2 -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -I/usr/local/include/php/ext -I/usr/local/oracle/8.0.6.3/rdbms/demo -I/usr/local/oracle/8.0.6.3/network/public -DHAVE_CONFIG_H -g -O2 -c /www/tmp/oci8-1.2.2/oci8.c -o oci8.lo mkdir .libs gcc -I. -I/www/tmp/oci8-1.2.2 -DPHP_ATOM_INC -I/www/tmp/oci8-1.2.2/include -I/www/tmp/oci8-1.2.2/main -I/www/tmp/oci8-1.2.2 -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -I/usr/local/include/php/ext -I/usr/local/oracle/8.0.6.3/rdbms/demo -I/usr/local/oracle/8.0.6.3/network/public -DHAVE_CONFIG_H -g -O2 -c /www/tmp/oci8-1.2.2/oci8.c -fPIC -DPIC -o .libs/oci8.o /www/tmp/oci8-1.2.2/oci8.c: In function `php_oci_connection_status': /www/tmp/oci8-1.2.2/oci8.c:1429: error: `OCI_ATTR_SERVER_STATUS' undeclared (first use in this function) /www/tmp/oci8-1.2.2/oci8.c:1429: error: (Each undeclared identifier is reported only once /www/tmp/oci8-1.2.2/oci8.c:1429: error: for each function it appears in.) /www/tmp/oci8-1.2.2/oci8.c:1431: error: `OCI_SERVER_NORMAL' undeclared (first use in this function) *** Error exit code 1 Stop. Expected result: Return a sucessful build. Actual result: -- /www/tmp/oci8-1.2.2/oci8.c: In function `php_oci_connection_status': /www/tmp/oci8-1.2.2/oci8.c:1429: error: `OCI_ATTR_SERVER_STATUS' undeclared (first use in this function) /www/tmp/oci8-1.2.2/oci8.c:1429: error: (Each undeclared identifier is reported only once /www/tmp/oci8-1.2.2/oci8.c:1429: error: for each function it appears in.) /www/tmp/oci8-1.2.2/oci8.c:1431: error: `OCI_SERVER_NORMAL' undeclared (first use in this function) *** Error exit code 1 Stop. -- Edit this bug report at http://bugs.php.net/?id=38960edit=1
#38963 [Opn-Fbk]: tempnam bypasses open_basedir
ID: 38963 Updated by: [EMAIL PROTECTED] Reported By: manuel at mausz dot at -Status: Open +Status: Feedback Bug Type: Filesystem function related Operating System: Linux/Gentoo PHP Version: 4.4.4 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Cannot reproduce: # ./sapi/cli/php -r 'var_dump(tempnam(false, temp));' Warning: tempnam(): open_basedir restriction in effect. File() is not within the allowed path(s): (/www) in Command line code on line 1 bool(false) Previous Comments: [2006-09-26 15:19:47] manuel at mausz dot at Description: tempnam bypasses open_basedir if dir = false Reproduce code: --- ?php $tempfile = tempnam(false, phptest); ? Expected result: Warning: tempnam() [function.tempnam]: open_basedir restriction in effect. File(/tmp) is not within the allowed path(s): (...) in Actual result: -- # ls /tmp/phptest* /tmp/phptestt4mIOa -- Edit this bug report at http://bugs.php.net/?id=38963edit=1
#38961 [Opn-Fbk]: Metaphone results in segmentation fault
ID: 38961
Updated by: [EMAIL PROTECTED]
Reported By: nikolas dot hagelstein at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Netbsd 3.0.1 AMD64
PHP Version: 5.1.6
New Comment:
Works perfectly fine: string(0)
Previous Comments:
[2006-09-26 15:16:57] nikolas dot hagelstein at gmail dot com
I can not try that since i am not able to submit real utf8 chars
through my shell.
test.php
?php
echo crash:.metaphone('ö');
?
php test.php
results in a segmentation fault test.php needs to be an UTF8 file.
file -i test.php
test.php: text/plain; charset=utf-8
[2006-09-26 15:09:28] [EMAIL PROTECTED]
./sapi/cli/php -r
'var_dump(metaphone(#1088;#1091;#1089;#1089;#1082;#1080;#1081;
#1103;#1079;#1099;#1082; UTF8));'
string(3) UTF
[2006-09-26 15:06:14] nikolas dot hagelstein at gmail dot com
Starting program: /usr/pkg/bin/php test.php
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x0050c86b in zif_metaphone ()
(gdb) bt
#0 0x0050c86b in zif_metaphone ()
#1 0x0050c761 in zif_metaphone ()
#2 0x0059f489 in execute ()
#3 0x0059ed20 in execute ()
#4 0x00585a06 in zend_execute_scripts ()
#5 0x0054c169 in php_execute_script ()
#6 0x005eac84 in main ()
#7 0x004407a8 in ___start ()
(gdb)
[2006-09-26 14:09:57] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2006-09-26 14:01:12] nikolas dot hagelstein at gmail dot com
Description:
Passing utf8 data to metaphone results in a segmentation fault.
Reproduce code:
---
?PHP
//replace xxx with native utf8 chars e.g. copy and paste from
a russian website. The document itself needs to be of ut8 too
echo crash:.metaphone('xxx');
?
--
Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38950 [Fbk-Opn]: script times out long befor reaching max. execution time
ID: 38950
User updated by: pavel dot stratil-jun at fenix dot cz
Reported By: pavel dot stratil-jun at fenix dot cz
-Status: Feedback
+Status: Open
Bug Type: *Encryption and hash functions
Operating System: gentoo (amd64smp)
PHP Version: 5.1.6
New Comment:
I cant find the rule in the problem. I was able to reproduce it always
on files 1.2GB. I could reproduce it sometimes on files ranging from
70MB to 1.2GB and I havent been able to reproduce on files 70MB.
Previous Comments:
[2006-09-26 12:59:18] [EMAIL PROTECTED]
but streaming hashing still fails on large files (the
script timeouts for real after max_execution_time even on
relatively small files, compared to the first tests - i.e.
200MB)
Please elaborate.
many compile failures when trying to build with some
common extensions such as imap (against imap2006) or
mysqli (5.1.11).
Please report them as separate issues.
[2006-09-26 12:45:31] pavel dot stratil-jun at fenix dot cz
seems that the problem is in
$fp = fopen('test', r);
$ctx = hash_init('sha512');
while (!feof($fp)) {
hash_update($ctx, fgets($fp, 4096));
}
$uplo_mhash = hash_final($ctx);
fclose($fp);
when calling the script from apache. When running from shell the
problem disappears completely. In apache the premature timeout problem
disappeared in the snapshot version, but streaming hashing still fails
on large files (the script timeouts for real after max_execution_time
even on relatively small files, compared to the first tests - i.e.
200MB). Hash_file() seems to work flawlesly. When going towards smaller
files, streaming hashing catches on and is about 60% the speed of
hash_file.
Tried this with apache 2.2.2 and 2.2.3 with modified as well as
distribution configurations with the same result.
tested on
php5.2-200609261030
./configure --prefix=${PHP_PATH} --with-apxs2=${APACHE_PATH}/bin/apxs
gmake # ok
gmake test # failed in 4 tests
# Test for buffering in core functions with implicit flush off
[tests/func/008.phpt]
# Bug #16069 [ext/iconv/tests/bug16069.phpt]
#iconv stream filter [ext/iconv/tests/iconv_stream_filter.phpt]
# Math constants [ext/standard/tests/math/constants.phpt]
ps: dont know how far the development of php 5.2 is but i was getting
many compile failures when trying to build with some common extensions
such as imap (against imap2006) or mysqli (5.1.11).
[2006-09-26 09:13:41] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-09-25 15:01:51] pavel dot stratil-jun at fenix dot cz
Description:
when trying to hash large files (cant say yet how large, but a 800MB
file was hashed without problems but a 1300MB file not), the script
times out after about 1 minute even if max. execution time is set to
half an hour. smaller files, such as the 800MB file were successfully
hashed a few times using different hashing methods (in total the script
took about 4 minutes to run).
Reproduce code:
---
// tried both:
$fp = fopen('file.ext', r);
$ctx = hash_init('sha512');
while (!feof($fp)) {
hash_update($ctx, fgets($fp,$bytes));
}
$res_hash = hash_final($ctx); // this would be line 58
fclose($fp);
// and
hash_file('sha512', 'file.ext'); // this would be line 67
// $bytes were set to anywhere from 4kB to 32MB.. same result all the
time
Expected result:
obviously, a hash.
Actual result:
--
Fatal error: Maximum execution time of 1800 seconds exceeded in
/opt/apache/htdocs/hashtest.php on line 58.
or
Fatal error: Maximum execution time of 1800 seconds exceeded in
/opt/apache/htdocs/hashtest.php on line 67.
depending what piece of code was commented.
--
Edit this bug report at http://bugs.php.net/?id=38950edit=1
#38961 [Opn-Fbk]: Metaphone results in segmentation fault
ID: 38961
Updated by: [EMAIL PROTECTED]
Reported By: nikolas dot hagelstein at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Netbsd 3.0.1 AMD64
PHP Version: 5.1.6
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Previous Comments:
[2006-09-26 14:01:12] nikolas dot hagelstein at gmail dot com
Description:
Passing utf8 data to metaphone results in a segmentation fault.
Reproduce code:
---
?PHP
//replace xxx with native utf8 chars e.g. copy and paste from
a russian website. The document itself needs to be of ut8 too
echo crash:.metaphone('xxx');
?
--
Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38961 [NEW]: Metaphone results in segmentation fault
From: nikolas dot hagelstein at gmail dot com
Operating system: Netbsd 3.0.1 AMD64
PHP version: 5.1.6
PHP Bug Type: Reproducible crash
Bug description: Metaphone results in segmentation fault
Description:
Passing utf8 data to metaphone results in a segmentation fault.
Reproduce code:
---
?PHP
//replace xxx with native utf8 chars e.g. copy and paste from
a russian website. The document itself needs to be of ut8 too
echo crash:.metaphone('xxx');
?
--
Edit bug report at http://bugs.php.net/?id=38961edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38961r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38961r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38961r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38961r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38961r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38961r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38961r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38961r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38961r=support
Expected behavior:http://bugs.php.net/fix.php?id=38961r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38961r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38961r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38961r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38961r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38961r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38961r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38961r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38961r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38961r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38961r=mysqlcfg
#38952 [Fbk-Opn]: php cli built, libphp5.so not built
ID: 38952
User updated by: stevep at sga dot org
Reported By: stevep at sga dot org
-Status: Feedback
+Status: Open
Bug Type: Compile Failure
Operating System: Unixware 7.1.0
PHP Version: 5CVS-2006-09-25 (snap)
New Comment:
I assume the toolchain to be front to back, I guess we
have differing semantics.
At any rate, the GNU linker does not produce proper
shared libraries either, only libphp5.a, I installed
gnumake, libtools-1.5.22 and binutils-2.17 and still it
will not build properly, still getting the same error
about not being able to satisfy inter-library
dependencies as posted before, even with the minimum
config.
Is there a way by digging through config.log/etc to find
out why it thinks it can not resolve dependencies, or to
see what they are?
Previous Comments:
[2006-09-25 21:13:26] [EMAIL PROTECTED]
Did you see where I mentioned that I *DID* use the GNU
toolchain as well?
No, you said only I tried building gcc-3.4.6, which is clearly NOT
the same as GNU toolchain.
I intentionally emphasized the GNU linker, which is required.
[2006-09-25 21:05:58] stevep at sga dot org
This is not a bogus ticket, at least not for the reason
you flagged it as such.
Did you see where I mentioned that I *DID* use the GNU
toolchain as well? I have the same exact issue.
[2006-09-25 20:56:19] [EMAIL PROTECTED]
Please use GNU linker and GNU build tools, others are not supported.
[2006-09-25 16:49:01] stevep at sga dot org
Description:
I have run into this problem on PHP5.1.6 and when trying
the latest PHP5 snapshot on a Unixware 7.1.0 host.
*** Warning: libtool could not satisfy all declared
inter-library
*** dependencies of module libphp5. Therefore, libtool
will create
*** a static module, that should work as long as the
dlopening
*** application is linked with the -dlopen flag.
copying selected object files to avoid basename
conflicts...
using piecewise archive linking...
Reproduce code:
---
CC=cc LD=/usr/ccs/bin/ld LDFLAGS=-L/usr/ccs/lib ./
configure \
--disable-rpath \
--with-apxs=/www/bin/apxs \
--with-openssl=/usr/local/ssl \
--disable-debug \
--enable-magic-quotes \
--enable-mm=shared \
--enable-track-vars \
--enable-trans-sid \
--enable-wddx=shared \
--enable-xml \
--enable-mhash \
--enable-mcrypt \
--with-mhash=/usr/local/lib \
--with-mcrypt=/usr/local/lib \
--with-dom \
--with-gd \
--with-gettext \
--with-mysql=/usr/local/mysql \
--with-regex=system \
--with-xml \
--with-zlib-dir=/usr/lib \
--prefix=/usr/local
make
Expected result:
libphp5.so built
Actual result:
--
libphp5.so not built, only libphp5.a
The same configuration did work when I last installed
PHP-4.3.9 on this machine.
I am using the SCO bundled toolchain to build this. I
tried building gcc-3.4.6 and using that, but have the
same problems.
I also tried just to configure as:
CC=cc LD=/usr/ccs/bin/ld LDFLAGS=-L/usr/ccs/lib ./
configure \
--with-apxs=/www/bin/apxs \
--prefix=/usr/local
Same problem.
More details available upon request, I'm not sure what
all to include.
As a side note, I had to make a few quick changes to get
it to compile on Unixware 7.1.0:
ext/hash/hash_ripemd.c:
Unixware 7.1.0 did not like the static unsigned char
SS[80] assignment, I changed the name of SS to something
else, and in the following macro definitions, and all
was fine.
ext/sqlite/sqlite.c
Did not like enum callback_prep_t { DO_REG, SKIP_REG,
ERR }; I had to change ERR to something else and also
changing references in the rest of the code.
--
Edit this bug report at http://bugs.php.net/?id=38952edit=1
#38950 [Opn-Fbk]: script times out long befor reaching max. execution time
ID: 38950
Updated by: [EMAIL PROTECTED]
Reported By: pavel dot stratil-jun at fenix dot cz
-Status: Open
+Status: Feedback
Bug Type: *Encryption and hash functions
Operating System: gentoo (amd64smp)
PHP Version: 5.1.6
New Comment:
Reproduce what? What is the value of max_execution_time? What is the
error message? What is the real amount of time spent and how did you
measure it?
Previous Comments:
[2006-09-26 14:19:35] pavel dot stratil-jun at fenix dot cz
I cant find the rule in the problem. I was able to reproduce it always
on files 1.2GB. I could reproduce it sometimes on files ranging from
70MB to 1.2GB and I havent been able to reproduce on files 70MB.
[2006-09-26 12:59:18] [EMAIL PROTECTED]
but streaming hashing still fails on large files (the
script timeouts for real after max_execution_time even on
relatively small files, compared to the first tests - i.e.
200MB)
Please elaborate.
many compile failures when trying to build with some
common extensions such as imap (against imap2006) or
mysqli (5.1.11).
Please report them as separate issues.
[2006-09-26 12:45:31] pavel dot stratil-jun at fenix dot cz
seems that the problem is in
$fp = fopen('test', r);
$ctx = hash_init('sha512');
while (!feof($fp)) {
hash_update($ctx, fgets($fp, 4096));
}
$uplo_mhash = hash_final($ctx);
fclose($fp);
when calling the script from apache. When running from shell the
problem disappears completely. In apache the premature timeout problem
disappeared in the snapshot version, but streaming hashing still fails
on large files (the script timeouts for real after max_execution_time
even on relatively small files, compared to the first tests - i.e.
200MB). Hash_file() seems to work flawlesly. When going towards smaller
files, streaming hashing catches on and is about 60% the speed of
hash_file.
Tried this with apache 2.2.2 and 2.2.3 with modified as well as
distribution configurations with the same result.
tested on
php5.2-200609261030
./configure --prefix=${PHP_PATH} --with-apxs2=${APACHE_PATH}/bin/apxs
gmake # ok
gmake test # failed in 4 tests
# Test for buffering in core functions with implicit flush off
[tests/func/008.phpt]
# Bug #16069 [ext/iconv/tests/bug16069.phpt]
#iconv stream filter [ext/iconv/tests/iconv_stream_filter.phpt]
# Math constants [ext/standard/tests/math/constants.phpt]
ps: dont know how far the development of php 5.2 is but i was getting
many compile failures when trying to build with some common extensions
such as imap (against imap2006) or mysqli (5.1.11).
[2006-09-26 09:13:41] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-09-25 15:01:51] pavel dot stratil-jun at fenix dot cz
Description:
when trying to hash large files (cant say yet how large, but a 800MB
file was hashed without problems but a 1300MB file not), the script
times out after about 1 minute even if max. execution time is set to
half an hour. smaller files, such as the 800MB file were successfully
hashed a few times using different hashing methods (in total the script
took about 4 minutes to run).
Reproduce code:
---
// tried both:
$fp = fopen('file.ext', r);
$ctx = hash_init('sha512');
while (!feof($fp)) {
hash_update($ctx, fgets($fp,$bytes));
}
$res_hash = hash_final($ctx); // this would be line 58
fclose($fp);
// and
hash_file('sha512', 'file.ext'); // this would be line 67
// $bytes were set to anywhere from 4kB to 32MB.. same result all the
time
Expected result:
obviously, a hash.
Actual result:
--
Fatal error: Maximum execution time of 1800 seconds exceeded in
/opt/apache/htdocs/hashtest.php on line 58.
or
Fatal error: Maximum execution time of 1800 seconds exceeded in
/opt/apache/htdocs/hashtest.php on line 67.
depending what piece of code was commented.
--
Edit this bug report at http://bugs.php.net/?id=38950edit=1
#38962 [NEW]: memory leak in fgets when using cli
From: jim-bo at hotpop dot com
Operating system: Linux Debian Etch
PHP version: 5.1.6
PHP Bug Type: CGI related
Bug description: memory leak in fgets when using cli
Description:
Using cli on debian etch it seems that fgets leaks memory.
I have replaced fgets with stream_get_line and it seems to not leak.
Please forgive me if this is a programming error on my behalf...but i
can't see it.
PHP 5.1.6-1 (cli) (built: Sep 1 2006 13:52:26)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
Reproduce code:
---
?
$descriptorSpec = array(
0 = array(pipe, r), // stdin is a pipe that
the child process will read from
1 = array(pipe, w), // stdout is a pipe that
the child process will write to
2 = array(pipe, w) // stderr is a pipe that
the child process will write to
);
for ($i=0;$i20;++$i)
{
$process = proc_open('/usr/bin/uptime', $descriptorSpec, $pipes);
if (is_resource($process))
{
fclose($pipes[0]);
while(!feof($pipes[1]))
$stdout .= fgets($pipes[1], 1024);
fclose($pipes[1]);
fclose($pipes[2]);
}
$returnValue = proc_close($process);
unset($returnValue, $stdout, $stderr, $process, $pipes[0],
$pipes[1], $pipes[2]);
print $i . ' == ' . memory_get_usage() . \r\n;
}
?
Expected result:
0 == 41344
1 == 41408
2 == 41408
3 == 41408
4 == 41408
5 == 41408
6 == 41408
7 == 41408
8 == 41408
9 == 41408
10 == 41408
11 == 41408
12 == 41408
13 == 41408
14 == 41408
15 == 41408
16 == 41408
17 == 41408
18 == 41408
19 == 41408
(this is the actual result when replacing fgets with stream_get_line)
Actual result:
--
0 == 41240
1 == 41368
2 == 41432
3 == 41496
4 == 41560
5 == 41624
6 == 41688
7 == 41752
8 == 41816
9 == 41880
10 == 41944
11 == 42008
12 == 42072
13 == 42136
14 == 42200
15 == 42264
16 == 42328
17 == 42392
18 == 42456
19 == 42520
--
Edit bug report at http://bugs.php.net/?id=38962edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38962r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38962r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38962r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38962r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38962r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38962r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38962r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38962r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38962r=support
Expected behavior:http://bugs.php.net/fix.php?id=38962r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38962r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38962r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38962r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38962r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38962r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38962r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38962r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38962r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38962r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38962r=mysqlcfg
#38964 [Opn-Bgs]: Duality in treating variables.
ID: 38964 Updated by: [EMAIL PROTECTED] Reported By: faust04 at o2 dot pl -Status: Open +Status: Bogus Bug Type: Variables related Operating System: OpenSuSE10.1 PHP Version: 5.1.6 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Inside a string it acts as concatenation. Previous Comments: [2006-09-26 15:20:10] faust04 at o2 dot pl Description: Duality in treating variables. Reproduce code: --- $o_$o = 10; // generates an error - that's ok echo My variable value: $o_$o; // treat's $o_$o as a right declared variable (sic!). It looks like 2 different variable definitions and that's the mistake Expected result: Error 2 times Actual result: -- Error My variable value: -- Edit this bug report at http://bugs.php.net/?id=38964edit=1
#38952 [Opn-Fbk]: php cli built, libphp5.so not built
ID: 38952
Updated by: [EMAIL PROTECTED]
Reported By: stevep at sga dot org
-Status: Open
+Status: Feedback
Bug Type: Compile Failure
Operating System: Unixware 7.1.0
PHP Version: 5CVS-2006-09-25 (snap)
New Comment:
Please provide an account on a Unixware machine, as we don't have one
for tests.
Previous Comments:
[2006-09-26 14:47:19] stevep at sga dot org
I assume the toolchain to be front to back, I guess we
have differing semantics.
At any rate, the GNU linker does not produce proper
shared libraries either, only libphp5.a, I installed
gnumake, libtools-1.5.22 and binutils-2.17 and still it
will not build properly, still getting the same error
about not being able to satisfy inter-library
dependencies as posted before, even with the minimum
config.
Is there a way by digging through config.log/etc to find
out why it thinks it can not resolve dependencies, or to
see what they are?
[2006-09-25 21:13:26] [EMAIL PROTECTED]
Did you see where I mentioned that I *DID* use the GNU
toolchain as well?
No, you said only I tried building gcc-3.4.6, which is clearly NOT
the same as GNU toolchain.
I intentionally emphasized the GNU linker, which is required.
[2006-09-25 21:05:58] stevep at sga dot org
This is not a bogus ticket, at least not for the reason
you flagged it as such.
Did you see where I mentioned that I *DID* use the GNU
toolchain as well? I have the same exact issue.
[2006-09-25 20:56:19] [EMAIL PROTECTED]
Please use GNU linker and GNU build tools, others are not supported.
[2006-09-25 16:49:01] stevep at sga dot org
Description:
I have run into this problem on PHP5.1.6 and when trying
the latest PHP5 snapshot on a Unixware 7.1.0 host.
*** Warning: libtool could not satisfy all declared
inter-library
*** dependencies of module libphp5. Therefore, libtool
will create
*** a static module, that should work as long as the
dlopening
*** application is linked with the -dlopen flag.
copying selected object files to avoid basename
conflicts...
using piecewise archive linking...
Reproduce code:
---
CC=cc LD=/usr/ccs/bin/ld LDFLAGS=-L/usr/ccs/lib ./
configure \
--disable-rpath \
--with-apxs=/www/bin/apxs \
--with-openssl=/usr/local/ssl \
--disable-debug \
--enable-magic-quotes \
--enable-mm=shared \
--enable-track-vars \
--enable-trans-sid \
--enable-wddx=shared \
--enable-xml \
--enable-mhash \
--enable-mcrypt \
--with-mhash=/usr/local/lib \
--with-mcrypt=/usr/local/lib \
--with-dom \
--with-gd \
--with-gettext \
--with-mysql=/usr/local/mysql \
--with-regex=system \
--with-xml \
--with-zlib-dir=/usr/lib \
--prefix=/usr/local
make
Expected result:
libphp5.so built
Actual result:
--
libphp5.so not built, only libphp5.a
The same configuration did work when I last installed
PHP-4.3.9 on this machine.
I am using the SCO bundled toolchain to build this. I
tried building gcc-3.4.6 and using that, but have the
same problems.
I also tried just to configure as:
CC=cc LD=/usr/ccs/bin/ld LDFLAGS=-L/usr/ccs/lib ./
configure \
--with-apxs=/www/bin/apxs \
--prefix=/usr/local
Same problem.
More details available upon request, I'm not sure what
all to include.
As a side note, I had to make a few quick changes to get
it to compile on Unixware 7.1.0:
ext/hash/hash_ripemd.c:
Unixware 7.1.0 did not like the static unsigned char
SS[80] assignment, I changed the name of SS to something
else, and in the following macro definitions, and all
was fine.
ext/sqlite/sqlite.c
Did not like enum callback_prep_t { DO_REG, SKIP_REG,
ERR }; I had to change ERR to something else and also
changing references in the rest of the code.
--
Edit this bug report at http://bugs.php.net/?id=38952edit=1
#38964 [NEW]: Duality in treating variables.
From: faust04 at o2 dot pl Operating system: OpenSuSE10.1 PHP version: 5.1.6 PHP Bug Type: Variables related Bug description: Duality in treating variables. Description: Duality in treating variables. Reproduce code: --- $o_$o = 10; // generates an error - that's ok echo My variable value: $o_$o; // treat's $o_$o as a right declared variable (sic!). It looks like 2 different variable definitions and that's the mistake Expected result: Error 2 times Actual result: -- Error My variable value: -- Edit bug report at http://bugs.php.net/?id=38964edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38964r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38964r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38964r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38964r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38964r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38964r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38964r=needscript Try newer version:http://bugs.php.net/fix.php?id=38964r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38964r=support Expected behavior:http://bugs.php.net/fix.php?id=38964r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38964r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38964r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38964r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38964r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38964r=dst IIS Stability:http://bugs.php.net/fix.php?id=38964r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38964r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38964r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38964r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38964r=mysqlcfg
#38950 [Fbk-Opn]: script times out long befor reaching max. execution time
ID: 38950
User updated by: pavel dot stratil-jun at fenix dot cz
Reported By: pavel dot stratil-jun at fenix dot cz
-Status: Feedback
+Status: Open
Bug Type: *Encryption and hash functions
Operating System: gentoo (amd64smp)
PHP Version: 5.1.6
New Comment:
* Reproduce what?
reproduce the timeout error when trying streaming hashing.
* What is the value of max_execution_time?
1800 seconds
* What is the error message?
on php 5.1.6 after running for about a minute (checked with a
stopwatch): Fatal error: Maximum execution time of 1800 seconds
exceeded in
/opt/apache/htdocs/hashtest.php on line 58.
on php 5.2 after running for 1800 seconds (checked with a stopwatch):
Fatal error: Maximum execution time of 1800 seconds exceeded in
/opt/apache/htdocs/hashtest.php on line 58.
My totally naive guess is that during the while loop the eof might not
be properly recognised (on both versions) or that the loop itself has
some counter which for some reason signals to php that the script timed
out even if it didnt.
Previous Comments:
[2006-09-26 14:24:44] [EMAIL PROTECTED]
Reproduce what? What is the value of max_execution_time? What is the
error message? What is the real amount of time spent and how did you
measure it?
[2006-09-26 14:19:35] pavel dot stratil-jun at fenix dot cz
I cant find the rule in the problem. I was able to reproduce it always
on files 1.2GB. I could reproduce it sometimes on files ranging from
70MB to 1.2GB and I havent been able to reproduce on files 70MB.
[2006-09-26 12:59:18] [EMAIL PROTECTED]
but streaming hashing still fails on large files (the
script timeouts for real after max_execution_time even on
relatively small files, compared to the first tests - i.e.
200MB)
Please elaborate.
many compile failures when trying to build with some
common extensions such as imap (against imap2006) or
mysqli (5.1.11).
Please report them as separate issues.
[2006-09-26 12:45:31] pavel dot stratil-jun at fenix dot cz
seems that the problem is in
$fp = fopen('test', r);
$ctx = hash_init('sha512');
while (!feof($fp)) {
hash_update($ctx, fgets($fp, 4096));
}
$uplo_mhash = hash_final($ctx);
fclose($fp);
when calling the script from apache. When running from shell the
problem disappears completely. In apache the premature timeout problem
disappeared in the snapshot version, but streaming hashing still fails
on large files (the script timeouts for real after max_execution_time
even on relatively small files, compared to the first tests - i.e.
200MB). Hash_file() seems to work flawlesly. When going towards smaller
files, streaming hashing catches on and is about 60% the speed of
hash_file.
Tried this with apache 2.2.2 and 2.2.3 with modified as well as
distribution configurations with the same result.
tested on
php5.2-200609261030
./configure --prefix=${PHP_PATH} --with-apxs2=${APACHE_PATH}/bin/apxs
gmake # ok
gmake test # failed in 4 tests
# Test for buffering in core functions with implicit flush off
[tests/func/008.phpt]
# Bug #16069 [ext/iconv/tests/bug16069.phpt]
#iconv stream filter [ext/iconv/tests/iconv_stream_filter.phpt]
# Math constants [ext/standard/tests/math/constants.phpt]
ps: dont know how far the development of php 5.2 is but i was getting
many compile failures when trying to build with some common extensions
such as imap (against imap2006) or mysqli (5.1.11).
[2006-09-26 09:13:41] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/38950
--
Edit this bug report at http://bugs.php.net/?id=38950edit=1
#35691 [Com]: Can't change to another drive letter using chdir()
ID: 35691
Comment by: thiagomp at gmail dot com
Reported By: ejwaibel at gmail dot com
Status: Assigned
Bug Type: Directory function related
Operating System: Windows 2003
PHP Version: 5CVS-2005-12-19 (snap)
Assigned To: nlopess
New Comment:
The problem appeared here with the following configuration:
Windows XP SP2
PHP 5.0.5 (with Apache 1.3.33) and 5.1.6 (with Apache 2.0.59)
Previous Comments:
[2006-01-20 10:18:32] jarek at katnik dot pl
It happpens also with Apache 1.3.31.
[2006-01-19 17:00:11] [EMAIL PROTECTED]
OK, so here I go again. bug #36088 states this only happens with Apache
(2.0.x) and works in CLI. Previously I had only tested in CLI, so back
to testing.
[2006-01-19 08:56:15] jarek at katnik dot pl
I'm using PHP Version 5.1.2 on MS Windows XP Pro SP2.
Drive 'R:' is mounted by ClearCase.
When I run script listed bellow I get warrning:
Warning: chdir() [function.chdir]: No such file or directory (errno 2)
in {scriptName} on line {lineNumber}
?php
chdir('R:');
?
[2005-12-20 19:43:20] [EMAIL PROTECTED]
I've installed win 2003 and I can't reproduce the problem.
Please double check your 'subst' command (by entering in my computer
and see if the drive is listed there, etc..)
[2005-12-19 17:41:10] [EMAIL PROTECTED]
So, this is only happening with attached drive on Windows 2003. I can
only think of a bug in GetLongPathName().
I'll install windows 2003 server somewhere to test.
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/35691
--
Edit this bug report at http://bugs.php.net/?id=35691edit=1
#38950 [Fbk-Opn]: script times out long befor reaching max. execution time
ID: 38950 User updated by: pavel dot stratil-jun at fenix dot cz Reported By: pavel dot stratil-jun at fenix dot cz -Status: Feedback +Status: Open Bug Type: *Encryption and hash functions Operating System: gentoo (amd64smp) PHP Version: 5.1.6 New Comment: on 5.2? well yes and no. the timeout problem disappeared, but the timeout itself is still there. file_hash() does a 200MB file on my machine in about 4 seconds the checksum stream hashing times out after half an hour! and i am not sure if its a performance issue because on smaller files (anything from bytes to tens of MB) the stream hashing has 60% the speed of file_hash(), so extrapolating this i would expect a 200MB file to be hashed in say max 10 seconds, a timeout after 30 minutes is not ok Previous Comments: [2006-09-26 15:17:42] [EMAIL PROTECTED] on php 5.2 after running for 1800 seconds (checked with a stopwatch): Fatal error: Maximum execution time of 1800 seconds exceeded So it does work fine, right? [2006-09-26 15:14:54] pavel dot stratil-jun at fenix dot cz * Reproduce what? reproduce the timeout error when trying streaming hashing. * What is the value of max_execution_time? 1800 seconds * What is the error message? on php 5.1.6 after running for about a minute (checked with a stopwatch): Fatal error: Maximum execution time of 1800 seconds exceeded in /opt/apache/htdocs/hashtest.php on line 58. on php 5.2 after running for 1800 seconds (checked with a stopwatch): Fatal error: Maximum execution time of 1800 seconds exceeded in /opt/apache/htdocs/hashtest.php on line 58. My totally naive guess is that during the while loop the eof might not be properly recognised (on both versions) or that the loop itself has some counter which for some reason signals to php that the script timed out even if it didnt. [2006-09-26 14:24:44] [EMAIL PROTECTED] Reproduce what? What is the value of max_execution_time? What is the error message? What is the real amount of time spent and how did you measure it? [2006-09-26 14:19:35] pavel dot stratil-jun at fenix dot cz I cant find the rule in the problem. I was able to reproduce it always on files 1.2GB. I could reproduce it sometimes on files ranging from 70MB to 1.2GB and I havent been able to reproduce on files 70MB. [2006-09-26 12:59:18] [EMAIL PROTECTED] but streaming hashing still fails on large files (the script timeouts for real after max_execution_time even on relatively small files, compared to the first tests - i.e. 200MB) Please elaborate. many compile failures when trying to build with some common extensions such as imap (against imap2006) or mysqli (5.1.11). Please report them as separate issues. 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/38950 -- Edit this bug report at http://bugs.php.net/?id=38950edit=1
#38961 [Fbk-Opn]: Metaphone results in segmentation fault
ID: 38961
User updated by: nikolas dot hagelstein at gmail dot com
Reported By: nikolas dot hagelstein at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Netbsd 3.0.1 AMD64
PHP Version: 5.1.6
New Comment:
Starting program: /usr/pkg/bin/php test.php
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x0050c86b in zif_metaphone ()
(gdb) bt
#0 0x0050c86b in zif_metaphone ()
#1 0x0050c761 in zif_metaphone ()
#2 0x0059f489 in execute ()
#3 0x0059ed20 in execute ()
#4 0x00585a06 in zend_execute_scripts ()
#5 0x0054c169 in php_execute_script ()
#6 0x005eac84 in main ()
#7 0x004407a8 in ___start ()
(gdb)
Previous Comments:
[2006-09-26 14:09:57] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2006-09-26 14:01:12] nikolas dot hagelstein at gmail dot com
Description:
Passing utf8 data to metaphone results in a segmentation fault.
Reproduce code:
---
?PHP
//replace xxx with native utf8 chars e.g. copy and paste from
a russian website. The document itself needs to be of ut8 too
echo crash:.metaphone('xxx');
?
--
Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38961 [Fbk-Opn]: Metaphone results in segmentation fault
ID: 38961
User updated by: nikolas dot hagelstein at gmail dot com
Reported By: nikolas dot hagelstein at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Netbsd 3.0.1 AMD64
PHP Version: 5.1.6
New Comment:
I can not try that since i am not able to submit real utf8 chars
through my shell.
test.php
?php
echo crash:.metaphone('ö');
?
php test.php
results in a segmentation fault test.php needs to be an UTF8 file.
file -i test.php
test.php: text/plain; charset=utf-8
Previous Comments:
[2006-09-26 15:09:28] [EMAIL PROTECTED]
./sapi/cli/php -r
'var_dump(metaphone(#1088;#1091;#1089;#1089;#1082;#1080;#1081;
#1103;#1079;#1099;#1082; UTF8));'
string(3) UTF
[2006-09-26 15:06:14] nikolas dot hagelstein at gmail dot com
Starting program: /usr/pkg/bin/php test.php
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x0050c86b in zif_metaphone ()
(gdb) bt
#0 0x0050c86b in zif_metaphone ()
#1 0x0050c761 in zif_metaphone ()
#2 0x0059f489 in execute ()
#3 0x0059ed20 in execute ()
#4 0x00585a06 in zend_execute_scripts ()
#5 0x0054c169 in php_execute_script ()
#6 0x005eac84 in main ()
#7 0x004407a8 in ___start ()
(gdb)
[2006-09-26 14:09:57] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2006-09-26 14:01:12] nikolas dot hagelstein at gmail dot com
Description:
Passing utf8 data to metaphone results in a segmentation fault.
Reproduce code:
---
?PHP
//replace xxx with native utf8 chars e.g. copy and paste from
a russian website. The document itself needs to be of ut8 too
echo crash:.metaphone('xxx');
?
--
Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38962 [Opn-Bgs]: memory leak in fgets when using cli
ID: 38962
Updated by: [EMAIL PROTECTED]
Reported By: jim-bo at hotpop dot com
-Status: Open
+Status: Bogus
Bug Type: CGI related
Operating System: Linux Debian Etch
PHP Version: 5.1.6
New Comment:
What you see is not a leak (a leak would be reported to you by the
memory manager), this how memory manager work.
No bug here.
Previous Comments:
[2006-09-26 14:57:45] jim-bo at hotpop dot com
Description:
Using cli on debian etch it seems that fgets leaks memory.
I have replaced fgets with stream_get_line and it seems to not leak.
Please forgive me if this is a programming error on my behalf...but i
can't see it.
PHP 5.1.6-1 (cli) (built: Sep 1 2006 13:52:26)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
Reproduce code:
---
?
$descriptorSpec = array(
0 = array(pipe, r), // stdin is a pipe
that the child process will read from
1 = array(pipe, w), // stdout is a pipe
that the child process will write to
2 = array(pipe, w) // stderr is a pipe
that the child process will write to
);
for ($i=0;$i20;++$i)
{
$process = proc_open('/usr/bin/uptime', $descriptorSpec,
$pipes);
if (is_resource($process))
{
fclose($pipes[0]);
while(!feof($pipes[1]))
$stdout .= fgets($pipes[1], 1024);
fclose($pipes[1]);
fclose($pipes[2]);
}
$returnValue = proc_close($process);
unset($returnValue, $stdout, $stderr, $process, $pipes[0],
$pipes[1], $pipes[2]);
print $i . ' == ' . memory_get_usage() . \r\n;
}
?
Expected result:
0 == 41344
1 == 41408
2 == 41408
3 == 41408
4 == 41408
5 == 41408
6 == 41408
7 == 41408
8 == 41408
9 == 41408
10 == 41408
11 == 41408
12 == 41408
13 == 41408
14 == 41408
15 == 41408
16 == 41408
17 == 41408
18 == 41408
19 == 41408
(this is the actual result when replacing fgets with stream_get_line)
Actual result:
--
0 == 41240
1 == 41368
2 == 41432
3 == 41496
4 == 41560
5 == 41624
6 == 41688
7 == 41752
8 == 41816
9 == 41880
10 == 41944
11 == 42008
12 == 42072
13 == 42136
14 == 42200
15 == 42264
16 == 42328
17 == 42392
18 == 42456
19 == 42520
--
Edit this bug report at http://bugs.php.net/?id=38962edit=1
#38961 [Fbk-Opn]: Metaphone results in segmentation fault
ID: 38961
User updated by: nikolas dot hagelstein at gmail dot com
Reported By: nikolas dot hagelstein at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Netbsd 3.0.1 AMD64
PHP Version: 5.1.6
New Comment:
I checked out 5.2 from cvs but i am not able to build it on my
maschine.
Syntax error: Unterminated quoted string
Any other way to check if the the 64bit fix works?
Previous Comments:
[2006-09-26 15:41:22] [EMAIL PROTECTED]
Can you please try the latest CVS, it has a 64bit fix that may
fix the crash you are experiencing.
[2006-09-26 15:35:34] nikolas dot hagelstein at gmail dot com
So it is eigther a system specific issue (i was able to reproduce it on
2 maschines) or you did not used an utf8 file ;)
[2006-09-26 15:32:42] [EMAIL PROTECTED]
Works perfectly fine: string(0)
[2006-09-26 15:16:57] nikolas dot hagelstein at gmail dot com
I can not try that since i am not able to submit real utf8 chars
through my shell.
test.php
?php
echo crash:.metaphone('ö');
?
php test.php
results in a segmentation fault test.php needs to be an UTF8 file.
file -i test.php
test.php: text/plain; charset=utf-8
[2006-09-26 15:09:28] [EMAIL PROTECTED]
./sapi/cli/php -r
'var_dump(metaphone(#1088;#1091;#1089;#1089;#1082;#1080;#1081;
#1103;#1079;#1099;#1082; UTF8));'
string(3) UTF
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/38961
--
Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38950 [Opn-Csd]: script times out long befor reaching max. execution time
ID: 38950 Updated by: [EMAIL PROTECTED] Reported By: pavel dot stratil-jun at fenix dot cz -Status: Open +Status: Closed Bug Type: *Encryption and hash functions Operating System: gentoo (amd64smp) PHP Version: 5.1.6 New Comment: 200MB file is hashed in 3 seconds using hash_file() and in 7 seconds using streams. The difference is expected because hash_file() uses static buffer, while hash_update()/fgets() use dynamic buffers. Previous Comments: [2006-09-26 15:28:00] pavel dot stratil-jun at fenix dot cz on 5.2? well yes and no. the timeout problem disappeared, but the timeout itself is still there. file_hash() does a 200MB file on my machine in about 4 seconds the checksum stream hashing times out after half an hour! and i am not sure if its a performance issue because on smaller files (anything from bytes to tens of MB) the stream hashing has 60% the speed of file_hash(), so extrapolating this i would expect a 200MB file to be hashed in say max 10 seconds, a timeout after 30 minutes is not ok [2006-09-26 15:17:42] [EMAIL PROTECTED] on php 5.2 after running for 1800 seconds (checked with a stopwatch): Fatal error: Maximum execution time of 1800 seconds exceeded So it does work fine, right? [2006-09-26 15:14:54] pavel dot stratil-jun at fenix dot cz * Reproduce what? reproduce the timeout error when trying streaming hashing. * What is the value of max_execution_time? 1800 seconds * What is the error message? on php 5.1.6 after running for about a minute (checked with a stopwatch): Fatal error: Maximum execution time of 1800 seconds exceeded in /opt/apache/htdocs/hashtest.php on line 58. on php 5.2 after running for 1800 seconds (checked with a stopwatch): Fatal error: Maximum execution time of 1800 seconds exceeded in /opt/apache/htdocs/hashtest.php on line 58. My totally naive guess is that during the while loop the eof might not be properly recognised (on both versions) or that the loop itself has some counter which for some reason signals to php that the script timed out even if it didnt. [2006-09-26 14:24:44] [EMAIL PROTECTED] Reproduce what? What is the value of max_execution_time? What is the error message? What is the real amount of time spent and how did you measure it? [2006-09-26 14:19:35] pavel dot stratil-jun at fenix dot cz I cant find the rule in the problem. I was able to reproduce it always on files 1.2GB. I could reproduce it sometimes on files ranging from 70MB to 1.2GB and I havent been able to reproduce on files 70MB. 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/38950 -- Edit this bug report at http://bugs.php.net/?id=38950edit=1
#38963 [Fbk-Opn]: tempnam bypasses open_basedir
ID: 38963 User updated by: manuel at mausz dot at Reported By: manuel at mausz dot at -Status: Feedback +Status: Open Bug Type: Filesystem function related Operating System: Linux/Gentoo PHP Version: 4.4.4 New Comment: Please try using mod_php. Using the client also don't work for me. Oh and just to be sure: - tried with safe_mode on + off - open_basedir does _not_ include /tmp ;) Previous Comments: [2006-09-26 15:30:39] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Cannot reproduce: # ./sapi/cli/php -r 'var_dump(tempnam(false, temp));' Warning: tempnam(): open_basedir restriction in effect. File() is not within the allowed path(s): (/www) in Command line code on line 1 bool(false) [2006-09-26 15:19:47] manuel at mausz dot at Description: tempnam bypasses open_basedir if dir = false Reproduce code: --- ?php $tempfile = tempnam(false, phptest); ? Expected result: Warning: tempnam() [function.tempnam]: open_basedir restriction in effect. File(/tmp) is not within the allowed path(s): (...) in Actual result: -- # ls /tmp/phptest* /tmp/phptestt4mIOa -- Edit this bug report at http://bugs.php.net/?id=38963edit=1
#38819 [Fbk-Opn]: segfault in ldap_get_entries()
ID: 38819
User updated by: madcoder at gmail dot com
Reported By: madcoder at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: LDAP related
Operating System: 2.6.15-gentoo linux amd64
PHP Version: 5.1.6
New Comment:
No, I'm sorry, it's on a private LAN. A VPN account would be required
to gain access to the LAN, and corporate policy won't allow me to grant
you that. If you would like to contact me off-bugzilla, I might be able
to arrange a different way of accessing the server.
Previous Comments:
[2006-09-26 09:38:39] [EMAIL PROTECTED]
Is it possible to get an account @ this server?
[2006-09-26 09:36:37] madcoder at gmail dot com
Sorry for the extra post... I just tested with different values in
ldap_connect. For all values of the hostname parameter that I tried,
any that were *NOT* prefixed with ldap://; caused a segmentation fault
at line 2:
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
The various values I tried, all of which resulted in a segfault, were:
hostname (xyzdc01 and xyzdc02)
IP (172.16.0.50 and 172.16.0.51)
FQHN (xyzdc01.xyz.acs-inc.com and xyzdc02.xyz.acs-inc.com)
All of the above, when prefixed with ldap://, resulted in the same
segfault described initially, at ldap_get_entries().
[2006-09-26 09:29:47] madcoder at gmail dot com
My apologies for misunderstanding...
To reproduce the problem on my system:
1) I connect to the ldap server, which happens to be a Microsoft Active
Directory domain controller, using:
$_SERVER['ldap'] = ldap_connect(ldap://xyzdc02.xyz.acs-inc.com;) or
die(ldap connect failed);
2) Set MSAD-required options:
ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($_SERVER['ldap'], LDAP_OPT_REFERRALS, 0);
3) Bind to the LDAP directory with a search user configured with read
access to the directory:
ldap_bind($_SERVER['ldap'], '[EMAIL PROTECTED]', 'some.Pass')
or die('ldap bind failed');
4) Perform a basic search, looking for my User object:
$result = ldap_search($_SERVER['ldap'], 'dc=xyz,dc=acs-inc,dc=com',
'(sAMAccountName=jhansche)',
array('samaccountname','telephonenumber'));
(print a couple of debug messages):
echo done searching\n;
echo Count: . ldap_count_entries($_SERVER['ldap'],$result) .
entries\n;
5) Attempt to fetch the results of the search above:
$info = ldap_get_entries($_SERVER['ldap'], $result);
*** This was the last line to execute before the segfault ***
(print more debugging messages):
echo Done fetching\n;
print_r($info);
==
I then test the script with this command line (ruling out apache as any
part of the problem), and receive these results to stdout/err:
# php -e test.php
done searching
Count: 1 entries
Segmentation fault
==
As a result of that process, running via gdb, I get the backtrace,
which I have posted previously.
==
Running via valgrind, filtering out the valgrind output, the script
*runs fine*, and produces the following output:
# valgrind php -e test.php 2/dev/null
done searching
Count: 1 entries
Done fetching
Array
(
[Full output of the array returned by ldap_get_entries() is
displayed here correctly, but snipped out for brevity's sake]
)
# (end of output)
==
The LDAP server is running Windows Server 2003 SP1. The segmentation
fault occurs when trying to connect to either of the two domain
controllers on the network. The segfault also occurs if I leave off
the LDAP_OPT_REFERRALS = 0 option, and perform a single-level search
directly on the Organizational Unit containing my user account.
==
/etc/openldap/ldap.conf:
BASEdc=xyz,dc=acs-inc,dc=com
URI ldap://xyz.acs-inc.com
TLS_REQCERT never
TLS_CACERT /etc/ssl/certs/xyzdc02.pem
TLS_CACERTDIR /etc/ssl/certs
(note that I am not calling ldap_start_tls() in this test, so the TLS_*
lines are not used)
==
Performing the same query via the command-line 'ldapsearch' utility
from OpenLDAP:
$ ldapsearch -H ldap://xyz.acs-inc.com -D [EMAIL PROTECTED] -w
some.Pass (samaccountname=jhansche) telephonenumber
# LDAPv3
# base with scope subtree
# filter: (samaccountname=jhansche)
# requesting: telephonenumber
# Joe Hansche, Administrators, elp.acs-inc.com
dn: CN=Joe Hansche,OU=Administrators,DC=xyz,DC=acs-inc,DC=com
telephoneNumber: 5492
==
Unfortunately, I don't have another non-MS ldap server to try. It
appears that the search is completed successfully, because the
ldap_count_entries() call returns 1, which is correct. It just
segfaults when trying to retrieve the actual entries with
ldap_get_entries(). I hope that is more informative. If not, please
let me know what additional
#38958 [Opn-Bgs]: bug
ID: 38958 Updated by: [EMAIL PROTECTED] Reported By: info at arininav dot ru -Status: Open +Status: Bogus Bug Type: Dynamic loading Operating System: win2003 server 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-26 08:43:27] info at arininav dot ru Description: Hi, Don't load php_oci8.dll from packages 5.1.4, 5, 6. Php_oci8.dll loading if takes it from 5.1.2 only or low. -- Edit this bug report at http://bugs.php.net/?id=38958edit=1
#38942 [Asn-Csd]: Double old-style-ctor inheritance
ID: 38942
Updated by: [EMAIL PROTECTED]
Reported By: hannes dot magnusson at gmail dot com
-Status: Assigned
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5CVS-2006-09-24 (CVS)
Assigned To: dmitry
New Comment:
Fixed in CVS HEAD and PHP_5_2.
Previous Comments:
[2006-09-24 18:16:44] [EMAIL PROTECTED]
Patch: http://php.is/bugs/38942/bug38942.patch.txt
[2006-09-24 18:14:33] hannes dot magnusson at gmail dot com
Description:
The engine seems to register old-style-ctors twice, once
during parent-ctor-inheriting and once during
normal-method-inheriting
Reproduce code:
---
?php
class foo {
public function foo() {}
}
class bar extends foo {
}
ReflectionClass::export(bar);
Expected result:
- Methods [1] {
Method [ user, inherits foo, ctor public method
foo ] {
@@ /usr/src/php/5.2/bug.php 3 - 3
}
Actual result:
--
- Methods [2] {
Method [ user, inherits foo, ctor public method
foo ] {
@@ /usr/src/php/5.2/bug.php 3 - 3
}
Method [ user, inherits foo, ctor public method
foo ] {
@@ /usr/src/php/5.2/bug.php 3 - 3
}
--
Edit this bug report at http://bugs.php.net/?id=38942edit=1
#38955 [Opn]: PDO DBLIB driver does not support transactions
ID: 38955
Updated by: [EMAIL PROTECTED]
Reported By: remery at seminolesheriff dot org
Status: Open
-Bug Type: PDO related
+Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 5.1.6
New Comment:
No bug here, reclassified as feature request.
Previous Comments:
[2006-09-25 18:43:10] remery at seminolesheriff dot org
Description:
I'm connecting from a Linux/Apache/PHP server to a Microsoft SQL Server
2000 database using PDO with the DBLIB driver. Attempting to use
transactions produces the exception 'This driver doesn't support
transactions'.
Reproduce code:
---
$dsn = 'dblib:host=' . $server . ';dbname=' . $dbName;
$user = 'tempUser';
$pwd = 'tmpPwd';
$table = 'sqlTable';
$column = 'colName';
$value = 'value';
$sql = 'Insert Into ' . $dbName;
$sql .= ' (' . $column . ')';
$sql .= ' Values ' . $value;
$conn = new PDO($dsn, $user, $pwd);
$conn-beginTransaction();
$conn-exec($sql);
$conn-commit();
Expected result:
The value should be inserted into the table.
Actual result:
--
Fatal error: Uncaught exception 'PDOException' with message 'This
driver doesn't support transactions' in
/var/www/html/business/entity.php:37 Stack trace: #0
/var/www/html/business/entity.php(37): PDO-beginTransaction() #1
{main} thrown in /var/www/html/business/entity.php on line 37
--
Edit this bug report at http://bugs.php.net/?id=38955edit=1
#38963 [Opn-Fbk]: tempnam bypasses open_basedir
ID: 38963 Updated by: [EMAIL PROTECTED] Reported By: manuel at mausz dot at -Status: Open +Status: Feedback Bug Type: Filesystem function related Operating System: Linux/Gentoo PHP Version: 4.4.4 New Comment: Make sure your phpinfo() display the expected value of open_basedir. Turn on display_errors etc. It doesn't depend on the server API in any way. Previous Comments: [2006-09-26 15:58:57] manuel at mausz dot at Please try using mod_php. Using the client also don't work for me. Oh and just to be sure: - tried with safe_mode on + off - open_basedir does _not_ include /tmp ;) [2006-09-26 15:30:39] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Cannot reproduce: # ./sapi/cli/php -r 'var_dump(tempnam(false, temp));' Warning: tempnam(): open_basedir restriction in effect. File() is not within the allowed path(s): (/www) in Command line code on line 1 bool(false) [2006-09-26 15:19:47] manuel at mausz dot at Description: tempnam bypasses open_basedir if dir = false Reproduce code: --- ?php $tempfile = tempnam(false, phptest); ? Expected result: Warning: tempnam() [function.tempnam]: open_basedir restriction in effect. File(/tmp) is not within the allowed path(s): (...) in Actual result: -- # ls /tmp/phptest* /tmp/phptestt4mIOa -- Edit this bug report at http://bugs.php.net/?id=38963edit=1
#38808 [Asn-Csd]: maybe ref issue for current() and others
ID: 38808 Updated by: [EMAIL PROTECTED] Reported By: dev at ioncube dot com -Status: Assigned +Status: Closed Bug Type: Variables related Operating System: Any PHP Version: 5.1.6 Assigned To: dmitry New Comment: Fixed in CVS HEAD and PHP_5_2. Previous Comments: [2006-09-25 13:05:51] [EMAIL PROTECTED] Dmitry, any ideas? [2006-09-14 11:25:20] dev at ioncube dot com The point is that whether to send a parameter by ref or not is determined in _COMPILE TIME_. Correct :) Prior to 5.1, whether a function accepted a value by reference or value was a boolean decision, and the code in the executor, (which is still there), would promote the passed variable to by reference if the function required it. This is how and why the function next() would still work in this example for even a dynamic call because the parameter must be a reference, and that logic still works. As of 5.1.0 the test became numeric to distinguish the should be and maybe cases, and the executor only checks for whether a parameter should be passed by reference and not whether it may be. As a result, the change to pass by reference does not happen for current even though it is a valid candidate. [2006-09-14 10:55:22] [EMAIL PROTECTED] Heh, that's actually interesting. The point is that whether to send a parameter by ref or not is determined in _COMPILE TIME_. Apparently it's not possible to detect it in this case, since the value of $f is not known at that moment. [2006-09-13 14:50:06] dev at ioncube dot com Description: Minor issue; the implementation of maybe reference parameters since 5.1.0 (and still present in 5.2RC2) can cause unexpected results. Reproduce code: --- ?php $b = array(1='one', 2='two'); $a = $b; var_dump(current($a)); next($a); $f = current; var_dump($f($a)); ? Expected result: string(3) one string(3) two Actual result: -- string(3) one string(3) one -- Edit this bug report at http://bugs.php.net/?id=38808edit=1
#38961 [Opn-Fbk]: Metaphone results in segmentation fault
ID: 38961
Updated by: [EMAIL PROTECTED]
Reported By: nikolas dot hagelstein at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Netbsd 3.0.1 AMD64
PHP Version: 5.1.6
New Comment:
Syntax error: Unterminated quoted string
Please elaborate.
Previous Comments:
[2006-09-26 15:56:37] nikolas dot hagelstein at gmail dot com
I checked out 5.2 from cvs but i am not able to build it on my
maschine.
Syntax error: Unterminated quoted string
Any other way to check if the the 64bit fix works?
[2006-09-26 15:41:22] [EMAIL PROTECTED]
Can you please try the latest CVS, it has a 64bit fix that may
fix the crash you are experiencing.
[2006-09-26 15:35:34] nikolas dot hagelstein at gmail dot com
So it is eigther a system specific issue (i was able to reproduce it on
2 maschines) or you did not used an utf8 file ;)
[2006-09-26 15:32:42] [EMAIL PROTECTED]
Works perfectly fine: string(0)
[2006-09-26 15:16:57] nikolas dot hagelstein at gmail dot com
I can not try that since i am not able to submit real utf8 chars
through my shell.
test.php
?php
echo crash:.metaphone('ö');
?
php test.php
results in a segmentation fault test.php needs to be an UTF8 file.
file -i test.php
test.php: text/plain; charset=utf-8
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/38961
--
Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38805 [Com]: PDO Truncates Text from SQL Server Text Data Type Field
ID: 38805 Comment by: ritch at bugsoftware dot co dot uk Reported By: gkrajci at arescorporation dot com Status: Assigned Bug Type: PDO related Operating System: Windows NT PBMA-WB2 5.2 build 37 PHP Version: 5.1.6 Assigned To: wez New Comment: I'm also suffering this problem after changing my database connection type to PDO. I'm running PHP 5.1.2 on Windows server 2003 with MSSQL 2005. In the old mssql ext. you had to specificaly tell the configure it in php.ini to bring back larger text fields: ; Valid range 0 - 2147483647. Default = 4096. mssql.textlimit = 2147483647 ; Valid range 0 - 2147483647. Default = 4096. mssql.textsize = 2147483647 I have not found the same for the new PDO extension - so I'm assuming this has some thing to do with the problem. (My text fields are also truncated to 4096) Help with this issue would be greatley appreciated. Previous Comments: [2006-09-14 11:47:26] gkrajci at arescorporation dot com Microsoft SQL Server connections PHP.INI --- extension=php_pdo.dll extension=php_pdo_mssql.dll extension=php_pdo_mysql.dll PDO PDO support enabled PDO drivers mssql, mysql pdo_mssql PDO Driver for MSSQL DB-lib enabled Flavour MSSQL_70 pdo_mysql PDO Driver for MySQL, client library version 5.0.22 [2006-09-13 15:45:31] [EMAIL PROTECTED] I assume you're using ODBC? [2006-09-13 15:40:37] [EMAIL PROTECTED] what PDO driver are you using? [2006-09-13 13:06:35] gkrajci at arescorporation dot com Description: When using PDO to retrieve text from a SQL Server text data type field the text is truncated when I display it on a Web page PDO Transcript length = 4096 (truncated) PEAR Transcript length = 6139(full text) Using SQL Server 2000 Reproduce code: --- $sql = SELECT title AS VideoTitle, transcript_text AS TranscriptText FROM video WHERE video_id = 324; $dbh = new PDO($pdo_dsn, $db_user, $db_password); $transcript_q = $dbh-query($sql); $transcript_rs = $transcript_q-fetch(); $pear_dsn = $db_type://$db_user:[EMAIL PROTECTED]/$db_name; require_once( 'DB.php' ); $db = DB::connect( $pear_dsn, true ); if ( DB::isError($db) ) die( $db-getMessage() ); $res = $db-query($sql); $row = $res-fetchRow(); Expected result: The text in TranscriptText to be the text and the same length. Actual result: -- See Description for this bug report. -- Edit this bug report at http://bugs.php.net/?id=38805edit=1
#38961 [Fbk-Opn]: Metaphone results in segmentation fault
ID: 38961 User updated by: nikolas dot hagelstein at gmail dot com Reported By: nikolas dot hagelstein at gmail dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Netbsd 3.0.1 AMD64 PHP Version: 5.1.6 New Comment: Ok, i just copied the cvs metaphone.c to my 5.1.6 source tree and did a rebuild. Still segfault, same backtrace : Program received signal SIGSEGV, Segmentation fault. 0x0050c86c in zif_metaphone () (gdb) bt #0 0x0050c86c in zif_metaphone () #1 0x0050c762 in zif_metaphone () #2 0x0059f309 in execute () #3 0x0059eba0 in execute () #4 0x00585886 in zend_execute_scripts () #5 0x0054bfe9 in php_execute_script () #6 0x005eab04 in main () #7 0x004407a8 in ___start () Previous Comments: [2006-09-26 16:04:18] [EMAIL PROTECTED] Syntax error: Unterminated quoted string Please elaborate. [2006-09-26 15:56:37] nikolas dot hagelstein at gmail dot com I checked out 5.2 from cvs but i am not able to build it on my maschine. Syntax error: Unterminated quoted string Any other way to check if the the 64bit fix works? [2006-09-26 15:41:22] [EMAIL PROTECTED] Can you please try the latest CVS, it has a 64bit fix that may fix the crash you are experiencing. [2006-09-26 15:35:34] nikolas dot hagelstein at gmail dot com So it is eigther a system specific issue (i was able to reproduce it on 2 maschines) or you did not used an utf8 file ;) [2006-09-26 15:32:42] [EMAIL PROTECTED] Works perfectly fine: string(0) 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/38961 -- Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38961 [Opn-Fbk]: Metaphone results in segmentation fault
ID: 38961 Updated by: [EMAIL PROTECTED] Reported By: nikolas dot hagelstein at gmail dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Netbsd 3.0.1 AMD64 PHP Version: 5.1.6 New Comment: With --enable-debug we would get a lot more useful information. Previous Comments: [2006-09-26 16:23:48] nikolas dot hagelstein at gmail dot com Ok, i just copied the cvs metaphone.c to my 5.1.6 source tree and did a rebuild. Still segfault, same backtrace : Program received signal SIGSEGV, Segmentation fault. 0x0050c86c in zif_metaphone () (gdb) bt #0 0x0050c86c in zif_metaphone () #1 0x0050c762 in zif_metaphone () #2 0x0059f309 in execute () #3 0x0059eba0 in execute () #4 0x00585886 in zend_execute_scripts () #5 0x0054bfe9 in php_execute_script () #6 0x005eab04 in main () #7 0x004407a8 in ___start () [2006-09-26 16:04:18] [EMAIL PROTECTED] Syntax error: Unterminated quoted string Please elaborate. [2006-09-26 15:56:37] nikolas dot hagelstein at gmail dot com I checked out 5.2 from cvs but i am not able to build it on my maschine. Syntax error: Unterminated quoted string Any other way to check if the the 64bit fix works? [2006-09-26 15:41:22] [EMAIL PROTECTED] Can you please try the latest CVS, it has a 64bit fix that may fix the crash you are experiencing. [2006-09-26 15:35:34] nikolas dot hagelstein at gmail dot com So it is eigther a system specific issue (i was able to reproduce it on 2 maschines) or you did not used an utf8 file ;) 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/38961 -- Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38961 [Fbk-Opn]: Metaphone results in segmentation fault
ID: 38961 User updated by: nikolas dot hagelstein at gmail dot com Reported By: nikolas dot hagelstein at gmail dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Netbsd 3.0.1 AMD64 PHP Version: 5.1.6 New Comment: recompiled using --enabled-debug - same output Previous Comments: [2006-09-26 16:27:57] [EMAIL PROTECTED] With --enable-debug we would get a lot more useful information. [2006-09-26 16:23:48] nikolas dot hagelstein at gmail dot com Ok, i just copied the cvs metaphone.c to my 5.1.6 source tree and did a rebuild. Still segfault, same backtrace : Program received signal SIGSEGV, Segmentation fault. 0x0050c86c in zif_metaphone () (gdb) bt #0 0x0050c86c in zif_metaphone () #1 0x0050c762 in zif_metaphone () #2 0x0059f309 in execute () #3 0x0059eba0 in execute () #4 0x00585886 in zend_execute_scripts () #5 0x0054bfe9 in php_execute_script () #6 0x005eab04 in main () #7 0x004407a8 in ___start () [2006-09-26 16:04:18] [EMAIL PROTECTED] Syntax error: Unterminated quoted string Please elaborate. [2006-09-26 15:56:37] nikolas dot hagelstein at gmail dot com I checked out 5.2 from cvs but i am not able to build it on my maschine. Syntax error: Unterminated quoted string Any other way to check if the the 64bit fix works? [2006-09-26 15:41:22] [EMAIL PROTECTED] Can you please try the latest CVS, it has a 64bit fix that may fix the crash you are experiencing. 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/38961 -- Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38961 [Opn-Fbk]: Metaphone results in segmentation fault
ID: 38961 Updated by: [EMAIL PROTECTED] Reported By: nikolas dot hagelstein at gmail dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Netbsd 3.0.1 AMD64 PHP Version: 5.1.6 New Comment: --enabled-debug != --enable-debug Previous Comments: [2006-09-26 16:38:21] nikolas dot hagelstein at gmail dot com recompiled using --enabled-debug - same output [2006-09-26 16:27:57] [EMAIL PROTECTED] With --enable-debug we would get a lot more useful information. [2006-09-26 16:23:48] nikolas dot hagelstein at gmail dot com Ok, i just copied the cvs metaphone.c to my 5.1.6 source tree and did a rebuild. Still segfault, same backtrace : Program received signal SIGSEGV, Segmentation fault. 0x0050c86c in zif_metaphone () (gdb) bt #0 0x0050c86c in zif_metaphone () #1 0x0050c762 in zif_metaphone () #2 0x0059f309 in execute () #3 0x0059eba0 in execute () #4 0x00585886 in zend_execute_scripts () #5 0x0054bfe9 in php_execute_script () #6 0x005eab04 in main () #7 0x004407a8 in ___start () [2006-09-26 16:04:18] [EMAIL PROTECTED] Syntax error: Unterminated quoted string Please elaborate. [2006-09-26 15:56:37] nikolas dot hagelstein at gmail dot com I checked out 5.2 from cvs but i am not able to build it on my maschine. Syntax error: Unterminated quoted string Any other way to check if the the 64bit fix works? 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/38961 -- Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38961 [Fbk-Opn]: Metaphone results in segmentation fault
ID: 38961 User updated by: nikolas dot hagelstein at gmail dot com Reported By: nikolas dot hagelstein at gmail dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Netbsd 3.0.1 AMD64 PHP Version: 5.1.6 New Comment: Just a typo withhin my comment debug is enabled see beyond PHP 5.1.6 (cli) (built: Sep 26 2006 18:33:22) (DEBUG) Previous Comments: [2006-09-26 16:48:12] [EMAIL PROTECTED] --enabled-debug != --enable-debug [2006-09-26 16:38:21] nikolas dot hagelstein at gmail dot com recompiled using --enabled-debug - same output [2006-09-26 16:27:57] [EMAIL PROTECTED] With --enable-debug we would get a lot more useful information. [2006-09-26 16:23:48] nikolas dot hagelstein at gmail dot com Ok, i just copied the cvs metaphone.c to my 5.1.6 source tree and did a rebuild. Still segfault, same backtrace : Program received signal SIGSEGV, Segmentation fault. 0x0050c86c in zif_metaphone () (gdb) bt #0 0x0050c86c in zif_metaphone () #1 0x0050c762 in zif_metaphone () #2 0x0059f309 in execute () #3 0x0059eba0 in execute () #4 0x00585886 in zend_execute_scripts () #5 0x0054bfe9 in php_execute_script () #6 0x005eab04 in main () #7 0x004407a8 in ___start () [2006-09-26 16:04:18] [EMAIL PROTECTED] Syntax error: Unterminated quoted string Please elaborate. 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/38961 -- Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38961 [Opn-Fbk]: Metaphone results in segmentation fault
ID: 38961 Updated by: [EMAIL PROTECTED] Reported By: nikolas dot hagelstein at gmail dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Netbsd 3.0.1 AMD64 PHP Version: 5.1.6 New Comment: And the backtrace is EXACTLY the same? Just #0 0x0050c86c in zif_metaphone () ? Previous Comments: [2006-09-26 16:53:05] nikolas dot hagelstein at gmail dot com Just a typo withhin my comment debug is enabled see beyond PHP 5.1.6 (cli) (built: Sep 26 2006 18:33:22) (DEBUG) [2006-09-26 16:48:12] [EMAIL PROTECTED] --enabled-debug != --enable-debug [2006-09-26 16:38:21] nikolas dot hagelstein at gmail dot com recompiled using --enabled-debug - same output [2006-09-26 16:27:57] [EMAIL PROTECTED] With --enable-debug we would get a lot more useful information. [2006-09-26 16:23:48] nikolas dot hagelstein at gmail dot com Ok, i just copied the cvs metaphone.c to my 5.1.6 source tree and did a rebuild. Still segfault, same backtrace : Program received signal SIGSEGV, Segmentation fault. 0x0050c86c in zif_metaphone () (gdb) bt #0 0x0050c86c in zif_metaphone () #1 0x0050c762 in zif_metaphone () #2 0x0059f309 in execute () #3 0x0059eba0 in execute () #4 0x00585886 in zend_execute_scripts () #5 0x0054bfe9 in php_execute_script () #6 0x005eab04 in main () #7 0x004407a8 in ___start () 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/38961 -- Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38961 [Fbk-Opn]: Metaphone results in segmentation fault
ID: 38961 User updated by: nikolas dot hagelstein at gmail dot com Reported By: nikolas dot hagelstein at gmail dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Netbsd 3.0.1 AMD64 PHP Version: 5.1.6 New Comment: yes ...it is: Starting program: /usr/pkg/bin/php /var/www/www.chaosbutze.de/htdocs/test.php (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x0051bb0f in zif_metaphone () (gdb) bt #0 0x0051bb0f in zif_metaphone () #1 0x0051b9e2 in zif_metaphone () #2 0x005bfa95 in execute () #3 0x005bf21c in execute () #4 0x005a2ef6 in zend_execute_scripts () #5 0x00562c09 in php_execute_script () #6 0x006133e9 in main () #7 0x00440aa8 in ___start () i even tried -e but without any success... Previous Comments: [2006-09-26 16:57:21] [EMAIL PROTECTED] And the backtrace is EXACTLY the same? Just #0 0x0050c86c in zif_metaphone () ? [2006-09-26 16:53:05] nikolas dot hagelstein at gmail dot com Just a typo withhin my comment debug is enabled see beyond PHP 5.1.6 (cli) (built: Sep 26 2006 18:33:22) (DEBUG) [2006-09-26 16:48:12] [EMAIL PROTECTED] --enabled-debug != --enable-debug [2006-09-26 16:38:21] nikolas dot hagelstein at gmail dot com recompiled using --enabled-debug - same output [2006-09-26 16:27:57] [EMAIL PROTECTED] With --enable-debug we would get a lot more useful information. 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/38961 -- Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38961 [Opn-Fbk]: Metaphone results in segmentation fault
ID: 38961 Updated by: [EMAIL PROTECTED] Reported By: nikolas dot hagelstein at gmail dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Netbsd 3.0.1 AMD64 PHP Version: 5.1.6 New Comment: Well, your PHP is built without --enable-debug, that's the fact. Previous Comments: [2006-09-26 17:00:46] nikolas dot hagelstein at gmail dot com yes ...it is: Starting program: /usr/pkg/bin/php /var/www/www.chaosbutze.de/htdocs/test.php (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x0051bb0f in zif_metaphone () (gdb) bt #0 0x0051bb0f in zif_metaphone () #1 0x0051b9e2 in zif_metaphone () #2 0x005bfa95 in execute () #3 0x005bf21c in execute () #4 0x005a2ef6 in zend_execute_scripts () #5 0x00562c09 in php_execute_script () #6 0x006133e9 in main () #7 0x00440aa8 in ___start () i even tried -e but without any success... [2006-09-26 16:57:21] [EMAIL PROTECTED] And the backtrace is EXACTLY the same? Just #0 0x0050c86c in zif_metaphone () ? [2006-09-26 16:53:05] nikolas dot hagelstein at gmail dot com Just a typo withhin my comment debug is enabled see beyond PHP 5.1.6 (cli) (built: Sep 26 2006 18:33:22) (DEBUG) [2006-09-26 16:48:12] [EMAIL PROTECTED] --enabled-debug != --enable-debug [2006-09-26 16:38:21] nikolas dot hagelstein at gmail dot com recompiled using --enabled-debug - same output 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/38961 -- Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38961 [Fbk]: Metaphone results in segmentation fault
ID: 38961 Updated by: [EMAIL PROTECTED] Reported By: nikolas dot hagelstein at gmail dot com Status: Feedback Bug Type: Reproducible crash Operating System: Netbsd 3.0.1 AMD64 PHP Version: 5.1.6 New Comment: ..or your PHP binary is stripped. Just get the sources, compile them with ./configure --enable-debug --disable-all and use the sapi/cli/php binary. Previous Comments: [2006-09-26 17:02:49] [EMAIL PROTECTED] Well, your PHP is built without --enable-debug, that's the fact. [2006-09-26 17:00:46] nikolas dot hagelstein at gmail dot com yes ...it is: Starting program: /usr/pkg/bin/php /var/www/www.chaosbutze.de/htdocs/test.php (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x0051bb0f in zif_metaphone () (gdb) bt #0 0x0051bb0f in zif_metaphone () #1 0x0051b9e2 in zif_metaphone () #2 0x005bfa95 in execute () #3 0x005bf21c in execute () #4 0x005a2ef6 in zend_execute_scripts () #5 0x00562c09 in php_execute_script () #6 0x006133e9 in main () #7 0x00440aa8 in ___start () i even tried -e but without any success... [2006-09-26 16:57:21] [EMAIL PROTECTED] And the backtrace is EXACTLY the same? Just #0 0x0050c86c in zif_metaphone () ? [2006-09-26 16:53:05] nikolas dot hagelstein at gmail dot com Just a typo withhin my comment debug is enabled see beyond PHP 5.1.6 (cli) (built: Sep 26 2006 18:33:22) (DEBUG) [2006-09-26 16:48:12] [EMAIL PROTECTED] --enabled-debug != --enable-debug 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/38961 -- Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38961 [Fbk-Opn]: Metaphone results in segmentation fault
ID: 38961 User updated by: nikolas dot hagelstein at gmail dot com Reported By: nikolas dot hagelstein at gmail dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Netbsd 3.0.1 AMD64 PHP Version: 5.1.6 New Comment: it is php -v returns (DEBUG) which indicates that it has been build with enable-debug: PHP 5.1.6 (cli) (built: Sep 26 2006 18:33:22) (DEBUG) Previous Comments: [2006-09-26 17:06:29] [EMAIL PROTECTED] ..or your PHP binary is stripped. Just get the sources, compile them with ./configure --enable-debug --disable-all and use the sapi/cli/php binary. [2006-09-26 17:02:49] [EMAIL PROTECTED] Well, your PHP is built without --enable-debug, that's the fact. [2006-09-26 17:00:46] nikolas dot hagelstein at gmail dot com yes ...it is: Starting program: /usr/pkg/bin/php /var/www/www.chaosbutze.de/htdocs/test.php (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x0051bb0f in zif_metaphone () (gdb) bt #0 0x0051bb0f in zif_metaphone () #1 0x0051b9e2 in zif_metaphone () #2 0x005bfa95 in execute () #3 0x005bf21c in execute () #4 0x005a2ef6 in zend_execute_scripts () #5 0x00562c09 in php_execute_script () #6 0x006133e9 in main () #7 0x00440aa8 in ___start () i even tried -e but without any success... [2006-09-26 16:57:21] [EMAIL PROTECTED] And the backtrace is EXACTLY the same? Just #0 0x0050c86c in zif_metaphone () ? [2006-09-26 16:53:05] nikolas dot hagelstein at gmail dot com Just a typo withhin my comment debug is enabled see beyond PHP 5.1.6 (cli) (built: Sep 26 2006 18:33:22) (DEBUG) 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/38961 -- Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38961 [Opn-Fbk]: Metaphone results in segmentation fault
ID: 38961 Updated by: [EMAIL PROTECTED] Reported By: nikolas dot hagelstein at gmail dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Netbsd 3.0.1 AMD64 PHP Version: 5.1.6 Previous Comments: [2006-09-26 17:07:51] nikolas dot hagelstein at gmail dot com it is php -v returns (DEBUG) which indicates that it has been build with enable-debug: PHP 5.1.6 (cli) (built: Sep 26 2006 18:33:22) (DEBUG) [2006-09-26 17:06:29] [EMAIL PROTECTED] ..or your PHP binary is stripped. Just get the sources, compile them with ./configure --enable-debug --disable-all and use the sapi/cli/php binary. [2006-09-26 17:02:49] [EMAIL PROTECTED] Well, your PHP is built without --enable-debug, that's the fact. [2006-09-26 17:00:46] nikolas dot hagelstein at gmail dot com yes ...it is: Starting program: /usr/pkg/bin/php /var/www/www.chaosbutze.de/htdocs/test.php (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x0051bb0f in zif_metaphone () (gdb) bt #0 0x0051bb0f in zif_metaphone () #1 0x0051b9e2 in zif_metaphone () #2 0x005bfa95 in execute () #3 0x005bf21c in execute () #4 0x005a2ef6 in zend_execute_scripts () #5 0x00562c09 in php_execute_script () #6 0x006133e9 in main () #7 0x00440aa8 in ___start () i even tried -e but without any success... [2006-09-26 16:57:21] [EMAIL PROTECTED] And the backtrace is EXACTLY the same? Just #0 0x0050c86c in zif_metaphone () ? 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/38961 -- Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38965 [NEW]: mssql_connect doesn't use TCP 1433 for external SQL Server
From: aren at cambre dot biz Operating system: Windows 2003 (for both servers) PHP version: 4.4.4 PHP Bug Type: MSSQL related Bug description: mssql_connect doesn't use TCP 1433 for external SQL Server Description: When using mssql_connect to connect to a SQL Server database on a remote server, PHP attemtps to connect using named pipes. This is a terribly outdated behavior; SQL Server connections these days are almost always done with TCP 1433. I figured this out with a difficult phpBB installation and using Wireshark (formerly Ethereal) to watch network traffic. There is a registry hack that can force the SQL Server Client program to use TCP 1433, but this hack's effects on other software is unknown. For more info, see http://people.smu.edu/acambre/blog/2006/09/22/Buggy+PHP.aspx and http://www.phpbb.com/phpBB/viewtopic.php?t=446662postdays=0postorder=ascstart=0 Reproduce code: --- Just use mssql_connect to connect to an external database. Expected result: The database should open just as if the database is on localhost. Actual result: -- Usually a cannot connect error. -- Edit bug report at http://bugs.php.net/?id=38965edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38965r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38965r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38965r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38965r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38965r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38965r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38965r=needscript Try newer version:http://bugs.php.net/fix.php?id=38965r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38965r=support Expected behavior:http://bugs.php.net/fix.php?id=38965r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38965r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38965r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38965r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38965r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38965r=dst IIS Stability:http://bugs.php.net/fix.php?id=38965r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38965r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38965r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38965r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38965r=mysqlcfg
#38965 [Opn-Asn]: mssql_connect doesn't use TCP 1433 for external SQL Server
ID: 38965 Updated by: [EMAIL PROTECTED] Reported By: aren at cambre dot biz -Status: Open +Status: Assigned Bug Type: MSSQL related Operating System: Windows 2003 (for both servers) PHP Version: 4.4.4 -Assigned To: +Assigned To: fmk New Comment: Frank, is this really a PHP problem? Previous Comments: [2006-09-26 17:16:54] aren at cambre dot biz Description: When using mssql_connect to connect to a SQL Server database on a remote server, PHP attemtps to connect using named pipes. This is a terribly outdated behavior; SQL Server connections these days are almost always done with TCP 1433. I figured this out with a difficult phpBB installation and using Wireshark (formerly Ethereal) to watch network traffic. There is a registry hack that can force the SQL Server Client program to use TCP 1433, but this hack's effects on other software is unknown. For more info, see http://people.smu.edu/acambre/blog/2006/09/22/Buggy+PHP.aspx and http://www.phpbb.com/phpBB/viewtopic.php?t=446662postdays=0postorder=ascstart=0 Reproduce code: --- Just use mssql_connect to connect to an external database. Expected result: The database should open just as if the database is on localhost. Actual result: -- Usually a cannot connect error. -- Edit this bug report at http://bugs.php.net/?id=38965edit=1
#38961 [Fbk]: Metaphone results in segmentation fault
ID: 38961 Updated by: [EMAIL PROTECTED] Reported By: nikolas dot hagelstein at gmail dot com Status: Feedback Bug Type: Reproducible crash Operating System: Netbsd 3.0.1 AMD64 PHP Version: 5.1.6 New Comment: Please do the following: #1 fetch http://snaps.php.net/php5.2-200609261630.tar.bz2 #2 extract it #3 cd into the directory #4 ./configure --disable-all --enable-debug #5 make #6 sapi/cli/php your_test_file.php Previous Comments: [2006-09-26 17:07:51] nikolas dot hagelstein at gmail dot com it is php -v returns (DEBUG) which indicates that it has been build with enable-debug: PHP 5.1.6 (cli) (built: Sep 26 2006 18:33:22) (DEBUG) [2006-09-26 17:06:29] [EMAIL PROTECTED] ..or your PHP binary is stripped. Just get the sources, compile them with ./configure --enable-debug --disable-all and use the sapi/cli/php binary. [2006-09-26 17:02:49] [EMAIL PROTECTED] Well, your PHP is built without --enable-debug, that's the fact. [2006-09-26 17:00:46] nikolas dot hagelstein at gmail dot com yes ...it is: Starting program: /usr/pkg/bin/php /var/www/www.chaosbutze.de/htdocs/test.php (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x0051bb0f in zif_metaphone () (gdb) bt #0 0x0051bb0f in zif_metaphone () #1 0x0051b9e2 in zif_metaphone () #2 0x005bfa95 in execute () #3 0x005bf21c in execute () #4 0x005a2ef6 in zend_execute_scripts () #5 0x00562c09 in php_execute_script () #6 0x006133e9 in main () #7 0x00440aa8 in ___start () i even tried -e but without any success... [2006-09-26 16:57:21] [EMAIL PROTECTED] And the backtrace is EXACTLY the same? Just #0 0x0050c86c in zif_metaphone () ? 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/38961 -- Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38820 [Opn-Fbk]: chdir(.) and chdir(..) don't work with Apache 2.0+
ID: 38820 Updated by: [EMAIL PROTECTED] Reported By: ras at fyn dot dk -Status: Open +Status: Feedback Bug Type: Directory function related Operating System: Win XP SP2 PHP Version: 5.1.6 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Previous Comments: [2006-09-26 06:19:26] ras at fyn dot dk No, it does not reproduce on Linux, as said, the bug appears to be specific to the Windows port. [2006-09-25 13:04:23] [EMAIL PROTECTED] Not reproducible on Linux with Apache2.0.55 worker/prefork. [2006-09-14 11:21:56] ras at fyn dot dk Tony, as said - I already tried the current snapshot, downloaded the latest development release yesterday. Unless it was fixed and updated today, I'm sorry, but I don't have time to uninstall, reinstall and reconfigure Apache and PHP again just now. My current Apache 1.3 installation works just fine for me - I only use the Windows release for testing and development on my workstation... [2006-09-14 08:50:01] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-09-14 06:40:02] ras at fyn dot dk Description: When using chdir() with relative folders (e.g. . and ..), under Apache 2.0 or newer, using either the php5 module or the CGI binary, the function changes the current directory to the Apache application folder, rather than a folder relative to the current folder. Tested with PHP 5.1.6, and current 5.2.x-dev, under Apache 2.2.3, 2.0.59 and 2.0.55 - all tested with both the php5 module and the CGI binary, all with same result. Bug appears to be specific to the Windows port of PHP. Apache 1.3.37 exhibits no similar problems. I filed this bug with Apache, but Ruediger Pluem at apache.org says that this is clearly a PHP bug: http://issues.apache.org/bugzilla/show_bug.cgi?id=40496 Reproduce code: --- // create the test folder before running the script! echo getcwd() . br /; chdir(test); echo getcwd() . br /; chdir(..); echo getcwd() . br /; chdir(..); echo getcwd(); Expected result: C:\Web C:\Web\test C:\Web C:\ Actual result: -- C:\Web C:\Web\test C:\Programmer\Apache Group C:\Programmer\Apache Group -- Edit this bug report at http://bugs.php.net/?id=38820edit=1
#38965 [Asn-Bgs]: mssql_connect doesn't use TCP 1433 for external SQL Server
ID: 38965 Updated by: [EMAIL PROTECTED] Reported By: aren at cambre dot biz -Status: Assigned +Status: Bogus Bug Type: MSSQL related Operating System: Windows 2003 (for both servers) PHP Version: 4.4.4 Assigned To: fmk New Comment: No PHP uses ntwdblib and if you install the Client tools from MSSQL server you can define the default protocol. Older versions of ntwdblib (or combinations of other MS tools installed) uses named pipes as the default. The best way is to install the Client Tools and us the Clinet Network utility to set default protocol as well as create aliases for different servers. Each alias can be defined with the prefered protocol. Previous Comments: [2006-09-26 17:25:21] [EMAIL PROTECTED] Frank, is this really a PHP problem? [2006-09-26 17:16:54] aren at cambre dot biz Description: When using mssql_connect to connect to a SQL Server database on a remote server, PHP attemtps to connect using named pipes. This is a terribly outdated behavior; SQL Server connections these days are almost always done with TCP 1433. I figured this out with a difficult phpBB installation and using Wireshark (formerly Ethereal) to watch network traffic. There is a registry hack that can force the SQL Server Client program to use TCP 1433, but this hack's effects on other software is unknown. For more info, see http://people.smu.edu/acambre/blog/2006/09/22/Buggy+PHP.aspx and http://www.phpbb.com/phpBB/viewtopic.php?t=446662postdays=0postorder=ascstart=0 Reproduce code: --- Just use mssql_connect to connect to an external database. Expected result: The database should open just as if the database is on localhost. Actual result: -- Usually a cannot connect error. -- Edit this bug report at http://bugs.php.net/?id=38965edit=1
#38961 [Fbk-Opn]: Metaphone results in segmentation fault
ID: 38961
User updated by: nikolas dot hagelstein at gmail dot com
Reported By: nikolas dot hagelstein at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Netbsd 3.0.1 AMD64
PHP Version: 5.1.6
New Comment:
sorry folks you have been right it seems as if the pkgsrc process
somehow stripes debug informations :|. Anyway here is what i got using
a native build process and the native sources (without the latest cvs
patch provided by iliaa)
Program received signal SIGSEGV, Segmentation fault.
0x004a00ff in metaphone (word=0x8127c0 ö, word_len=2,
max_phonemes=0, phoned_word=0x7f7fcc70, traditional=1)
at /usr/local/src/php-5.1.6/ext/standard/metaphone.c:195
195 for (; !isalpha(Curr_Letter); w_idx++) {
(gdb) bt
#0 0x004a00ff in metaphone (word=0x8127c0 ö, word_len=2,
max_phonemes=0, phoned_word=0x7f7fcc70, traditional=1)
at /usr/local/src/php-5.1.6/ext/standard/metaphone.c:195
#1 0x0049ff40 in zif_metaphone (ht=1, return_value=0x812840,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at /usr/local/src/php-5.1.6/ext/standard/metaphone.c:46
#2 0x00561366 in zend_do_fcall_common_helper_SPEC (
execute_data=0x7f7fce20) at zend_vm_execute.h:200
#3 0x0056493d in ZEND_DO_FCALL_SPEC_CONST_HANDLER (
execute_data=0x7f7fce20) at zend_vm_execute.h:1640
#4 0x00560e6a in execute (op_array=0x783c40) at
zend_vm_execute.h:92
#5 0x0053ddf6 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/local/src/php-5.1.6/Zend/zend.c:1109
#6 0x004eed77 in php_execute_script
(primary_file=0x7f7fe7c0)
at /usr/local/src/php-5.1.6/main/main.c:1737
#7 0x005b1cd7 in main (argc=2, argv=0x7f7fe8c0)
at /usr/local/src/php-5.1.6/sapi/cgi/cgi_main.c:1612
Previous Comments:
[2006-09-26 17:28:04] [EMAIL PROTECTED]
Please do the following:
#1 fetch http://snaps.php.net/php5.2-200609261630.tar.bz2
#2 extract it
#3 cd into the directory
#4 ./configure --disable-all --enable-debug
#5 make
#6 sapi/cli/php your_test_file.php
[2006-09-26 17:07:51] nikolas dot hagelstein at gmail dot com
it is php -v returns (DEBUG) which indicates that it has been build
with enable-debug:
PHP 5.1.6 (cli) (built: Sep 26 2006 18:33:22) (DEBUG)
[2006-09-26 17:06:29] [EMAIL PROTECTED]
..or your PHP binary is stripped.
Just get the sources, compile them with ./configure --enable-debug
--disable-all and use the sapi/cli/php binary.
[2006-09-26 17:02:49] [EMAIL PROTECTED]
Well, your PHP is built without --enable-debug, that's the fact.
[2006-09-26 17:00:46] nikolas dot hagelstein at gmail dot com
yes ...it is:
Starting program: /usr/pkg/bin/php
/var/www/www.chaosbutze.de/htdocs/test.php
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x0051bb0f in zif_metaphone ()
(gdb) bt
#0 0x0051bb0f in zif_metaphone ()
#1 0x0051b9e2 in zif_metaphone ()
#2 0x005bfa95 in execute ()
#3 0x005bf21c in execute ()
#4 0x005a2ef6 in zend_execute_scripts ()
#5 0x00562c09 in php_execute_script ()
#6 0x006133e9 in main ()
#7 0x00440aa8 in ___start ()
i even tried -e but without any success...
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/38961
--
Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38954 [Bgs-Opn]: PHP cannot connect with MySQL/MySQLi
ID: 38954 User updated by: akaraethon at gmail dot com Reported By: akaraethon at gmail dot com -Status: Bogus +Status: Open Bug Type: MySQL related Operating System: Windows Server 2003 32bit PHP Version: 5.1.6 New Comment: Fine, you are right its not a forum, for some ODD reason I couldnt find even one forum out there devoted to PHP, and If I were a newbie, and not someone who has worked with PHP since PHP2.0 I might agree that I just made a config mistake, but I have, I didnt and I still think this may be some sort of problem with PHP not liking something. Previous Comments: [2006-09-26 07:09:11] [EMAIL PROTECTED] Still not PHP problem. And I don't see any reasons to post parts of the docs here, it's not a forum. [2006-09-26 01:31:44] akaraethon at gmail dot com Ok, are you not READING what I write? In my very first post I said I have enabled the DLL file, but PHP will not connect. so why don't we do this, instead of just changing this to bogus (again) lets figure out whats going on, and see if we cant come toan agreement as to the status, if you think its bogus then tell me what to do. [2006-09-25 22:55:25] [EMAIL PROTECTED] www.php.net/mysql MySQL is no longer enabled by default, so the php_mysql.dll DLL must be enabled... [2006-09-25 22:48:05] akaraethon at gmail dot com Well then where is the problem comming from? I HAVE followed ALL the instructions for setup on IIS and MySQL is running fine, so if this isnt a bug then why is it happening? [2006-09-25 20:57:24] [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. 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/38954 -- Edit this bug report at http://bugs.php.net/?id=38954edit=1
#38961 [Opn]: Metaphone results in segmentation fault
ID: 38961
User updated by: nikolas dot hagelstein at gmail dot com
Reported By: nikolas dot hagelstein at gmail dot com
Status: Open
Bug Type: Reproducible crash
Operating System: Netbsd 3.0.1 AMD64
PHP Version: 5.1.6
New Comment:
segfault on 5.1.6 and php5.2-200609261630 same backtrace
Previous Comments:
[2006-09-26 18:04:20] nikolas dot hagelstein at gmail dot com
sorry folks you have been right it seems as if the pkgsrc process
somehow stripes debug informations :|. Anyway here is what i got using
a native build process and the native sources (without the latest cvs
patch provided by iliaa)
Program received signal SIGSEGV, Segmentation fault.
0x004a00ff in metaphone (word=0x8127c0 ö, word_len=2,
max_phonemes=0, phoned_word=0x7f7fcc70, traditional=1)
at /usr/local/src/php-5.1.6/ext/standard/metaphone.c:195
195 for (; !isalpha(Curr_Letter); w_idx++) {
(gdb) bt
#0 0x004a00ff in metaphone (word=0x8127c0 ö, word_len=2,
max_phonemes=0, phoned_word=0x7f7fcc70, traditional=1)
at /usr/local/src/php-5.1.6/ext/standard/metaphone.c:195
#1 0x0049ff40 in zif_metaphone (ht=1, return_value=0x812840,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at /usr/local/src/php-5.1.6/ext/standard/metaphone.c:46
#2 0x00561366 in zend_do_fcall_common_helper_SPEC (
execute_data=0x7f7fce20) at zend_vm_execute.h:200
#3 0x0056493d in ZEND_DO_FCALL_SPEC_CONST_HANDLER (
execute_data=0x7f7fce20) at zend_vm_execute.h:1640
#4 0x00560e6a in execute (op_array=0x783c40) at
zend_vm_execute.h:92
#5 0x0053ddf6 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/local/src/php-5.1.6/Zend/zend.c:1109
#6 0x004eed77 in php_execute_script
(primary_file=0x7f7fe7c0)
at /usr/local/src/php-5.1.6/main/main.c:1737
#7 0x005b1cd7 in main (argc=2, argv=0x7f7fe8c0)
at /usr/local/src/php-5.1.6/sapi/cgi/cgi_main.c:1612
[2006-09-26 17:28:04] [EMAIL PROTECTED]
Please do the following:
#1 fetch http://snaps.php.net/php5.2-200609261630.tar.bz2
#2 extract it
#3 cd into the directory
#4 ./configure --disable-all --enable-debug
#5 make
#6 sapi/cli/php your_test_file.php
[2006-09-26 17:07:51] nikolas dot hagelstein at gmail dot com
it is php -v returns (DEBUG) which indicates that it has been build
with enable-debug:
PHP 5.1.6 (cli) (built: Sep 26 2006 18:33:22) (DEBUG)
[2006-09-26 17:06:29] [EMAIL PROTECTED]
..or your PHP binary is stripped.
Just get the sources, compile them with ./configure --enable-debug
--disable-all and use the sapi/cli/php binary.
[2006-09-26 17:02:49] [EMAIL PROTECTED]
Well, your PHP is built without --enable-debug, that's the fact.
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/38961
--
Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38961 [Opn-Fbk]: Metaphone results in segmentation fault
ID: 38961
Updated by: [EMAIL PROTECTED]
Reported By: nikolas dot hagelstein at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Netbsd 3.0.1 AMD64
PHP Version: 5.1.6
New Comment:
Looks like your libc is broken.
Please type this in gdb after bt:
f 0
p word[w_idx]
p toupper(word[w_idx])
p isalpha(toupper(word[w_idx]))
and paste the output here
Previous Comments:
[2006-09-26 18:17:17] nikolas dot hagelstein at gmail dot com
segfault on 5.1.6 and php5.2-200609261630 same backtrace
[2006-09-26 18:04:20] nikolas dot hagelstein at gmail dot com
sorry folks you have been right it seems as if the pkgsrc process
somehow stripes debug informations :|. Anyway here is what i got using
a native build process and the native sources (without the latest cvs
patch provided by iliaa)
Program received signal SIGSEGV, Segmentation fault.
0x004a00ff in metaphone (word=0x8127c0 ö, word_len=2,
max_phonemes=0, phoned_word=0x7f7fcc70, traditional=1)
at /usr/local/src/php-5.1.6/ext/standard/metaphone.c:195
195 for (; !isalpha(Curr_Letter); w_idx++) {
(gdb) bt
#0 0x004a00ff in metaphone (word=0x8127c0 ö, word_len=2,
max_phonemes=0, phoned_word=0x7f7fcc70, traditional=1)
at /usr/local/src/php-5.1.6/ext/standard/metaphone.c:195
#1 0x0049ff40 in zif_metaphone (ht=1, return_value=0x812840,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at /usr/local/src/php-5.1.6/ext/standard/metaphone.c:46
#2 0x00561366 in zend_do_fcall_common_helper_SPEC (
execute_data=0x7f7fce20) at zend_vm_execute.h:200
#3 0x0056493d in ZEND_DO_FCALL_SPEC_CONST_HANDLER (
execute_data=0x7f7fce20) at zend_vm_execute.h:1640
#4 0x00560e6a in execute (op_array=0x783c40) at
zend_vm_execute.h:92
#5 0x0053ddf6 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/local/src/php-5.1.6/Zend/zend.c:1109
#6 0x004eed77 in php_execute_script
(primary_file=0x7f7fe7c0)
at /usr/local/src/php-5.1.6/main/main.c:1737
#7 0x005b1cd7 in main (argc=2, argv=0x7f7fe8c0)
at /usr/local/src/php-5.1.6/sapi/cgi/cgi_main.c:1612
[2006-09-26 17:28:04] [EMAIL PROTECTED]
Please do the following:
#1 fetch http://snaps.php.net/php5.2-200609261630.tar.bz2
#2 extract it
#3 cd into the directory
#4 ./configure --disable-all --enable-debug
#5 make
#6 sapi/cli/php your_test_file.php
[2006-09-26 17:07:51] nikolas dot hagelstein at gmail dot com
it is php -v returns (DEBUG) which indicates that it has been build
with enable-debug:
PHP 5.1.6 (cli) (built: Sep 26 2006 18:33:22) (DEBUG)
[2006-09-26 17:06:29] [EMAIL PROTECTED]
..or your PHP binary is stripped.
Just get the sources, compile them with ./configure --enable-debug
--disable-all and use the sapi/cli/php binary.
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/38961
--
Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38954 [Opn-Bgs]: PHP cannot connect with MySQL/MySQLi
ID: 38954 Updated by: [EMAIL PROTECTED] Reported By: akaraethon at gmail dot com -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: Windows Server 2003 32bit PHP Version: 5.1.6 New Comment: There is detailed description of what should be done in order to enable MySQL support in PHP: http://php.net/mysql Previous Comments: [2006-09-26 18:08:29] akaraethon at gmail dot com Fine, you are right its not a forum, for some ODD reason I couldnt find even one forum out there devoted to PHP, and If I were a newbie, and not someone who has worked with PHP since PHP2.0 I might agree that I just made a config mistake, but I have, I didnt and I still think this may be some sort of problem with PHP not liking something. [2006-09-26 07:09:11] [EMAIL PROTECTED] Still not PHP problem. And I don't see any reasons to post parts of the docs here, it's not a forum. [2006-09-26 01:31:44] akaraethon at gmail dot com Ok, are you not READING what I write? In my very first post I said I have enabled the DLL file, but PHP will not connect. so why don't we do this, instead of just changing this to bogus (again) lets figure out whats going on, and see if we cant come toan agreement as to the status, if you think its bogus then tell me what to do. [2006-09-25 22:55:25] [EMAIL PROTECTED] www.php.net/mysql MySQL is no longer enabled by default, so the php_mysql.dll DLL must be enabled... [2006-09-25 22:48:05] akaraethon at gmail dot com Well then where is the problem comming from? I HAVE followed ALL the instructions for setup on IIS and MySQL is running fine, so if this isnt a bug then why is it happening? 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/38954 -- Edit this bug report at http://bugs.php.net/?id=38954edit=1
#38965 [Bgs]: mssql_connect doesn't use TCP 1433 for external SQL Server
ID: 38965 User updated by: aren at cambre dot biz Reported By: aren at cambre dot biz Status: Bogus Bug Type: MSSQL related Operating System: Windows 2003 (for both servers) PHP Version: 4.4.4 Assigned To: fmk New Comment: This ntwdblib was on a default installation of Windows Server 2003. Previous Comments: [2006-09-26 17:35:43] [EMAIL PROTECTED] No PHP uses ntwdblib and if you install the Client tools from MSSQL server you can define the default protocol. Older versions of ntwdblib (or combinations of other MS tools installed) uses named pipes as the default. The best way is to install the Client Tools and us the Clinet Network utility to set default protocol as well as create aliases for different servers. Each alias can be defined with the prefered protocol. [2006-09-26 17:25:21] [EMAIL PROTECTED] Frank, is this really a PHP problem? [2006-09-26 17:16:54] aren at cambre dot biz Description: When using mssql_connect to connect to a SQL Server database on a remote server, PHP attemtps to connect using named pipes. This is a terribly outdated behavior; SQL Server connections these days are almost always done with TCP 1433. I figured this out with a difficult phpBB installation and using Wireshark (formerly Ethereal) to watch network traffic. There is a registry hack that can force the SQL Server Client program to use TCP 1433, but this hack's effects on other software is unknown. For more info, see http://people.smu.edu/acambre/blog/2006/09/22/Buggy+PHP.aspx and http://www.phpbb.com/phpBB/viewtopic.php?t=446662postdays=0postorder=ascstart=0 Reproduce code: --- Just use mssql_connect to connect to an external database. Expected result: The database should open just as if the database is on localhost. Actual result: -- Usually a cannot connect error. -- Edit this bug report at http://bugs.php.net/?id=38965edit=1
#38961 [Fbk-Opn]: Metaphone results in segmentation fault
ID: 38961
User updated by: nikolas dot hagelstein at gmail dot com
Reported By: nikolas dot hagelstein at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Netbsd 3.0.1 AMD64
PHP Version: 5.1.6
New Comment:
(gdb) p word[w_idx]
No symbol table is loaded. Use the file command.
seems as if i have to load a symbol table or something, any hints?
Previous Comments:
[2006-09-26 18:18:22] [EMAIL PROTECTED]
Looks like your libc is broken.
Please type this in gdb after bt:
f 0
p word[w_idx]
p toupper(word[w_idx])
p isalpha(toupper(word[w_idx]))
and paste the output here
[2006-09-26 18:17:17] nikolas dot hagelstein at gmail dot com
segfault on 5.1.6 and php5.2-200609261630 same backtrace
[2006-09-26 18:04:20] nikolas dot hagelstein at gmail dot com
sorry folks you have been right it seems as if the pkgsrc process
somehow stripes debug informations :|. Anyway here is what i got using
a native build process and the native sources (without the latest cvs
patch provided by iliaa)
Program received signal SIGSEGV, Segmentation fault.
0x004a00ff in metaphone (word=0x8127c0 ö, word_len=2,
max_phonemes=0, phoned_word=0x7f7fcc70, traditional=1)
at /usr/local/src/php-5.1.6/ext/standard/metaphone.c:195
195 for (; !isalpha(Curr_Letter); w_idx++) {
(gdb) bt
#0 0x004a00ff in metaphone (word=0x8127c0 ö, word_len=2,
max_phonemes=0, phoned_word=0x7f7fcc70, traditional=1)
at /usr/local/src/php-5.1.6/ext/standard/metaphone.c:195
#1 0x0049ff40 in zif_metaphone (ht=1, return_value=0x812840,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at /usr/local/src/php-5.1.6/ext/standard/metaphone.c:46
#2 0x00561366 in zend_do_fcall_common_helper_SPEC (
execute_data=0x7f7fce20) at zend_vm_execute.h:200
#3 0x0056493d in ZEND_DO_FCALL_SPEC_CONST_HANDLER (
execute_data=0x7f7fce20) at zend_vm_execute.h:1640
#4 0x00560e6a in execute (op_array=0x783c40) at
zend_vm_execute.h:92
#5 0x0053ddf6 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/local/src/php-5.1.6/Zend/zend.c:1109
#6 0x004eed77 in php_execute_script
(primary_file=0x7f7fe7c0)
at /usr/local/src/php-5.1.6/main/main.c:1737
#7 0x005b1cd7 in main (argc=2, argv=0x7f7fe8c0)
at /usr/local/src/php-5.1.6/sapi/cgi/cgi_main.c:1612
[2006-09-26 17:28:04] [EMAIL PROTECTED]
Please do the following:
#1 fetch http://snaps.php.net/php5.2-200609261630.tar.bz2
#2 extract it
#3 cd into the directory
#4 ./configure --disable-all --enable-debug
#5 make
#6 sapi/cli/php your_test_file.php
[2006-09-26 17:07:51] nikolas dot hagelstein at gmail dot com
it is php -v returns (DEBUG) which indicates that it has been build
with enable-debug:
PHP 5.1.6 (cli) (built: Sep 26 2006 18:33:22) (DEBUG)
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/38961
--
Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38961 [Opn-Fbk]: Metaphone results in segmentation fault
ID: 38961
Updated by: [EMAIL PROTECTED]
Reported By: nikolas dot hagelstein at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Netbsd 3.0.1 AMD64
PHP Version: 5.1.6
New Comment:
# gdb sapi/cli/php
(gdb) r /path/to/test/script.php
here will be segfault
(gdb) f 0
(gdb) p word[w_idx]
(gdb) p toupper(word[w_idx])
(gdb) p isalpha(toupper(word[w_idx]))
Previous Comments:
[2006-09-26 18:26:08] nikolas dot hagelstein at gmail dot com
(gdb) p word[w_idx]
No symbol table is loaded. Use the file command.
seems as if i have to load a symbol table or something, any hints?
[2006-09-26 18:18:22] [EMAIL PROTECTED]
Looks like your libc is broken.
Please type this in gdb after bt:
f 0
p word[w_idx]
p toupper(word[w_idx])
p isalpha(toupper(word[w_idx]))
and paste the output here
[2006-09-26 18:17:17] nikolas dot hagelstein at gmail dot com
segfault on 5.1.6 and php5.2-200609261630 same backtrace
[2006-09-26 18:04:20] nikolas dot hagelstein at gmail dot com
sorry folks you have been right it seems as if the pkgsrc process
somehow stripes debug informations :|. Anyway here is what i got using
a native build process and the native sources (without the latest cvs
patch provided by iliaa)
Program received signal SIGSEGV, Segmentation fault.
0x004a00ff in metaphone (word=0x8127c0 ö, word_len=2,
max_phonemes=0, phoned_word=0x7f7fcc70, traditional=1)
at /usr/local/src/php-5.1.6/ext/standard/metaphone.c:195
195 for (; !isalpha(Curr_Letter); w_idx++) {
(gdb) bt
#0 0x004a00ff in metaphone (word=0x8127c0 ö, word_len=2,
max_phonemes=0, phoned_word=0x7f7fcc70, traditional=1)
at /usr/local/src/php-5.1.6/ext/standard/metaphone.c:195
#1 0x0049ff40 in zif_metaphone (ht=1, return_value=0x812840,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at /usr/local/src/php-5.1.6/ext/standard/metaphone.c:46
#2 0x00561366 in zend_do_fcall_common_helper_SPEC (
execute_data=0x7f7fce20) at zend_vm_execute.h:200
#3 0x0056493d in ZEND_DO_FCALL_SPEC_CONST_HANDLER (
execute_data=0x7f7fce20) at zend_vm_execute.h:1640
#4 0x00560e6a in execute (op_array=0x783c40) at
zend_vm_execute.h:92
#5 0x0053ddf6 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/local/src/php-5.1.6/Zend/zend.c:1109
#6 0x004eed77 in php_execute_script
(primary_file=0x7f7fe7c0)
at /usr/local/src/php-5.1.6/main/main.c:1737
#7 0x005b1cd7 in main (argc=2, argv=0x7f7fe8c0)
at /usr/local/src/php-5.1.6/sapi/cgi/cgi_main.c:1612
[2006-09-26 17:28:04] [EMAIL PROTECTED]
Please do the following:
#1 fetch http://snaps.php.net/php5.2-200609261630.tar.bz2
#2 extract it
#3 cd into the directory
#4 ./configure --disable-all --enable-debug
#5 make
#6 sapi/cli/php your_test_file.php
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/38961
--
Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38961 [Fbk-Opn]: Metaphone results in segmentation fault
ID: 38961
User updated by: nikolas dot hagelstein at gmail dot com
Reported By: nikolas dot hagelstein at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Netbsd 3.0.1 AMD64
PHP Version: 5.1.6
New Comment:
ah got it i had to run php -e
(gdb) p word[w_idx]
$1 = -61 'Ã'
(gdb) p toupper(word[w_idx])
$2 = 28518
(gdb) p isalpha(toupper(word[w_idx]))
Program received signal SIGSEGV, Segmentation fault.
0x000200e4eced in isalpha () from /usr/lib/libc.so.12
Previous Comments:
[2006-09-26 18:33:44] [EMAIL PROTECTED]
# gdb sapi/cli/php
(gdb) r /path/to/test/script.php
here will be segfault
(gdb) f 0
(gdb) p word[w_idx]
(gdb) p toupper(word[w_idx])
(gdb) p isalpha(toupper(word[w_idx]))
[2006-09-26 18:26:08] nikolas dot hagelstein at gmail dot com
(gdb) p word[w_idx]
No symbol table is loaded. Use the file command.
seems as if i have to load a symbol table or something, any hints?
[2006-09-26 18:18:22] [EMAIL PROTECTED]
Looks like your libc is broken.
Please type this in gdb after bt:
f 0
p word[w_idx]
p toupper(word[w_idx])
p isalpha(toupper(word[w_idx]))
and paste the output here
[2006-09-26 18:17:17] nikolas dot hagelstein at gmail dot com
segfault on 5.1.6 and php5.2-200609261630 same backtrace
[2006-09-26 18:04:20] nikolas dot hagelstein at gmail dot com
sorry folks you have been right it seems as if the pkgsrc process
somehow stripes debug informations :|. Anyway here is what i got using
a native build process and the native sources (without the latest cvs
patch provided by iliaa)
Program received signal SIGSEGV, Segmentation fault.
0x004a00ff in metaphone (word=0x8127c0 ö, word_len=2,
max_phonemes=0, phoned_word=0x7f7fcc70, traditional=1)
at /usr/local/src/php-5.1.6/ext/standard/metaphone.c:195
195 for (; !isalpha(Curr_Letter); w_idx++) {
(gdb) bt
#0 0x004a00ff in metaphone (word=0x8127c0 ö, word_len=2,
max_phonemes=0, phoned_word=0x7f7fcc70, traditional=1)
at /usr/local/src/php-5.1.6/ext/standard/metaphone.c:195
#1 0x0049ff40 in zif_metaphone (ht=1, return_value=0x812840,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at /usr/local/src/php-5.1.6/ext/standard/metaphone.c:46
#2 0x00561366 in zend_do_fcall_common_helper_SPEC (
execute_data=0x7f7fce20) at zend_vm_execute.h:200
#3 0x0056493d in ZEND_DO_FCALL_SPEC_CONST_HANDLER (
execute_data=0x7f7fce20) at zend_vm_execute.h:1640
#4 0x00560e6a in execute (op_array=0x783c40) at
zend_vm_execute.h:92
#5 0x0053ddf6 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/local/src/php-5.1.6/Zend/zend.c:1109
#6 0x004eed77 in php_execute_script
(primary_file=0x7f7fe7c0)
at /usr/local/src/php-5.1.6/main/main.c:1737
#7 0x005b1cd7 in main (argc=2, argv=0x7f7fe8c0)
at /usr/local/src/php-5.1.6/sapi/cgi/cgi_main.c:1612
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/38961
--
Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38954 [Bgs]: PHP cannot connect with MySQL/MySQLi
ID: 38954 User updated by: akaraethon at gmail dot com Reported By: akaraethon at gmail dot com Status: Bogus Bug Type: MySQL related Operating System: Windows Server 2003 32bit PHP Version: 5.1.6 New Comment: wow I NEVER knew that was ther, I mean its not like I EVER have used PHP 5.0 and MySQL together, I mean like whoa who would have thought they worked together? again, as stated in my first post I ALREADY READ THAT! Previous Comments: [2006-09-26 18:20:55] [EMAIL PROTECTED] There is detailed description of what should be done in order to enable MySQL support in PHP: http://php.net/mysql [2006-09-26 18:08:29] akaraethon at gmail dot com Fine, you are right its not a forum, for some ODD reason I couldnt find even one forum out there devoted to PHP, and If I were a newbie, and not someone who has worked with PHP since PHP2.0 I might agree that I just made a config mistake, but I have, I didnt and I still think this may be some sort of problem with PHP not liking something. [2006-09-26 07:09:11] [EMAIL PROTECTED] Still not PHP problem. And I don't see any reasons to post parts of the docs here, it's not a forum. [2006-09-26 01:31:44] akaraethon at gmail dot com Ok, are you not READING what I write? In my very first post I said I have enabled the DLL file, but PHP will not connect. so why don't we do this, instead of just changing this to bogus (again) lets figure out whats going on, and see if we cant come toan agreement as to the status, if you think its bogus then tell me what to do. [2006-09-25 22:55:25] [EMAIL PROTECTED] www.php.net/mysql MySQL is no longer enabled by default, so the php_mysql.dll DLL must be enabled... The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/38954 -- Edit this bug report at http://bugs.php.net/?id=38954edit=1
#38963 [Fbk-Opn]: tempnam bypasses open_basedir
ID: 38963 User updated by: manuel at mausz dot at Reported By: manuel at mausz dot at -Status: Feedback +Status: Open Bug Type: Filesystem function related Operating System: Linux/Gentoo PHP Version: 4.4.4 New Comment: Ok, here is the detailed problem: If tempnam() will be called with an empty string, expand_filepath() (called from php_check_specific_open_basedir()) will expand this string to cwd. The cwd is most probably in open_basedir, so php_check_specific_open_basedir succeeds. tempnam() will then call php_open_temporary_file() which includes an fallback to php_get_temporary_directory(). In most apache setups, php is not able to write to the cwd (cause of safe_mode), so php_open_temporary_file() will fallback. This is not the case when using client, so php -d open_basedir=`pwd` -r 'var_dump(tempnam(false, temp));' works. Previous Comments: [2006-09-26 16:03:30] [EMAIL PROTECTED] Make sure your phpinfo() display the expected value of open_basedir. Turn on display_errors etc. It doesn't depend on the server API in any way. [2006-09-26 15:58:57] manuel at mausz dot at Please try using mod_php. Using the client also don't work for me. Oh and just to be sure: - tried with safe_mode on + off - open_basedir does _not_ include /tmp ;) [2006-09-26 15:30:39] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Cannot reproduce: # ./sapi/cli/php -r 'var_dump(tempnam(false, temp));' Warning: tempnam(): open_basedir restriction in effect. File() is not within the allowed path(s): (/www) in Command line code on line 1 bool(false) [2006-09-26 15:19:47] manuel at mausz dot at Description: tempnam bypasses open_basedir if dir = false Reproduce code: --- ?php $tempfile = tempnam(false, phptest); ? Expected result: Warning: tempnam() [function.tempnam]: open_basedir restriction in effect. File(/tmp) is not within the allowed path(s): (...) in Actual result: -- # ls /tmp/phptest* /tmp/phptestt4mIOa -- Edit this bug report at http://bugs.php.net/?id=38963edit=1
#38965 [Bgs-Opn]: mssql_connect doesn't use TCP 1433 for external SQL Server
ID: 38965 User updated by: aren at cambre dot biz Reported By: aren at cambre dot biz -Status: Bogus +Status: Open Bug Type: MSSQL related Operating System: Windows 2003 (for both servers) PHP Version: 4.4.4 Assigned To: fmk New Comment: Lemme add some more info: The IIS (web) server is a really vanilla Windows Server 2003 box. All that is installed, per Add or Remove Programs, is McAfee VirusScan Enterprise, Microsoft .NET Framework 2.0, PHP 4.4.4, and WMware Tools (it's virtual). I also installed Wireshark 0.99.3 and WinPcap 3.1, but they were installed afte the fact and did not affect the issue. If PHP's SQL Server connect script doesn't work right on a vanilla box, I can't believe this is bogus. SQL Server or SQL Server Client Tools has never been installed on this box. Programs should adhere to industry standard behaviors on vanilla Windows boxes, and industry standard for talking to SQL Server is TCP 1433. If PHP is not doing it, it needs to be fixed or properly documented. It may be as simply as classifying this as a documentation bug and adding documentation that addresses the issue, if that is the proper solution. Previous Comments: [2006-09-26 18:23:45] aren at cambre dot biz This ntwdblib was on a default installation of Windows Server 2003. [2006-09-26 17:35:43] [EMAIL PROTECTED] No PHP uses ntwdblib and if you install the Client tools from MSSQL server you can define the default protocol. Older versions of ntwdblib (or combinations of other MS tools installed) uses named pipes as the default. The best way is to install the Client Tools and us the Clinet Network utility to set default protocol as well as create aliases for different servers. Each alias can be defined with the prefered protocol. [2006-09-26 17:25:21] [EMAIL PROTECTED] Frank, is this really a PHP problem? [2006-09-26 17:16:54] aren at cambre dot biz Description: When using mssql_connect to connect to a SQL Server database on a remote server, PHP attemtps to connect using named pipes. This is a terribly outdated behavior; SQL Server connections these days are almost always done with TCP 1433. I figured this out with a difficult phpBB installation and using Wireshark (formerly Ethereal) to watch network traffic. There is a registry hack that can force the SQL Server Client program to use TCP 1433, but this hack's effects on other software is unknown. For more info, see http://people.smu.edu/acambre/blog/2006/09/22/Buggy+PHP.aspx and http://www.phpbb.com/phpBB/viewtopic.php?t=446662postdays=0postorder=ascstart=0 Reproduce code: --- Just use mssql_connect to connect to an external database. Expected result: The database should open just as if the database is on localhost. Actual result: -- Usually a cannot connect error. -- Edit this bug report at http://bugs.php.net/?id=38965edit=1
#38961 [Opn-Sus]: Metaphone results in segmentation fault
ID: 38961 Updated by: [EMAIL PROTECTED] Reported By: nikolas dot hagelstein at gmail dot com -Status: Open +Status: Suspended Bug Type: Reproducible crash Operating System: Netbsd 3.0.1 AMD64 PHP Version: 5.1.6 New Comment: I've reported it to NetBSD people, lets see what they say about it. Previous Comments: [2006-09-26 18:34:13] nikolas dot hagelstein at gmail dot com ah got it i had to run php -e (gdb) p word[w_idx] $1 = -61 'Ã' (gdb) p toupper(word[w_idx]) $2 = 28518 (gdb) p isalpha(toupper(word[w_idx])) Program received signal SIGSEGV, Segmentation fault. 0x000200e4eced in isalpha () from /usr/lib/libc.so.12 [2006-09-26 18:33:44] [EMAIL PROTECTED] # gdb sapi/cli/php (gdb) r /path/to/test/script.php here will be segfault (gdb) f 0 (gdb) p word[w_idx] (gdb) p toupper(word[w_idx]) (gdb) p isalpha(toupper(word[w_idx])) [2006-09-26 18:26:08] nikolas dot hagelstein at gmail dot com (gdb) p word[w_idx] No symbol table is loaded. Use the file command. seems as if i have to load a symbol table or something, any hints? [2006-09-26 18:18:22] [EMAIL PROTECTED] Looks like your libc is broken. Please type this in gdb after bt: f 0 p word[w_idx] p toupper(word[w_idx]) p isalpha(toupper(word[w_idx])) and paste the output here [2006-09-26 18:17:17] nikolas dot hagelstein at gmail dot com segfault on 5.1.6 and php5.2-200609261630 same backtrace 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/38961 -- Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38961 [Sus]: Metaphone results in segmentation fault
ID: 38961 User updated by: nikolas dot hagelstein at gmail dot com Reported By: nikolas dot hagelstein at gmail dot com Status: Suspended Bug Type: Reproducible crash Operating System: Netbsd 3.0.1 AMD64 PHP Version: 5.1.6 New Comment: (gdb) p word[w_idx] $1 = -61 'Ã' in my native mind this should not result in a negative number. This seems to be related to wider datatypes on 64 bit maschines possible a compiler flag issue ... Previous Comments: [2006-09-26 20:19:01] [EMAIL PROTECTED] I've reported it to NetBSD people, lets see what they say about it. [2006-09-26 18:34:13] nikolas dot hagelstein at gmail dot com ah got it i had to run php -e (gdb) p word[w_idx] $1 = -61 'Ã' (gdb) p toupper(word[w_idx]) $2 = 28518 (gdb) p isalpha(toupper(word[w_idx])) Program received signal SIGSEGV, Segmentation fault. 0x000200e4eced in isalpha () from /usr/lib/libc.so.12 [2006-09-26 18:33:44] [EMAIL PROTECTED] # gdb sapi/cli/php (gdb) r /path/to/test/script.php here will be segfault (gdb) f 0 (gdb) p word[w_idx] (gdb) p toupper(word[w_idx]) (gdb) p isalpha(toupper(word[w_idx])) [2006-09-26 18:26:08] nikolas dot hagelstein at gmail dot com (gdb) p word[w_idx] No symbol table is loaded. Use the file command. seems as if i have to load a symbol table or something, any hints? [2006-09-26 18:18:22] [EMAIL PROTECTED] Looks like your libc is broken. Please type this in gdb after bt: f 0 p word[w_idx] p toupper(word[w_idx]) p isalpha(toupper(word[w_idx])) and paste the output here 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/38961 -- Edit this bug report at http://bugs.php.net/?id=38961edit=1
#38966 [NEW]: file() an external address returns a weird error message
From: dgbauleo at yahoo dot com dot br
Operating system: Windows XP
PHP version: 5.1.6
PHP Bug Type: Filesystem function related
Bug description: file() an external address returns a weird error message
Description:
I'm trying to pass an external link to the file() function, but it returns
a weird error message in portuguese.
Assuming that I live in Brazil, the message in portuguese is not the
problem. What I don't understand is that the code was working, then
suddenly it started to raise the error message.
Reproduce code:
---
?php
$aOrigem = file('http://rss.terra.com.br/0,,EI4795,00.xml');
?
Expected result:
The lines of the file 0,,EI4795,00.xml should be passed as an array to
$aOrigem.
Actual result:
--
I received this error message:
Warning: file(http://rss.terra.com.br/0,,EI4795,00.xml) [function.file]:
failed to open stream: Falha de uma chamada ao sistema que não deveria
falhar nunca. in D:\WebRoot\atualiza_xml.php on line 2
Translating the error message to english:
Fail in a system call which should never have failed.
I don't believe this is a coding issue, since the file is only 1 line
long, and this code was working about 2 hours ago.
--
Edit bug report at http://bugs.php.net/?id=38966edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38966r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38966r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38966r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38966r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38966r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38966r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38966r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38966r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38966r=support
Expected behavior:http://bugs.php.net/fix.php?id=38966r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38966r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38966r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38966r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38966r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38966r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38966r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38966r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38966r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38966r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38966r=mysqlcfg
#38966 [Opn-Bgs]: file() an external address returns a weird error message
ID: 38966
Updated by: [EMAIL PROTECTED]
Reported By: dgbauleo at yahoo dot com dot br
-Status: Open
+Status: Bogus
Bug Type: Filesystem function related
Operating System: Windows XP
PHP Version: 5.1.6
New Comment:
Falha de uma chamada ao sistema que não deveria falhar nunca.
This is what your OS says.
Previous Comments:
[2006-09-26 21:23:21] dgbauleo at yahoo dot com dot br
Description:
I'm trying to pass an external link to the file() function, but it
returns a weird error message in portuguese.
Assuming that I live in Brazil, the message in portuguese is not the
problem. What I don't understand is that the code was working, then
suddenly it started to raise the error message.
Reproduce code:
---
?php
$aOrigem = file('http://rss.terra.com.br/0,,EI4795,00.xml');
?
Expected result:
The lines of the file 0,,EI4795,00.xml should be passed as an array to
$aOrigem.
Actual result:
--
I received this error message:
Warning: file(http://rss.terra.com.br/0,,EI4795,00.xml)
[function.file]: failed to open stream: Falha de uma chamada ao sistema
que não deveria falhar nunca. in D:\WebRoot\atualiza_xml.php on line 2
Translating the error message to english:
Fail in a system call which should never have failed.
I don't believe this is a coding issue, since the file is only 1 line
long, and this code was working about 2 hours ago.
--
Edit this bug report at http://bugs.php.net/?id=38966edit=1
#38956 [Fbk-Opn]: seg fault during array_walk due to reallocated stack
ID: 38956 User updated by: jeannielu at hotmail dot com Reported By: jeannielu at hotmail dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Linux 2.6.16-22 PHP Version: 5.1.6 New Comment: php5.2-latest seems to fix it. Can I obtain a patch for 5.1.6? Will it apply cleanly? Previous Comments: [2006-09-26 07:04:58] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-09-26 01:32:58] judas dot iscariote at gmail dot com Looks as a duplicate of 34066 which is fixed in CVS, and will be in 5.2.0 very soon now :) [2006-09-25 22:41:44] jeannielu at hotmail dot com Description: I reliably get a seg fault during execution of array_walk() in our web application. Unfortunately, the seg fault is not reproducible with any simpler test case. gdb shows the death to be here: #0 zend_call_function (fci=0xbfe8bcf0, fci_cache=0xbfe8bd14) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_execute_API.c:859 859 (*fci-params[i])-refcount++; FYI, the call looks like this: array_walk($current_set, array($this, '_format_traffic_data'), $dd ); Where $current_set is a 2-D array of 10x5 elements, $dd another 2-D array of 2x2 elements. Each element is a string of 10-30 characters. However, I don't think the argument details are important. Valgrind shows that zend_call_function died processing the third argument because it referenced memory freed by zend_ptr_stack.h. See attached backtrace. Actual result: -- gdb: #0 zend_call_function (fci=0xbfe8bcf0, fci_cache=0xbfe8bd14) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_execute_API.c:859 #1 0x081bdb35 in php_array_walk (target_hash=0x90472cc, userdata=0x85ebd6c, recursive=0) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/ext/standard/array.c:1099 #2 0x081bdeaf in zif_array_walk (ht=3, return_value=0x904b69c, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/ext/standard/array.c:1159 #3 0x0826af4d in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe8cbd0) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:200 #4 0x0826a6f1 in execute (op_array=0x894b304) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:92 #5 0x0826a928 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe8df80) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:234 #6 0x0826a6f1 in execute (op_array=0x8b12e34) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:92 #7 0x0826a928 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe8f360) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:234 #8 0x0826a6f1 in execute (op_array=0x8ada67c) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:92 #9 0x0826a928 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe90280) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:234 #10 0x0826a6f1 in execute (op_array=0x8ac0bfc) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:92 #11 0x0826a928 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe92240) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:234 #12 0x0826a6f1 in execute (op_array=0x860b9e0) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:92 #13 0x0826a928 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe923b0) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:234 #14 0x0826a6f1 in execute (op_array=0x85f609c) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:92 #15 0x0825471f in zend_execute_scripts (type=8, retval=Variable retval is not available. ) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend.c:1109 #16 0x0822029c in php_execute_script (primary_file=0xbfe947d4) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/main/main.c:1737 #17 0x082ce8ad in main (argc=5, argv=0xbfe94914) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/sapi/cli/php_cli.c:1093 (gdb) print *fci-params[2] $1 = (zval *) 0x39 valgrind: ==7352== LEAK SUMMARY: ==7352==definitely lost: 0 bytes in 0 blocks. ==7352== possibly lost: 1,088 bytes in 1 blocks. ==7352==still reachable: 49,274 bytes in 568 blocks. ==7352== suppressed: 0 bytes in 0 blocks. ==7352== Reachable blocks (those to which a pointer was found) are not shown. ==7352== To see them,
#38960 [Opn-WFx]: OCI8 failure...
ID: 38960 Updated by: [EMAIL PROTECTED] Reported By: sn4265 at att dot com -Status: Open +Status: Wont fix Bug Type: Compile Failure Operating System: HPUX 11.11 PHP Version: 5.1.6 New Comment: Is this a major change to PHP5? Does it now only work with a more limited set of Oracle clients? Yes, there was a major change in OCI8, which greatly improved its functionality using new features available since Oracle 9. It still does work with Oracle 8 servers, but I don't think it makes sense to keep supporting (seriously) outdated Oracle 8.x clients. The easiest (and the recommended) way to setup a server with OCI8 support is to install Oracle Instant Client, doesn't matter which platform/OS you're using. I guess in your case the solution would be to stick with PHP4/PHP5.0.x. Other options are a bit more complicated: 1) upgrade the client to 9i (afaik instant client doesn't support Oracle 8i) 2) upgrade both Oracle server and client to version = 9. Previous Comments: [2006-09-26 12:34:52] sn4265 at att dot com No clue. I have never used that before. This system has had Oracle 8.0.6.3 on it for years, and has always been what we have built against in the past without any problems. Is this a major change to PHP5? Does it now only work with a more limited set of Oracle clients? [2006-09-26 12:28:49] [EMAIL PROTECTED] Does it work for you with Oracle Instant Client - http://www.oracle.com/technology/tech/oci/instantclient/index.html ? [2006-09-26 12:18:09] sn4265 at att dot com Description: I am attempting to build a working version of Apache 2.0.59 with PHP 5.1.6. I am doing this under HPUX 11.11, and have sucessfully built Apache, and PHP without OCI8 support. The problem is when I attempt to include OCI8 support either in the PHP build directly or by attempting to build the oci8-1.2.2 package after the fact. Here is the attempt buildint OCI8 after the fact. The error is identical when attempting to build PHP with OCI8 support too. Reproduce code: --- [EMAIL PROTECTED]:/www/tmp/oci8-1.2.2 phpize Configuring for: PHP Api Version: 20041225 Zend Module Api No: 20050922 Zend Extension Api No: 220051025 [EMAIL PROTECTED]:/www/tmp/oci8-1.2.2 ./configure checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for a sed that does not truncate output... /usr/bin/sed checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes [EMAIL PROTECTED]:/www/tmp/oci8-1.2.2 make /usr/bin/posix/sh /www/tmp/oci8-1.2.2/libtool --mode=compile gcc -I. -I/www/tmp/oci8-1.2.2 -DPHP_ATOM_INC -I/www/tmp/oci8-1.2.2/include -I/www/tmp/oci8-1.2.2/main -I/www/tmp/oci8-1.2.2 -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -I/usr/local/include/php/ext -I/usr/local/oracle/8.0.6.3/rdbms/demo -I/usr/local/oracle/8.0.6.3/network/public -DHAVE_CONFIG_H -g -O2 -c /www/tmp/oci8-1.2.2/oci8.c -o oci8.lo mkdir .libs gcc -I. -I/www/tmp/oci8-1.2.2 -DPHP_ATOM_INC -I/www/tmp/oci8-1.2.2/include -I/www/tmp/oci8-1.2.2/main -I/www/tmp/oci8-1.2.2 -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -I/usr/local/include/php/ext -I/usr/local/oracle/8.0.6.3/rdbms/demo -I/usr/local/oracle/8.0.6.3/network/public -DHAVE_CONFIG_H -g -O2 -c /www/tmp/oci8-1.2.2/oci8.c -fPIC -DPIC -o .libs/oci8.o /www/tmp/oci8-1.2.2/oci8.c: In function `php_oci_connection_status': /www/tmp/oci8-1.2.2/oci8.c:1429: error: `OCI_ATTR_SERVER_STATUS' undeclared (first use in this function) /www/tmp/oci8-1.2.2/oci8.c:1429: error: (Each undeclared identifier is reported only once /www/tmp/oci8-1.2.2/oci8.c:1429: error: for each function it appears in.) /www/tmp/oci8-1.2.2/oci8.c:1431: error: `OCI_SERVER_NORMAL' undeclared (first use in this function) *** Error exit code 1 Stop. Expected result: Return a sucessful build. Actual result: -- /www/tmp/oci8-1.2.2/oci8.c: In function `php_oci_connection_status': /www/tmp/oci8-1.2.2/oci8.c:1429: error: `OCI_ATTR_SERVER_STATUS' undeclared (first use in this function) /www/tmp/oci8-1.2.2/oci8.c:1429: error: (Each undeclared identifier is reported only once /www/tmp/oci8-1.2.2/oci8.c:1429: error: for each function it appears in.) /www/tmp/oci8-1.2.2/oci8.c:1431: error: `OCI_SERVER_NORMAL' undeclared (first use in this function) *** Error exit code 1 Stop. -- Edit this bug report at http://bugs.php.net/?id=38960edit=1
#38956 [Opn-Csd]: seg fault during array_walk due to reallocated stack
ID: 38956 Updated by: [EMAIL PROTECTED] Reported By: jeannielu at hotmail dot com -Status: Open +Status: Closed Bug Type: Reproducible crash Operating System: Linux 2.6.16-22 PHP Version: 5.1.6 New Comment: Fixed - closed. I don't think it makes sense to backport a patch from a release candidate to the previous release. Just wait for a couple of weeks for the release. Previous Comments: [2006-09-26 22:01:42] jeannielu at hotmail dot com php5.2-latest seems to fix it. Can I obtain a patch for 5.1.6? Will it apply cleanly? [2006-09-26 07:04:58] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-09-26 01:32:58] judas dot iscariote at gmail dot com Looks as a duplicate of 34066 which is fixed in CVS, and will be in 5.2.0 very soon now :) [2006-09-25 22:41:44] jeannielu at hotmail dot com Description: I reliably get a seg fault during execution of array_walk() in our web application. Unfortunately, the seg fault is not reproducible with any simpler test case. gdb shows the death to be here: #0 zend_call_function (fci=0xbfe8bcf0, fci_cache=0xbfe8bd14) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_execute_API.c:859 859 (*fci-params[i])-refcount++; FYI, the call looks like this: array_walk($current_set, array($this, '_format_traffic_data'), $dd ); Where $current_set is a 2-D array of 10x5 elements, $dd another 2-D array of 2x2 elements. Each element is a string of 10-30 characters. However, I don't think the argument details are important. Valgrind shows that zend_call_function died processing the third argument because it referenced memory freed by zend_ptr_stack.h. See attached backtrace. Actual result: -- gdb: #0 zend_call_function (fci=0xbfe8bcf0, fci_cache=0xbfe8bd14) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_execute_API.c:859 #1 0x081bdb35 in php_array_walk (target_hash=0x90472cc, userdata=0x85ebd6c, recursive=0) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/ext/standard/array.c:1099 #2 0x081bdeaf in zif_array_walk (ht=3, return_value=0x904b69c, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/ext/standard/array.c:1159 #3 0x0826af4d in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe8cbd0) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:200 #4 0x0826a6f1 in execute (op_array=0x894b304) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:92 #5 0x0826a928 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe8df80) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:234 #6 0x0826a6f1 in execute (op_array=0x8b12e34) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:92 #7 0x0826a928 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe8f360) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:234 #8 0x0826a6f1 in execute (op_array=0x8ada67c) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:92 #9 0x0826a928 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe90280) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:234 #10 0x0826a6f1 in execute (op_array=0x8ac0bfc) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:92 #11 0x0826a928 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe92240) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:234 #12 0x0826a6f1 in execute (op_array=0x860b9e0) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:92 #13 0x0826a928 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe923b0) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:234 #14 0x0826a6f1 in execute (op_array=0x85f609c) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend_vm_execute.h:92 #15 0x0825471f in zend_execute_scripts (type=8, retval=Variable retval is not available. ) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/Zend/zend.c:1109 #16 0x0822029c in php_execute_script (primary_file=0xbfe947d4) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/main/main.c:1737 #17 0x082ce8ad in main (argc=5, argv=0xbfe94914) at /usr/src/redhat/SOURCES/mazu/apache/php-5.1.6/sapi/cli/php_cli.c:1093 (gdb) print *fci-params[2] $1 = (zval *) 0x39 valgrind: ==7352== LEAK SUMMARY: ==7352==definitely lost: 0 bytes
#38961 [Sus-Fbk]: Metaphone results in segmentation fault
ID: 38961 Updated by: [EMAIL PROTECTED] Reported By: nikolas dot hagelstein at gmail dot com -Status: Suspended +Status: Feedback Bug Type: Reproducible crash Operating System: Netbsd 3.0.1 AMD64 PHP Version: 5.1.6 New Comment: Please apply this to the snapshot: http://tony2001.phpclub.net/dev/tmp/bug38961.diff Does this patch fix it for you? Previous Comments: [2006-09-26 20:30:30] nikolas dot hagelstein at gmail dot com (gdb) p word[w_idx] $1 = -61 'Ã' in my native mind this should not result in a negative number. This seems to be related to wider datatypes on 64 bit maschines possible a compiler flag issue ... [2006-09-26 20:19:01] [EMAIL PROTECTED] I've reported it to NetBSD people, lets see what they say about it. [2006-09-26 18:34:13] nikolas dot hagelstein at gmail dot com ah got it i had to run php -e (gdb) p word[w_idx] $1 = -61 'Ã' (gdb) p toupper(word[w_idx]) $2 = 28518 (gdb) p isalpha(toupper(word[w_idx])) Program received signal SIGSEGV, Segmentation fault. 0x000200e4eced in isalpha () from /usr/lib/libc.so.12 [2006-09-26 18:33:44] [EMAIL PROTECTED] # gdb sapi/cli/php (gdb) r /path/to/test/script.php here will be segfault (gdb) f 0 (gdb) p word[w_idx] (gdb) p toupper(word[w_idx]) (gdb) p isalpha(toupper(word[w_idx])) [2006-09-26 18:26:08] nikolas dot hagelstein at gmail dot com (gdb) p word[w_idx] No symbol table is loaded. Use the file command. seems as if i have to load a symbol table or something, any hints? 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/38961 -- Edit this bug report at http://bugs.php.net/?id=38961edit=1
#37766 [Opn-Fbk]: include_once() adds file more than one time
ID: 37766
Updated by: [EMAIL PROTECTED]
Reported By: boris_k at iname dot com
-Status: Open
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: win2000
PHP Version: 5CVS-2006-06-09 (snap)
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
Previous Comments:
[2006-06-09 15:37:05] boris_k at iname dot com
Description:
File inc/test3.inc included in code more then one time.
php is module of apache 2.2
php.ihi is here http://bdr.kiev.ua/tmpboris/php.ini till some time.
ICQ 176869864
Good luck!
Reproduce code:
---
File test.php
?php
include_once('inc/test3.inc'); // it have to print array
include_once('inc/test3.inc'); // no output
include_once('inc/test3.inc'); // no output
include_once ('inc/test2.inc'); //
?
File inc/test2.inc
?php include_once (test3.inc); ?
File inc/test3.inc
?php
echo file inc/file3.inc\n;
print_r(get_included_files ( ));
?
Expected result:
file inc/file3.inc
Array
(
[0] = C:\tmp\bdr\html\php\test.php
[1] = C:\tmp\bdr\html\php\inc\test3.inc
)
Actual result:
--
file inc/file3.inc
Array
(
[0] = C:\tmp\bdr\html\php\test.php
[1] = C:\tmp\bdr\html\php\inc\test3.inc
)
file inc/file3.inc
Array
(
[0] = C:\tmp\bdr\html\php\test.php
[1] = C:\tmp\bdr\html\php\inc\test3.inc
[2] = C:\tmp\bdr\html\php\inc\test2.inc
[3] = c:\tmp\bdr\html\php\inc\test3.inc
)
--
Edit this bug report at http://bugs.php.net/?id=37766edit=1
#37350 [Opn-Fbk]: realpath() doesn't canonicalize case on Windows
ID: 37350
Updated by: [EMAIL PROTECTED]
Reported By: k95vz5f02 at sneakemail dot com
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: Windows XP SP2
PHP Version: 5.1.4
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
Previous Comments:
[2006-06-23 17:19:53] k95vz5f02 at sneakemail dot com
On further investigation, realpath doesn't consistently canonicalize
the case at all on Windows, I've updated the summary accordingly.
First to remember the need for this: the documentation definition for
realpath is Returns canonicalized absolute pathname, and Wikipedia
defines canonicalization as
Canonicalization (abbreviated c14n) is the process of converting data
that has more than one possible representation into a standard
canonical representation. This can be done to compare different
representations for equivalence (...)
So clearly case should be converted to a standard form on platforms
such as Windows that are case-insensitive, and indeed Windows stores
the preferred case for every file, for example the standard directory
'C:\Program Files' should be capitalised like that, rather than, e.g.
'C:\program files' or 'C:\PROGRAM FILES', whereas 'C:\WINDOWS' is the
preferred case for that directory (on Win XP at least).
Tests:
1. realpath(C:\\Program Files) = C:\Program Files
2. realpath(c:\\PrOgRaM fIlEs) = c:\PrOgRaM fIlEs
3. realpath(C:\\program files\\) = C:\program files
4. realpath(C:/program files/) = C:\program files
5. realpath(C:\\pRoGrA~1)= C:\Program Files
6. realpath(c:\\windows) = c:\WINDOWS
7. realpath(c:\\wInDoWs\\DoWnLoAdEd PrOgRaM fIlEs\\) =
c:\WINDOWS\DoWnLoAdEd PrOgRaM fIlEs
Conclusion:
realpath deals with slashes consistently, but it only canonicalizes the
case of short filenames (as well as expanding them), not long file names
(anything more than 8.3, or with a space, etc); and it never capitalizes
the drive letter as it should.
A possible solution, if slightly inefficient, would be to convert path
components into short (8.3) form then apply the normal realpath logic.
[2006-06-23 11:13:39] hanskrentel at yahoo dot de
within the windows OS there is no difference between cAsE in filenames,
a solution might be to read out the actual filename from the system and
return it by realpath.
but this won't be a valid solution afterall: next to case ignorance,
there are two filenames for a file as well: the long and the short
(8.3) one (since win/32/95 or FAT 32). so i guess a comparison will
fail in that case anyway.
additionally, for me another problem occurs:
c:\windows is a directory and could be name as c:\windows\ as well (in
my opinion it even should but that's my personal opinion anyway).
since for me there is no logical correct solution for this problem
anyway I would suggest to handle the windows filesystem more similar to
the *nix one, that meaning using / instead of \ for example to point to
directories with the needed / at the end. additionally, a virtual root
might be good idea as well sothat c:\windows would be /c:/windows/
afterall. this would help developers to create better cross platform
code. this might be already discussed somewhere else maybe.
[2006-05-07 18:41:58] [EMAIL PROTECTED]
Realpath is also used internally for f.e. include_once, so this should
be looked into.
[2006-05-07 18:08:28] k95vz5f02 at sneakemail dot com
Description:
The realpath function doesn't canonicalize the case of the drive letter
on Windows (and possibly on certain other platforms).
For example:
realpath('C:\WINDOWS') returns 'C:\WINDOWS'
but realpath('c:\WINDOWS') returns 'c:\WINDOWS'
(note the different case of the 'C:')
Hence comparing realpaths cannot reliably be used to check that two
files are the same on Windows.
Reproduce code:
---
echo (realpath('C:\WINDOWS')==realpath('c:\WINDOWS')) ? true :
false;
Expected result:
true
Actual result:
--
false
--
Edit this bug report at http://bugs.php.net/?id=37350edit=1
#37239 [Opn-Fbk]: Regxp couses PHP script crach on Windows
ID: 37239 Updated by: [EMAIL PROTECTED] Reported By: dimox at inbox dot lv -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Windows XP Pro SP2 PHP Version: 4.4.4 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip It looks pretty much like a problem of PCRELib, but I can't tell anything for sure without a backtrace. Previous Comments: [2006-09-21 08:37:04] dimox at inbox dot lv Version 4.4.4 still has this problem :( If I run this script on version 4.3.11 (and other 4.3.x versions) - all works fine, but version 4.4.0 and all versions after it has this bug (on Windows! not Linux). [2006-06-01 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-05-15 21:34:38] beagle-php at sector99 dot com I have confirmed this problem on another box, this one running XPSP2 / IIS like the original poster. I don't have a Linux environment with 4.4.2 on it to test that but I hope to shortly. I can try running a trace but I'm a total noob with that kind of stuff. I don't see a debug version of PHP 4.4.2 on the snaps page -- just one for 5.x and 6.x. I tried using the Win32 debug download as referenced in bug #37188 (see 25 Apr) but couldn't get it to work. Any suggestions where to get a debug version? Thanks for your help! [2006-05-15 21:26:43] dimox at inbox dot lv Yes, its works on Linux. This bug is Windows only. On Apache/1.3.29 (Win32) PHP/4.3.10 this code works fine too. What information I can provide, except backtrace? [2006-05-14 12:28:11] [EMAIL PROTECTED] Works perfectly fine on Linux. Please provide more information. 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/37239 -- Edit this bug report at http://bugs.php.net/?id=37239edit=1
#37103 [Opn-Asn]: libmbfl headers not installed
ID: 37103 Updated by: [EMAIL PROTECTED] Reported By: Fedora at FamilleCollet dot com -Status: Open +Status: Assigned Bug Type: mbstring related Operating System: Linux (Fedora) PHP Version: 5.1.6 -Assigned To: +Assigned To: hirokawa New Comment: Assigned to the maintainer. Previous Comments: [2006-09-19 16:26:40] Fedora at FamilleCollet dot com For php-5.2.0 I don't understand permissions on ext/mbstring/libmbfl/mbfl/mbfl_defs.h (rwxr-xr-x) while other headers are rw-r--r-- I think the '*' in the config.m4 file is the problem. So i change my previous patch to simply remove it and the packaging is complete with all the headers (and mailparse pecl extension build fine). --- ext/mbstring/config.m4.orig 2006-09-18 17:46:08.0 +0200 +++ ext/mbstring/config.m4 2006-09-18 17:47:08.0 +0200 @@ -302,7 +302,7 @@ dnl libmbfl is required PHP_MBSTRING_SETUP_LIBMBFL PHP_MBSTRING_EXTENSION - PHP_INSTALL_HEADERS([ext/mbstring], [libmbfl/config.h libmbfl/mbfl/eaw_table.h libmbfl/mbfl/mbfilter.h libmbfl/mbfl/mbfilter_8bit.h libmbfl/mbfl/mbfilter_pass.h libmbfl/mbfl/mbfilter_wchar.h libmbfl/mbfl/mbfl_allocators.h libmbfl/mbfl/mbfl_consts.h libmbfl/mbfl/mbfl_convert.h libmbfl/mbfl/mbfl_defs.h* libmbfl/mbfl/mbfl_encoding.h libmbfl/mbfl/mbfl_filter_output.h libmbfl/mbfl/mbfl_ident.h libmbfl/mbfl/mbfl_language.h libmbfl/mbfl/mbfl_memory_device.h libmbfl/mbfl/mbfl_string.h ]) + PHP_INSTALL_HEADERS([ext/mbstring], [libmbfl/config.h libmbfl/mbfl/eaw_table.h libmbfl/mbfl/mbfilter.h libmbfl/mbfl/mbfilter_8bit.h libmbfl/mbfl/mbfilter_pass.h libmbfl/mbfl/mbfilter_wchar.h libmbfl/mbfl/mbfl_allocators.h libmbfl/mbfl/mbfl_consts.h libmbfl/mbfl/mbfl_convert.h libmbfl/mbfl/mbfl_defs.h libmbfl/mbfl/mbfl_encoding.h libmbfl/mbfl/mbfl_filter_output.h libmbfl/mbfl/mbfl_ident.h libmbfl/mbfl/mbfl_language.h libmbfl/mbfl/mbfl_memory_device.h libmbfl/mbfl/mbfl_string.h ]) fi # vim600: sts=2 sw=2 et [2006-09-18 15:55:09] Fedora at FamilleCollet dot com Still present in php-5.1.6 (only half corrected) Patch : --- ext/mbstring/config.m4.orig 2006-07-24 18:07:44.0 +0200 +++ ext/mbstring/config.m4 2006-07-24 18:08:03.0 +0200 @@ -293,7 +293,7 @@ dnl libmbfl is required PHP_MBSTRING_SETUP_LIBMBFL PHP_MBSTRING_EXTENSION - PHP_INSTALL_HEADERS([ext/mbstring], [libmbfl/ libmbfl/mbfl]) + PHP_INSTALL_HEADERS([ext/mbstring], [libmbfl/ libmbfl/mbfl/]) fi # vim600: sts=2 sw=2 et Even present in php-5.2.0RC5-dev (missing only one file : mbfl_defs.h) Patch : --- ext/mbstring/config.m4.orig 2006-09-18 17:46:08.0 +0200 +++ ext/mbstring/config.m4 2006-09-18 17:47:08.0 +0200 @@ -302,7 +302,7 @@ dnl libmbfl is required PHP_MBSTRING_SETUP_LIBMBFL PHP_MBSTRING_EXTENSION - PHP_INSTALL_HEADERS([ext/mbstring], [libmbfl/config.h libmbfl/mbfl/eaw_table.h libmbfl/mbfl/mbfilter.h libmbfl/mbfl/mbfilter_8bit.h libmbfl/mbfl/mbfilter_pass.h libmbfl/mbfl/mbfilter_wchar.h libmbfl/mbfl/mbfl_allocators.h libmbfl/mbfl/mbfl_consts.h libmbfl/mbfl/mbfl_convert.h libmbfl/mbfl/mbfl_defs.h* libmbfl/mbfl/mbfl_encoding.h libmbfl/mbfl/mbfl_filter_output.h libmbfl/mbfl/mbfl_ident.h libmbfl/mbfl/mbfl_language.h libmbfl/mbfl/mbfl_memory_device.h libmbfl/mbfl/mbfl_string.h ]) + PHP_INSTALL_HEADERS([ext/mbstring], [libmbfl/ libmbfl/mbfl/]) fi # vim600: sts=2 sw=2 et [2006-04-17 22:14:35] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2006-04-17 12:07:35] Fedora at FamilleCollet dot com Here is the little patch i use witch solve the problem Hope this help. --- ext/mbstring/config.m4.orig 2006-04-17 12:41:13.0 +0200 +++ ext/mbstring/config.m4 2006-04-17 12:42:55.0 +0200 @@ -293,7 +293,7 @@ dnl libmbfl is required PHP_MBSTRING_SETUP_LIBMBFL PHP_MBSTRING_EXTENSION - PHP_INSTALL_HEADERS([ext/mbstring], [libmbfl libmbfl/mbfl]) + PHP_INSTALL_HEADERS([ext/mbstring], [libmbfl/ libmbfl/mbfl/]) fi # vim600: sts=2 sw=2 et [2006-04-17 12:05:14] Fedora at FamilleCollet dot com Description: make install doesn't install headers of libmbfl in /usr/include/php/ext/mbstring/libmbfl/ They are required to build somme PECL extensions. For exemple mailparse, see bug #36136. Reproduce code: --- find /usr/include/php/ext/mbstring/ -name \*.h Expected result:
#37074 [Opn-Fbk]: pclose returns -1 (some times)
ID: 37074
Updated by: [EMAIL PROTECTED]
Reported By: mauroi at digbang dot com
-Status: Open
+Status: Feedback
Bug Type: Program Execution
Operating System: CentOS release 4.2
PHP Version: 5.1.2
New Comment:
Not reproducible.
Previous Comments:
[2006-04-18 21:49:49] mauroi at digbang dot com
With the new version I can't get anything in output.
And with sigchild it always returns -1, and without it returns 0.
Thanks in advance.
[2006-04-13 19:30:18] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-04-13 19:28:29] mauroi at digbang dot com
Forgot to mention.
I doesn't happen in Windows.
[2006-04-13 19:26:59] mauroi at digbang dot com
Description:
With the following script (in CLI), sometimes I get -1 and sometimes 0.
The report it's very similar to #8992, but with proc_close.
With out withoud --enable-sigchild.
Thanks in advance.
Reproduce code:
---
?
$cmd = ls;
if ($process = popen($command, 'r'))
{
$output = stream_get_contents($process);
$returnCode = pclose($process);
}
echo $returnCode . \n;
?
Expected result:
0
Actual result:
--
-1
--
Edit this bug report at http://bugs.php.net/?id=37074edit=1
