#43680 [NEW]: OnUpdateUTF8String problems in PHP 6
From: christopher dot jones at oracle dot com Operating system: n/a PHP version: 6CVS-2007-12-26 (CVS) PHP Bug Type: Unicode Engine related Bug description: OnUpdateUTF8String problems in PHP 6 Description: Problem reported to me as: The problems I faced when unicode.semantics=On were: 1) Any OnUpdateUTF8String php.ini variable is seen as NULL in oci_globals. 2) If the above is resolved, the memory of the variable is wiped out, by the time we come to execution of the script, after module inits. 3) We still convert to UTF-16 when unicode.semantics=Off. Patch is in: http://news.php.net/php.internals/32817 Andrei was OK with the change: http://news.php.net/php.internals/32949 -- Edit bug report at http://bugs.php.net/?id=43680edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43680r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43680r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43680r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43680r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43680r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43680r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43680r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43680r=needscript Try newer version:http://bugs.php.net/fix.php?id=43680r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43680r=support Expected behavior:http://bugs.php.net/fix.php?id=43680r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43680r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43680r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43680r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43680r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43680r=dst IIS Stability:http://bugs.php.net/fix.php?id=43680r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43680r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43680r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43680r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43680r=mysqlcfg
#43681 [NEW]: PDO-ODBC crashes unixODBC due to not binding columns on long data
From: bugs dot php dot net at zetafleet dot com
Operating system: Linux (Ubuntu 7.04)
PHP version: 5.2.5
PHP Bug Type: Reproducible crash
Bug description: PDO-ODBC crashes unixODBC due to not binding columns on
long data
Description:
PDO-ODBC causes unixODBC to crash when fetching data because it does not
bind all the columns in odbc_stmt.c if there are long (data 256b)
columns, resulting in a NULL pointer dereference in unixODBC at
SQLGetData:472 (line number is for the current CVS version of unixODBC;
release versions may differ. The line is bound_columns = bound_columns -
next).
The affected code may be odbc_stmt.c:422-439. I have solved the crash by
commenting out the branch, but this is not the correct solution since it
will now potentially allocate a huge amount of memory.
Reproduce code:
---
Create a table in MSSQL like:
CREATE TABLE Frontpage (
ID smallint identity,
Title nvarchar,
SectionUpdate text,
Category nvarchar,
Date smalldatetime,
Link nvarchar );
?php
$pdo = new PDO('odbc:NewMain', 'imageboston', 'ib86385');
$stmt = $pdo-query('SELECT * FROM Frontpage');
$result = $stmt-fetchAll(PDO::FETCH_NUM);
echo count($result);
?
Expected result:
42 (or however many rows are in the table)
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47223378858528 (LWP 14883)]
0x2af315aa93e4 in CLGetData (statement_handle=0xe34f00,
column_number=3, target_type=1, target_value=0xdca8f0, buffer_length=256,
strlen_or_ind=0xdd0420) at SQLGetData.c:472
472 bound_columns = bound_columns - next;
(gdb) bt
#0 0x2af315aa93e4 in CLGetData (statement_handle=0xe34f00,
column_number=3, target_type=1, target_value=0xdca8f0, buffer_length=256,
strlen_or_ind=0xdd0420)
at SQLGetData.c:472
#1 0x2af312debb4e in SQLGetData (statement_handle=0xe34880,
column_number=3, target_type=1, target_value=0xdca8f0, buffer_length=256,
strlen_or_ind=0xdd0420)
at SQLGetData.c:439
#2 0x2af3138eacd7 in odbc_stmt_get_col (stmt=0xdcfe00, colno=2,
ptr=0x7fffa10faa38, len=0x7fffa10faa30, caller_frees=0x7fffa10faa90)
at
/home/colin/software/source/php5-5.2.1/ext/pdo_odbc/odbc_stmt.c:460
#3 0x2af313068c35 in fetch_value (stmt=0xdcfe00, dest=0xdd1370,
colno=2, type_override=0x0) at
/home/colin/software/source/php5-5.2.1/ext/pdo/pdo_stmt.c:512
#4 0x2af31306a2d9 in do_fetch (stmt=0xdcfe00, do_bind=1,
return_value=0xdd1180, how=PDO_FETCH_NUM, ori=PDO_FETCH_ORI_NEXT, offset=0,
return_all=0x0)
at /home/colin/software/source/php5-5.2.1/ext/pdo/pdo_stmt.c:1017
#5 0x2af31306b9fa in zim_PDOStatement_fetchAll (ht=1,
return_value=0xdcf9b8, return_value_ptr=0x0, this_ptr=0xdcf9e0,
return_value_used=1)
at /home/colin/software/source/php5-5.2.1/ext/pdo/pdo_stmt.c:1494
#6 0x00676642 in ?? ()
#7 0x00666cac in execute ()
#8 0x00647cd3 in zend_execute_scripts ()
#9 0x00606288 in php_execute_script ()
#10 0x006d0960 in main ()
(Please ignore the source version; this problem exists also in 5.2.5
(pdo_odbc hasn't changed) -- I just happened to compile with full debug
information for 5.2.1-0ubuntu1.5.)
--
Edit bug report at http://bugs.php.net/?id=43681edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43681r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43681r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43681r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43681r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43681r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43681r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43681r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43681r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43681r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43681r=support
Expected behavior:http://bugs.php.net/fix.php?id=43681r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43681r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43681r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43681r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43681r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43681r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43681r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43681r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43681r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43681r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43681r=mysqlcfg
#43682 [NEW]: session id kept, content lost on subdomain
From: k dot andris at gmail dot com Operating system: Debian Sarge PHP version: 5.2.5 PHP Bug Type: Session related Bug description: session id kept, content lost on subdomain Description: The $_SESSION variable is empty when I look at it on a subdomain (abc.mydomain.com) even though session_id() is the same as on the main site (mydomain.com). Sessions are saved in files under /var/log/php5 - they just not read from there. The session cookie is OK too. Reproduce code: --- I have this on the base domain and on subdoamins too with different assigment lines. Still, they only seee their own assigments. ini_set(session.cookie_domain, .mydomain.net); session_start(); print_r($_SESSION); $_SESSION['main'] = 'main'; // assigment print_r($_SESSION); Expected result: Since I have the same session id, I expect the $_SESSION variable to be shared acreoss pages, and subdomains. -- Edit bug report at http://bugs.php.net/?id=43682edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43682r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43682r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43682r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43682r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43682r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43682r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43682r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43682r=needscript Try newer version:http://bugs.php.net/fix.php?id=43682r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43682r=support Expected behavior:http://bugs.php.net/fix.php?id=43682r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43682r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43682r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43682r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43682r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43682r=dst IIS Stability:http://bugs.php.net/fix.php?id=43682r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43682r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43682r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43682r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43682r=mysqlcfg
#43105 [Opn]: PHP seems to fail to close open files.
ID: 43105 Updated by: [EMAIL PROTECTED] Reported By: ian at onlineloop dot com Status: Open Bug Type: Apache2 related Operating System: Solaris, Linux, Mac OS X PHP Version: 5.2.5RC2-dev New Comment: I can't reproduce the bug in PHP 5.1.6 on Darwin Kernel Version 8.11.1, which makes me think its an issue of 5.2.5 only. Previous Comments: [2007-12-23 14:08:14] [EMAIL PROTECTED] Apache 1.3.33 and PHP 5.2.5 running on Darwin Kernel Version 8.11.1 (Mac OS X 10.4.11) compiled with configure command (gcc): './configure' '--prefix=/usr/local' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-apxs' '--with-kerberos' '--enable-cli' '--enable-exif' '--enable-ftp' '--enable-mbstring' '--enable-mbregex' '--enable-sockets' '--with-curl' '--with-config-file-path=/private/etc' '--sysconfdir=/private/etc' '--with-mysql=/usr/local/mysql' '--with-mysql-sock=/tmp/mysql.sock' '--without-pear' '--with-gd' '--enable-gd-native-ttf' '--with-png-dir' '--with-zlib' '--with-bz2' '--with-libxml-dir' '--with-mysqli=/usr/local/mysql/bin/mysql_config' '--enable-sqlite-utf8' '--enable-zip' '--disable-cgi' doesn't seems to be closing open files (requires, includes etc.) which ends up with the error Too many open files very often. # apachectl restart # lsof -u www | wc -l 56 # lsof -u www | grep \.php | wc -l no output After running one PHP script: # lsof -u www | grep \.php | wc -l 22 Another page hit: # lsof -u www | grep \.php | wc -l 104 And so on... The number of open files just keeps increasing. For some reason PHP 4.4.7 don't have this behavior, that is, apache keeps the number of open files somewhat constant when PHP is not running. For phpMyAdmin the first entries of lsof looks like: # lsof -u www | grep \.php | head httpd 678 www6r REG 14,226700 915904 /Users/data/htdocs/mysql/libraries/common.inc.php httpd 678 www7r REG 14,218504 915886 /Users/data/htdocs/mysql/libraries/core.lib.php httpd 678 www8r REG 14,2 2063 915950 /Users/data/htdocs/mysql/libraries/sanitizing.lib.php httpd 678 www9r REG 14,2 9447 915968 /Users/data/htdocs/mysql/libraries/Theme.class.php httpd 678 www 10r REG 14,210571 915906 /Users/data/htdocs/mysql/libraries/Theme_Manager.class.php httpd 678 www 11r REG 14,2 9447 915968 /Users/data/htdocs/mysql/libraries/Theme.class.php httpd 678 www 12r REG 14,233846 915974 /Users/data/htdocs/mysql/libraries/Config.class.php httpd 678 www 13r REG 14,244257 915868 /Users/data/htdocs/mysql/libraries/Table.class.php httpd 678 www 14r REG 14,279607 915957 /Users/data/htdocs/mysql/libraries/common.lib.php httpd 678 www 18r REG 14,2 1919 915824 /Users/data/htdocs/mysql/libraries/js_escape.lib.php [2007-11-29 16:03:43] marcus dot mueller at grintsch dot com As I stated above we have this issue on two Linux boxes with self-compiled PHP binaries. These were compiled using gcc! [2007-11-28 16:36:24] ian at onlineloop dot com Coming back to the bug report here now. In the meantime some private emails were exchanged, including a pfiles output from Solaris showing that PHP had over 210,000 open files after 24 hours running on our servers. Within 48 hours (we let it go this far onyl once), apache/php eats around 12Gb of RAM and has between 170 and 220 child processes with over 230,000 open files. Under 5.1.6 the usage is more around 1.5-2Gb ram, and 30-70 child processes, with rarely more than 100 open files (only when we are really under load do we get to more than about 800 open files at any one time). A small patch was sent to me to try, however this has changed nothing. I was also asked to compile with gcc if possible, however this is not feasible as too many other things would have to be recompiled. Besides, we specifically went away from gcc because everything we had that was compiled with gcc was seg faulting all the time, however with the Sun Studio compiler suite, everything is stable. I seriously doubt this is an apache bug, why were things working with previous versions of PHP, and not this one? [2007-11-28 15:02:11] grknight at iwon dot com I am also experiencing this issue. We are running Apache 2.2.3 on Redhat EL 3 and recently tried to update to 5.2.5 from 5.2.3 to fix the security issues. The moment 5.2.5 was activated, connections failed to close in apache and resulted in hung processes. I also tried 5.2.4 with the same results. No configurations were changed nor PHP scripts. Something changed in the PHP processes that
#43105 [Opn]: PHP seems to fail to close open files.
ID: 43105 Updated by: [EMAIL PROTECTED] Reported By: ian at onlineloop dot com Status: Open Bug Type: Apache2 related Operating System: Solaris, Linux, Mac OS X PHP Version: 5.2.5RC2-dev New Comment: I did some more tests: PHP 4.4.7: couldn't reproduce PHP 5.1.6: couldn't reproduce PHP 5.2.4: couldn't reproduce PHP 5.2.5: problem found PHP 5.3-200712262130: problem found Previous Comments: [2007-12-26 21:34:25] [EMAIL PROTECTED] I can't reproduce the bug in PHP 5.1.6 on Darwin Kernel Version 8.11.1, which makes me think its an issue of 5.2.5 only. [2007-12-23 14:08:14] [EMAIL PROTECTED] Apache 1.3.33 and PHP 5.2.5 running on Darwin Kernel Version 8.11.1 (Mac OS X 10.4.11) compiled with configure command (gcc): './configure' '--prefix=/usr/local' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-apxs' '--with-kerberos' '--enable-cli' '--enable-exif' '--enable-ftp' '--enable-mbstring' '--enable-mbregex' '--enable-sockets' '--with-curl' '--with-config-file-path=/private/etc' '--sysconfdir=/private/etc' '--with-mysql=/usr/local/mysql' '--with-mysql-sock=/tmp/mysql.sock' '--without-pear' '--with-gd' '--enable-gd-native-ttf' '--with-png-dir' '--with-zlib' '--with-bz2' '--with-libxml-dir' '--with-mysqli=/usr/local/mysql/bin/mysql_config' '--enable-sqlite-utf8' '--enable-zip' '--disable-cgi' doesn't seems to be closing open files (requires, includes etc.) which ends up with the error Too many open files very often. # apachectl restart # lsof -u www | wc -l 56 # lsof -u www | grep \.php | wc -l no output After running one PHP script: # lsof -u www | grep \.php | wc -l 22 Another page hit: # lsof -u www | grep \.php | wc -l 104 And so on... The number of open files just keeps increasing. For some reason PHP 4.4.7 don't have this behavior, that is, apache keeps the number of open files somewhat constant when PHP is not running. For phpMyAdmin the first entries of lsof looks like: # lsof -u www | grep \.php | head httpd 678 www6r REG 14,226700 915904 /Users/data/htdocs/mysql/libraries/common.inc.php httpd 678 www7r REG 14,218504 915886 /Users/data/htdocs/mysql/libraries/core.lib.php httpd 678 www8r REG 14,2 2063 915950 /Users/data/htdocs/mysql/libraries/sanitizing.lib.php httpd 678 www9r REG 14,2 9447 915968 /Users/data/htdocs/mysql/libraries/Theme.class.php httpd 678 www 10r REG 14,210571 915906 /Users/data/htdocs/mysql/libraries/Theme_Manager.class.php httpd 678 www 11r REG 14,2 9447 915968 /Users/data/htdocs/mysql/libraries/Theme.class.php httpd 678 www 12r REG 14,233846 915974 /Users/data/htdocs/mysql/libraries/Config.class.php httpd 678 www 13r REG 14,244257 915868 /Users/data/htdocs/mysql/libraries/Table.class.php httpd 678 www 14r REG 14,279607 915957 /Users/data/htdocs/mysql/libraries/common.lib.php httpd 678 www 18r REG 14,2 1919 915824 /Users/data/htdocs/mysql/libraries/js_escape.lib.php [2007-11-29 16:03:43] marcus dot mueller at grintsch dot com As I stated above we have this issue on two Linux boxes with self-compiled PHP binaries. These were compiled using gcc! [2007-11-28 16:36:24] ian at onlineloop dot com Coming back to the bug report here now. In the meantime some private emails were exchanged, including a pfiles output from Solaris showing that PHP had over 210,000 open files after 24 hours running on our servers. Within 48 hours (we let it go this far onyl once), apache/php eats around 12Gb of RAM and has between 170 and 220 child processes with over 230,000 open files. Under 5.1.6 the usage is more around 1.5-2Gb ram, and 30-70 child processes, with rarely more than 100 open files (only when we are really under load do we get to more than about 800 open files at any one time). A small patch was sent to me to try, however this has changed nothing. I was also asked to compile with gcc if possible, however this is not feasible as too many other things would have to be recompiled. Besides, we specifically went away from gcc because everything we had that was compiled with gcc was seg faulting all the time, however with the Sun Studio compiler suite, everything is stable. I seriously doubt this is an apache bug, why were things working with previous versions of PHP, and not this one? [2007-11-28 15:02:11] grknight at iwon dot com I am also experiencing this issue. We are running Apache 2.2.3 on Redhat EL 3 and recently tried to
#43682 [Opn]: session id kept, content lost on subdomain
ID: 43682 User updated by: k dot andris at gmail dot com Reported By: k dot andris at gmail dot com Status: Open Bug Type: Session related Operating System: Debian Sarge PHP Version: 5.2.5 New Comment: Works all right in 5.2 Previous Comments: [2007-12-26 21:00:49] k dot andris at gmail dot com Description: The $_SESSION variable is empty when I look at it on a subdomain (abc.mydomain.com) even though session_id() is the same as on the main site (mydomain.com). Sessions are saved in files under /var/log/php5 - they just not read from there. The session cookie is OK too. Reproduce code: --- I have this on the base domain and on subdoamins too with different assigment lines. Still, they only seee their own assigments. ini_set(session.cookie_domain, .mydomain.net); session_start(); print_r($_SESSION); $_SESSION['main'] = 'main'; // assigment print_r($_SESSION); Expected result: Since I have the same session id, I expect the $_SESSION variable to be shared acreoss pages, and subdomains. -- Edit this bug report at http://bugs.php.net/?id=43682edit=1
#28227 [Com]: PHP CGI depends upon non-standard SCRIPT_FILENAME
ID: 28227 Comment by: al dot rivero at gmail dot com Reported By: lukem at NetBSD dot org Status: No Feedback Bug Type: CGI related Operating System: * PHP Version: 5CVS, 4CVS (2005-02-04) Assigned To: fmk New Comment: with PHP/5.2.3-1ubuntu6.2 php-cgi ejemplo.php works, but REQUEST_METHOD=GET php-cgi ejemplo.php doesn't work, it produces the bug, No input file specified. Then REQUEST_METHOD=GET SCRIPT_FILENAME=ejemplo.php php-cgi ejemplo.php works, and more suprisingly SCRIPT_FILENAME=ejemplo.php php-cgi ejemplo.php works, and SCRIPT_FILENAME=ejemplo.php php-cgi works! Note that there is now an informative-doc RFC for CGI 1.1 http://www.ietf.org/rfc/rfc3875 and it says that _name is a MUST, but _filename is optional, in fact it is not mentioned there (it is an Apache extension). Previous Comments: [2007-07-03 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2007-06-25 23:44:14] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2006-08-10 19:05:01] [EMAIL PROTECTED] The patch broke CGI on other web servers (IIS on Win32). That was the reason it was reverted. So far I have not been able to come up with a way to apply your patch so it will work in all cases (not breaking existing installed systems). [2006-08-10 00:04:42] lukem at NetBSD dot org If I recall correctly, PHP4 as a CGI _did_ rely upon SCRIPT_FILENAME being set by the web server, at least in the default build of PHP4. My original workaround was to modify the non-Apache web server I was using to set SCRIPT_FILENAME before invoking php-as-cgi. IMHO, it not an acceptable long-term solution to modify the _web server_ because the _CGI application_ (php) relies upon a non-standard CGI variable. Which is why I developed the patch, which worked at the time for the release of PHP I was using (4.3.6). Based on the replies I've seen to my bug report patch, other people are also seeing this problem, even in newer releases of PHP. Not everyone uses PHP as an Apache module, and not everyone uses Apache as a web server. People that want to use php as a CGI on other minimal web servers (e.g, embedded systems) may run into this problem, spend time trying to fix it, get pushback from the PHP developer community about this not being a problem (c.f. the way various bug reports documenting a similar problem with the no input file found being closed as configuration problem, when I show that it's PHP-as-CGI barfing because SCRIPT_FILENAME isn't set), and in the end punt and use another solution. I strongly suggest that the PHP developers set up a test environment where PHP runs as a CGI from one of the many minimal (Open Source) web servers available that don't implement SCRIPT_FILENAME to attempt to reproduce this issue that numerous people have observerd (based on followups to this ticket, and other tickets that I've read). [2006-08-09 18:30:05] [EMAIL PROTECTED] because the patch is not correct and this is an incredibly fragile mechanism due to the wide variety of web servers out there. And despite what the bug report says, PHP does not rely on SCRIPT_FILENAME being present, it simply uses it if it is there. As far as I can tell using ./configure --enable-discard-path should take care of this problem. 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/28227 -- Edit this bug report at http://bugs.php.net/?id=28227edit=1
#43105 [Opn]: PHP seems to fail to close open files.
ID: 43105 Updated by: [EMAIL PROTECTED] Reported By: ian at onlineloop dot com Status: Open Bug Type: Apache2 related Operating System: Solaris, Linux, Mac OS X PHP Version: 5.2.5RC2-dev New Comment: It seems that the bug was introduced here: http://cvs.php.net/viewvc.cgi/php-src/main/fopen_wrappers.c?revision=1.175.2.3.2.14view=markuppathrev=PHP_5_2 (revision 1.175.2.3.2.14 of fopen_wrappers.c) Previous Comments: [2007-12-26 22:22:41] [EMAIL PROTECTED] I did some more tests: PHP 4.4.7: couldn't reproduce PHP 5.1.6: couldn't reproduce PHP 5.2.4: couldn't reproduce PHP 5.2.5: problem found PHP 5.3-200712262130: problem found [2007-12-26 21:34:25] [EMAIL PROTECTED] I can't reproduce the bug in PHP 5.1.6 on Darwin Kernel Version 8.11.1, which makes me think its an issue of 5.2.5 only. [2007-12-23 14:08:14] [EMAIL PROTECTED] Apache 1.3.33 and PHP 5.2.5 running on Darwin Kernel Version 8.11.1 (Mac OS X 10.4.11) compiled with configure command (gcc): './configure' '--prefix=/usr/local' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-apxs' '--with-kerberos' '--enable-cli' '--enable-exif' '--enable-ftp' '--enable-mbstring' '--enable-mbregex' '--enable-sockets' '--with-curl' '--with-config-file-path=/private/etc' '--sysconfdir=/private/etc' '--with-mysql=/usr/local/mysql' '--with-mysql-sock=/tmp/mysql.sock' '--without-pear' '--with-gd' '--enable-gd-native-ttf' '--with-png-dir' '--with-zlib' '--with-bz2' '--with-libxml-dir' '--with-mysqli=/usr/local/mysql/bin/mysql_config' '--enable-sqlite-utf8' '--enable-zip' '--disable-cgi' doesn't seems to be closing open files (requires, includes etc.) which ends up with the error Too many open files very often. # apachectl restart # lsof -u www | wc -l 56 # lsof -u www | grep \.php | wc -l no output After running one PHP script: # lsof -u www | grep \.php | wc -l 22 Another page hit: # lsof -u www | grep \.php | wc -l 104 And so on... The number of open files just keeps increasing. For some reason PHP 4.4.7 don't have this behavior, that is, apache keeps the number of open files somewhat constant when PHP is not running. For phpMyAdmin the first entries of lsof looks like: # lsof -u www | grep \.php | head httpd 678 www6r REG 14,226700 915904 /Users/data/htdocs/mysql/libraries/common.inc.php httpd 678 www7r REG 14,218504 915886 /Users/data/htdocs/mysql/libraries/core.lib.php httpd 678 www8r REG 14,2 2063 915950 /Users/data/htdocs/mysql/libraries/sanitizing.lib.php httpd 678 www9r REG 14,2 9447 915968 /Users/data/htdocs/mysql/libraries/Theme.class.php httpd 678 www 10r REG 14,210571 915906 /Users/data/htdocs/mysql/libraries/Theme_Manager.class.php httpd 678 www 11r REG 14,2 9447 915968 /Users/data/htdocs/mysql/libraries/Theme.class.php httpd 678 www 12r REG 14,233846 915974 /Users/data/htdocs/mysql/libraries/Config.class.php httpd 678 www 13r REG 14,244257 915868 /Users/data/htdocs/mysql/libraries/Table.class.php httpd 678 www 14r REG 14,279607 915957 /Users/data/htdocs/mysql/libraries/common.lib.php httpd 678 www 18r REG 14,2 1919 915824 /Users/data/htdocs/mysql/libraries/js_escape.lib.php [2007-11-29 16:03:43] marcus dot mueller at grintsch dot com As I stated above we have this issue on two Linux boxes with self-compiled PHP binaries. These were compiled using gcc! [2007-11-28 16:36:24] ian at onlineloop dot com Coming back to the bug report here now. In the meantime some private emails were exchanged, including a pfiles output from Solaris showing that PHP had over 210,000 open files after 24 hours running on our servers. Within 48 hours (we let it go this far onyl once), apache/php eats around 12Gb of RAM and has between 170 and 220 child processes with over 230,000 open files. Under 5.1.6 the usage is more around 1.5-2Gb ram, and 30-70 child processes, with rarely more than 100 open files (only when we are really under load do we get to more than about 800 open files at any one time). A small patch was sent to me to try, however this has changed nothing. I was also asked to compile with gcc if possible, however this is not feasible as too many other things would have to be recompiled. Besides, we specifically went away from gcc because everything we had that was compiled with gcc was seg faulting all the time, however with the Sun Studio compiler suite, everything is stable. I seriously doubt this is
#43683 [NEW]: Can not find oci.dll and uninstall
From: ranlicmu at gmail dot com Operating system: windows xp PHP version: 5.2.5 PHP Bug Type: *Configuration Issues Bug description: Can not find oci.dll and uninstall Description: Can not open any php file. The following dll fills are missing: oci.dll sqlite3.dll aspell-15.dll libcs.dll db2cli.dll isqlt09a.dll libsqldbc_c.dll libmonetra.dll lcrzo.dll ociw32.dll db2cli.dll iclit09b.dll intl3_svn.dll. Can not change and uninstall in the original installer. -- Edit bug report at http://bugs.php.net/?id=43683edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43683r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43683r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43683r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43683r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43683r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43683r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43683r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43683r=needscript Try newer version:http://bugs.php.net/fix.php?id=43683r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43683r=support Expected behavior:http://bugs.php.net/fix.php?id=43683r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43683r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43683r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43683r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43683r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43683r=dst IIS Stability:http://bugs.php.net/fix.php?id=43683r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43683r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43683r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43683r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43683r=mysqlcfg
#43105 [Opn-Csd]: PHP seems to fail to close open files.
ID: 43105 Updated by: [EMAIL PROTECTED] Reported By: ian at onlineloop dot com -Status: Open +Status: Closed Bug Type: Apache2 related Operating System: Solaris, Linux, Mac OS X PHP Version: 5.2.5RC2-dev -Assigned To: +Assigned To: bjori New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Thanks to Igors awesome debugging skillz :) Previous Comments: [2007-12-27 01:54:45] [EMAIL PROTECTED] It seems that the bug was introduced here: http://cvs.php.net/viewvc.cgi/php-src/main/fopen_wrappers.c?revision=1.175.2.3.2.14view=markuppathrev=PHP_5_2 (revision 1.175.2.3.2.14 of fopen_wrappers.c) [2007-12-26 22:22:41] [EMAIL PROTECTED] I did some more tests: PHP 4.4.7: couldn't reproduce PHP 5.1.6: couldn't reproduce PHP 5.2.4: couldn't reproduce PHP 5.2.5: problem found PHP 5.3-200712262130: problem found [2007-12-26 21:34:25] [EMAIL PROTECTED] I can't reproduce the bug in PHP 5.1.6 on Darwin Kernel Version 8.11.1, which makes me think its an issue of 5.2.5 only. [2007-12-23 14:08:14] [EMAIL PROTECTED] Apache 1.3.33 and PHP 5.2.5 running on Darwin Kernel Version 8.11.1 (Mac OS X 10.4.11) compiled with configure command (gcc): './configure' '--prefix=/usr/local' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-apxs' '--with-kerberos' '--enable-cli' '--enable-exif' '--enable-ftp' '--enable-mbstring' '--enable-mbregex' '--enable-sockets' '--with-curl' '--with-config-file-path=/private/etc' '--sysconfdir=/private/etc' '--with-mysql=/usr/local/mysql' '--with-mysql-sock=/tmp/mysql.sock' '--without-pear' '--with-gd' '--enable-gd-native-ttf' '--with-png-dir' '--with-zlib' '--with-bz2' '--with-libxml-dir' '--with-mysqli=/usr/local/mysql/bin/mysql_config' '--enable-sqlite-utf8' '--enable-zip' '--disable-cgi' doesn't seems to be closing open files (requires, includes etc.) which ends up with the error Too many open files very often. # apachectl restart # lsof -u www | wc -l 56 # lsof -u www | grep \.php | wc -l no output After running one PHP script: # lsof -u www | grep \.php | wc -l 22 Another page hit: # lsof -u www | grep \.php | wc -l 104 And so on... The number of open files just keeps increasing. For some reason PHP 4.4.7 don't have this behavior, that is, apache keeps the number of open files somewhat constant when PHP is not running. For phpMyAdmin the first entries of lsof looks like: # lsof -u www | grep \.php | head httpd 678 www6r REG 14,226700 915904 /Users/data/htdocs/mysql/libraries/common.inc.php httpd 678 www7r REG 14,218504 915886 /Users/data/htdocs/mysql/libraries/core.lib.php httpd 678 www8r REG 14,2 2063 915950 /Users/data/htdocs/mysql/libraries/sanitizing.lib.php httpd 678 www9r REG 14,2 9447 915968 /Users/data/htdocs/mysql/libraries/Theme.class.php httpd 678 www 10r REG 14,210571 915906 /Users/data/htdocs/mysql/libraries/Theme_Manager.class.php httpd 678 www 11r REG 14,2 9447 915968 /Users/data/htdocs/mysql/libraries/Theme.class.php httpd 678 www 12r REG 14,233846 915974 /Users/data/htdocs/mysql/libraries/Config.class.php httpd 678 www 13r REG 14,244257 915868 /Users/data/htdocs/mysql/libraries/Table.class.php httpd 678 www 14r REG 14,279607 915957 /Users/data/htdocs/mysql/libraries/common.lib.php httpd 678 www 18r REG 14,2 1919 915824 /Users/data/htdocs/mysql/libraries/js_escape.lib.php [2007-11-29 16:03:43] marcus dot mueller at grintsch dot com As I stated above we have this issue on two Linux boxes with self-compiled PHP binaries. These were compiled using gcc! 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/43105 -- Edit this bug report at http://bugs.php.net/?id=43105edit=1
#43684 [NEW]: leaky output buffering or the inproper for (;;) interpretation
From: programatorfreez at gmail dot com
Operating system: Gentoo GNU/Linux
PHP version: 5.2.5
PHP Bug Type: Scripting Engine problem
Bug description: leaky output buffering or the inproper for (;;) interpretation
Description:
ob_start(), ob_flush() or for(;;) is leaky and doesn't do what it gotta
do.
Reproduce code:
---
#!/usr/bin/php
?php
$i = 0;
for (;;) {
$i++;
@ob_start();
echo Iter: $ibr /\n; // PHP is pretty bad, it cannot even
do the for cycle properly
ob_flush();
}
?
Expected result:
It should be an infinite loop
Actual result:
--
...
Iter: 3067br /
sh-3.2$
--
Edit bug report at http://bugs.php.net/?id=43684edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43684r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43684r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43684r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43684r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43684r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43684r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43684r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43684r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43684r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43684r=support
Expected behavior:http://bugs.php.net/fix.php?id=43684r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43684r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43684r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43684r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43684r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43684r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43684r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43684r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43684r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43684r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43684r=mysqlcfg
#43685 [NEW]: Dom-importNode() returns FALSE instead of the Exception
From: programatorfreez at gmail dot com
Operating system: Gentoo GNU/Linux
PHP version: 5.2.5
PHP Bug Type: DOM XML related
Bug description: Dom-importNode() returns FALSE instead of the Exception
Description:
There is a DomException in the documentation of Dom-importNode(), but it
returns FALSE on fail without a reason.
Reproduce code:
---
/**
* Import node to dom
*
* @param DomElement node which will be imported
* @param boolean deep (use recursive importing - default TRUE)
* @return DomElement reference to created node
*/
public function domImportNode($node, $deep = TRUE) {
if (FALSE === ($sxe = $this-dom-importNode($node, $deep))) {
throw new Exception('importNode failed.');
}
$sxe = $this-dom-appendChild($sxe);
return $sxe;
}
Expected result:
DomException
Actual result:
--
My Exception
--
Edit bug report at http://bugs.php.net/?id=43685edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43685r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43685r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43685r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43685r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43685r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43685r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43685r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43685r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43685r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43685r=support
Expected behavior:http://bugs.php.net/fix.php?id=43685r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43685r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43685r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43685r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43685r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43685r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43685r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43685r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43685r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43685r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43685r=mysqlcfg
#43686 [NEW]: It could be possible to import a string into DomDocument
From: programatorfreez at gmail dot com
Operating system: Gentoo GNU/Linux
PHP version: 5.2.5
PHP Bug Type: Feature/Change Request
Bug description: It could be possible to import a string into DomDocument
Description:
You're missing a very handful feature and it's pretty annoying to make a
workaround which cannot perform exactly what I need until PHP is fixed.
Reproduce code:
---
This is my crappy workaround for the missing Dom-importString(), however
the support in DOM should be made.
/**
* Import a string like somethingbr /strongstrong/strong into the
DomDocument
*
* @param string string
* @param DomElement parent
* @return DomElement reference to imported node
*/
public function importString($string, $parent) {
if ($parent === NULL) {
throw new Exception('Parent cannot be NULL.');
}
$tmp = new DomDocument('1.0', 'utf-8');
// The div is unwanted here, but loadXml doesn't work without it
$tmp-loadXml('div' . $string . '/div');
return $this-domImportNode($tmp-firstChild);
}
Actual result:
--
PHP DOM doesn't provide any similar functionaly, although it's needed.
--
Edit bug report at http://bugs.php.net/?id=43686edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43686r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43686r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43686r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43686r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43686r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43686r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43686r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43686r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43686r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43686r=support
Expected behavior:http://bugs.php.net/fix.php?id=43686r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43686r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43686r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43686r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43686r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43686r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43686r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43686r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43686r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43686r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43686r=mysqlcfg
#21076 [Com]: ODBC_TABLES and ODBC_COLUMNS cannot be called together
ID: 21076
Comment by: php-louis at steelbytes dot com
Reported By: jlim at natsoft dot com
Status: No Feedback
Bug Type: ODBC related
Operating System: Win2000, IIS-CGI
PHP Version: 4CVS, 5CVS
New Comment:
I just ran into this problem with latest PHP and MSDE2000 (SQL Server
2000 cut down editon).
using somthing like the following does not work ... (pseudo code)
$tables = odbc_tables($con)
while ($t=$odbc_fetch_array($tables))
{
odbc_columns($con,$t['TABLE_CAT'],$t['TABLE_SCHEM'],$t['TABLE_NAME']);
-- fails here
display column results
}
but the following does work
$tables = odbc_tables($con)
while ($t=$odbc_fetch_array($tables))
array_push($tahbles_array,$t);
odbc_free_result($tables);
for (. $t in $tahbles_array .)
{
odbc_columns(..$t[name].) (as above)
display column results
odbc_free_result()
}
Previous Comments:
[2004-04-21 00:13:29] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to Open. Thank you.
[2004-04-13 12:57:54] [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
[2003-07-02 04:01:13] jlim at natsoft dot com
Tested with 4.3.3RC2-dev. Same problem with mssql odbc driver.
I also tested with access and oracle odbc drivers and the problem never
happens with these drivers, so it appears to be something specific to
the way mssql does things.
I also double-checked the MDAC using M'soft's ComCheck program(as i
have changed PC's), and it is mdac 2.7 SP1.
The mssql driver version is 2000.81.9031.14, 15/Nov/2002
Regards, John
[2003-06-29 22:45:57] [EMAIL PROTECTED]
Yep it exists.
[2003-02-19 23:35:38] [EMAIL PROTECTED]
Well now that seems really odd. I guess I'll have to try to get access
to a SQLServer machine for some testing... ugh...
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/21076
--
Edit this bug report at http://bugs.php.net/?id=21076edit=1
#43668 [Opn-Ana]: Added control of ODBC cursor type
ID: 43668 Updated by: [EMAIL PROTECTED] Reported By: iodbc at openlinksw dot com -Status: Open +Status: Analyzed Bug Type:ODBC related PHP Version: 5.2CVS-2007-12-24 (CVS) New Comment: A much needed patch that will also solve issues on older IBM DB2 installations with leaked memory. Applying this patch is highly recommended. Previous Comments: [2007-12-24 15:04:22] iodbc at openlinksw dot com Description: This patch allows the developer to specify what level of cursor support is needed for the application, rather than using the slowest available. ftp://download.openlinksw.com/support/php-dev/odbc-cursor.txt -- Edit this bug report at http://bugs.php.net/?id=43668edit=1
#43669 [Opn-Ana]: Fixed iODBC support for recent SDKs
ID: 43669 Updated by: [EMAIL PROTECTED] Reported By: iodbc at openlinksw dot com -Status: Open +Status: Analyzed Bug Type:ODBC related PHP Version: 5.2CVS-2007-12-24 (CVS) New Comment: Untested patch, but since it's provided by the iODBC maintainer, it's probably a safe patch to apply. Extends functionality for iODBC only. Previous Comments: [2007-12-24 15:07:39] iodbc at openlinksw dot com Description: PHP ODBC support does not work properly against later versions of the iODBC Driver Manager, so users are missing out on features that are long since supported. ftp://download.openlinksw.com/support/php-dev/odbc-iodbc.txt -- Edit this bug report at http://bugs.php.net/?id=43669edit=1
#43666 [Opn-Ana]: Adding odbc v3.52 support
ID: 43666 Updated by: [EMAIL PROTECTED] Reported By: iodbc at openlinksw dot com -Status: Open +Status: Analyzed Bug Type:ODBC related PHP Version: 5.2CVS-2007-12-24 (CVS) New Comment: Looking through the patch this looks like a clean update for 64bit compatibility. Applying this to HEAD would be wise. Previous Comments: [2007-12-24 15:00:07] iodbc at openlinksw dot com Here is the URL to the diff: ftp://download.openlinksw.com/support/php-dev/odbc-types.txt [2007-12-24 10:21:14] iodbc at openlinksw dot com Description: The ext/odbc code does not use ODBC 3.52 API datatypes which makes it impossible to use with WIN64 and Unix 64bit systems. I have created a patch to add this functionality which has also been posted to the php-dev mailing list. -- Edit this bug report at http://bugs.php.net/?id=43666edit=1
