#45287 [NEW]: PDO/ODBC driver doesn't respect PDO::ATTR_TIMEOUT option
From: csa at dside dot dyndns dot org
Operating system: Linux
PHP version: 5.2.6
PHP Bug Type: PDO related
Bug description: PDO/ODBC driver doesn't respect PDO::ATTR_TIMEOUT option
Description:
PDO/ODBC code is not implementing timeouts support. This limits PHP
applications abilities in the fast detection of inaccessible database
backends.
This patch provides missing functionality:
http://dside.dyndns.org/projects/patches.dir/php-ds-odbc_timeout.patch
Reproduce code:
---
$dbh = new PDO("odbc:some_unreachable_server_dsn", NULL, NULL, array(
PDO::ATTR_TIMEOUT => 1
));
Expected result:
Should timeout and throw exception in 1 second (if supported by underlying
ODBC driver).
Actual result:
--
The specified timeout is not passed to the ODBC driver and driver's
default is used.
--
Edit bug report at http://bugs.php.net/?id=45287&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45287&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45287&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45287&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45287&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45287&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45287&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45287&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45287&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45287&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45287&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45287&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45287&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45287&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45287&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45287&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45287&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45287&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45287&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45287&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45287&r=mysqlcfg
#43445 [Com]: Segfault when selecting from a "long" column using Odbc with TimesTen driver
ID: 43445
Comment by: csa at dside dot dyndns dot org
Reported By: akoebel at capgemini dot fr
Status: Open
Bug Type: PDO related
Operating System: Ubuntu 7.10
PHP Version: 5.2.6 20071127
New Comment:
I think it could be caused by bug #42765,
http://bugs.php.net/bug.php?id=42765
Previous Comments:
[2007-11-29 14:51:07] akoebel at capgemini dot fr
Tested today with version 5.2.6 from november 27th, 2007
PHP was compiled with debugging enabled and pdo-odbc=unixOdbc
unixOdbc was version 2.2.12
Here's the backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1216276816 (LWP 10102)]
0xb72439c5 in extract_sql_error_rec (head=0x8392858,
sqlstate=0xbf8e3a93 "0", rec_number=1,
native_error=0xbf8e3a98,
message_text=0xbf8e3ab8 "ocket_sendto", buffer_length=1023,
text_length=0xbf8e3ab0) at SQLGetDiagRec.c:440
440 as1 = (SQLCHAR*) unicode_to_ansi_alloc( ptr -> msg,
SQL_NTS, __get_connection( head ));
(gdb) bt
#0 0xb72439c5 in extract_sql_error_rec (head=0x8392858,
sqlstate=0xbf8e3a93 "0", rec_number=1,
native_error=0xbf8e3a98,
message_text=0xbf8e3ab8 "ocket_sendto", buffer_length=1023,
text_length=0xbf8e3ab0) at SQLGetDiagRec.c:440
#1 0xb724468d in SQLGetDiagRec (handle_type=3, handle=0x8392430,
rec_number=2, sqlstate=0xbf8e3a93 "0", native=0xbf8e3a98,
message_text=0xbf8e3ab8 "ocket_sendto", buffer_length=1023,
text_length_ptr=0xbf8e3ab0) at SQLGetDiagRec.c:741
#2 0xb746694d in pdo_odbc_error (dbh=0x82e78a4, stmt=0x82e9638,
statement=0x8392430, what=0xb7771b9d "SQLFetchScroll",
file=0xb7771ac8
"/home/sieadmin/php5.2-200711271530/ext/pdo_odbc/odbc_stmt.c", line=375,
tsrm_ls=0x8135388)
at
/home/sieadmin/php5.2-200711271530/ext/pdo_odbc/odbc_driver.c:120
#3 0xb7468a9a in odbc_stmt_fetch (stmt=0x82e9638,
ori=PDO_FETCH_ORI_NEXT,
offset=0, tsrm_ls=0x8135388)
at /home/sieadmin/php5.2-200711271530/ext/pdo_odbc/odbc_stmt.c:375
#4 0xb745e329 in do_fetch_common (stmt=0x82e9638,
ori=PDO_FETCH_ORI_NEXT,
offset=0, do_bind=1, tsrm_ls=0x8135388)
at /home/sieadmin/php5.2-200711271530/ext/pdo/pdo_stmt.c:669
#5 0xb745f764 in do_fetch (stmt=0x82e9638, do_bind=1,
return_value=0x82e9114,
how=PDO_FETCH_BOTH, ori=PDO_FETCH_ORI_NEXT, offset=0,
return_all=0x0,
tsrm_ls=0x8135388)
at /home/sieadmin/php5.2-200711271530/ext/pdo/pdo_stmt.c:903
#6 0xb7461025 in zim_PDOStatement_fetch (ht=0,
return_value=0x82e9114,
return_value_ptr=0x0, this_ptr=0x82e9094, return_value_used=1,
tsrm_ls=0x8135388)
at /home/sieadmin/php5.2-200711271530/ext/pdo/pdo_stmt.c:1342
#7 0xb76a47ea in zend_do_fcall_common_helper_SPEC
(execute_data=0xbf8e4360,
tsrm_ls=0x8135388)
at /home/sieadmin/php5.2-200711271530/Zend/zend_vm_execute.h:200
#8 0xb76a57e3 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xbf8e4360,
tsrm_ls=0x8135388)
at /home/sieadmin/php5.2-200711271530/Zend/zend_vm_execute.h:322
#9 0xb76a4284 in execute (op_array=0x82e77e8, tsrm_ls=0x8135388)
at /home/sieadmin/php5.2-200711271530/Zend/zend_vm_execute.h:92
#10 0xb767b7e5 in zend_execute_scripts (type=8, tsrm_ls=0x8135388,
retval=0x0,
file_count=3) at
/home/sieadmin/php5.2-200711271530/Zend/zend.c:1134
#11 0xb761596c in php_execute_script (primary_file=0xbf8e66cc,
tsrm_ls=0x8135388) at
/home/sieadmin/php5.2-200711271530/main/main.c:2004
#12 0xb770438e in php_handler (r=0x831f1c0)
at
/home/sieadmin/php5.2-200711271530/sapi/apache2handler/sapi_apache2.c:631
#13 0x08079259 in ap_run_handler ()
#14 0x0807c5b7 in ap_invoke_handler ()
#15 0x08089998 in ap_process_request ()
#16 0x08086c9b in ?? ()
#17 0x0831f1c0 in ?? ()
#18 0x0004 in ?? ()
#19 0x0831f1c0 in ?? ()
#20 0x in ?? ()
[2007-11-29 10:36:53] akoebel at capgemini dot fr
Description:
We're having some difficulties using PDO
in conjunction with Oracle TimesTen 7.03 ODBC driver
and long column datatypes.
Oracle table :
CREATE TABLE TEST (ID NUMBER(10) NOT NULL PRIMARY KEY,DATA LONG NOT
NULL);
INSERT INTO TEST VALUES (1,'sample');
TimesTen :
CREATE READONLY CACHE GROUP FROM TEST (ID NUMBER(10) NOT NULL PRIMARY
KEY, DATA VARCHAR(256000);
Note that timesten doesn't support the long datatype directly.
Odbc.ini :
[myDSN]
Datastore=/home/sieadmin/tt
PermSize=100
TempSize=100
UID=test
OracleId=XE
OraclePwd=test
DatabaseCharacterSet=WE8MSWIN1252
[testClient]
DRIVER = /opt/TimesTen/tt70/lib/libtten.so
DataStore=/home/sieadmin/tt
PermSize=100
PHP File :
PDO
prepare($sql);
$rs->execute();
while ($res=$rs->fetch()) {
print_r($res);
}
$conn=null;
?>
This script was executed on these platforms:
-Ubuntu 7.10 with PHP5
#42765 [Com]: PDO ODBC: Long binary field in query result crashes PHP ("Out of memory" error)
ID: 42765
Comment by: csa at dside dot dyndns dot org
Reported By: sms at inbox dot ru
Status: Open
Bug Type: PDO related
Operating System: Windows 2000 SP4
PHP Version: 5.2.4
New Comment:
By the way feel free to contact me on [EMAIL PROTECTED] if you have
problems with this patches.
Previous Comments:
[2008-06-10 09:06:02] csa at dside dot dyndns dot org
I got the same problem on Linux (64bit, php 5.2.6). Actually, the
problem is existing in all configurations. I have take a brief look
through php sources. The bug is in pdo_odbc code and affects all
architectures and underlying database engines.
Actually it is in 'ext/pdo_odbc/odbc_stmt.c', function
'odbc_stmt_describe'. The 'displaysize' variable is expected to contain
estimated size of the column. This could be a negative number if BLOB or
TEXT data is stored (since the record sizes could seriously vary).
However, later in this function the check on data size does not consider
negative numbers. This causes the described behavior. This patch solves
problem for me:
http://dside.dyndns.org/projects/patches.dir/php-ds-odbc_blob.patch
A Linux user trying to access MSSQL over FreeTDS may be interested in
the following patches as well:
http://dside.dyndns.org/projects/patches.dir/freetds-ds-odbc.patch
http://dside.dyndns.org/projects/patches.dir/php-ds-odbc64.patch
[2007-09-27 18:07:29] carlton dot whitehead at cebesius dot com
I encountered this bug with this setup:
Windows Server 2003 SP2 32bit
IIS 6
PHP 5.2.4
MS SQL Server 2005 Express SP2
PDO ODBC reproduce code:
---
prepare($stp);
$execResult = $ps->execute();
var_export($execResult, true);
}
catch (PDOException $e)
{
die($e->getMessage());
}
?>
Expected result:
output to browser: true
Actual result:
--
*Fatal error*: Out of memory (allocated 262144) (tried to allocate
4294967295 bytes) in *C:\Inetpub\wwwroot\FMarchive\lobtestPdoOdbc.php*
on line *9*
plain ODBC reproduce code:
--
Expected result:
output to browser: true
Actual result:
--
output to browser: true
(this indicates odbc_execute worked correctly)
[2007-09-26 11:00:15] sms at inbox dot ru
Description:
With PDO ODBC I can't get long binary data from Microsoft SQL Server
(image and varbinary(MAX) fields). PDO->query, PDOStatement->execute()
always result in PHP "Out of memory" error, even if output contains no
rows.
The same queries work fine with ODBC unified extension.
Reproduce code:
---
query("select [nbin] from [atts] where [id]=1");
?>
Expected result:
No PHP fatal errors
Actual result:
--
PHP Fatal error: Out of memory (allocated 262144) (tried to allocate
4294967295 bytes) in D:\Web\test.php on line 3
--
Edit this bug report at http://bugs.php.net/?id=42765&edit=1
#42765 [Com]: PDO ODBC: Long binary field in query result crashes PHP ("Out of memory" error)
ID: 42765
Comment by: csa at dside dot dyndns dot org
Reported By: sms at inbox dot ru
Status: Open
Bug Type: PDO related
Operating System: Windows 2000 SP4
PHP Version: 5.2.4
New Comment:
I got the same problem on Linux (64bit, php 5.2.6). Actually, the
problem is existing in all configurations. I have take a brief look
through php sources. The bug is in pdo_odbc code and affects all
architectures and underlying database engines.
Actually it is in 'ext/pdo_odbc/odbc_stmt.c', function
'odbc_stmt_describe'. The 'displaysize' variable is expected to contain
estimated size of the column. This could be a negative number if BLOB or
TEXT data is stored (since the record sizes could seriously vary).
However, later in this function the check on data size does not consider
negative numbers. This causes the described behavior. This patch solves
problem for me:
http://dside.dyndns.org/projects/patches.dir/php-ds-odbc_blob.patch
A Linux user trying to access MSSQL over FreeTDS may be interested in
the following patches as well:
http://dside.dyndns.org/projects/patches.dir/freetds-ds-odbc.patch
http://dside.dyndns.org/projects/patches.dir/php-ds-odbc64.patch
Previous Comments:
[2007-09-27 18:07:29] carlton dot whitehead at cebesius dot com
I encountered this bug with this setup:
Windows Server 2003 SP2 32bit
IIS 6
PHP 5.2.4
MS SQL Server 2005 Express SP2
PDO ODBC reproduce code:
---
prepare($stp);
$execResult = $ps->execute();
var_export($execResult, true);
}
catch (PDOException $e)
{
die($e->getMessage());
}
?>
Expected result:
output to browser: true
Actual result:
--
*Fatal error*: Out of memory (allocated 262144) (tried to allocate
4294967295 bytes) in *C:\Inetpub\wwwroot\FMarchive\lobtestPdoOdbc.php*
on line *9*
plain ODBC reproduce code:
--
Expected result:
output to browser: true
Actual result:
--
output to browser: true
(this indicates odbc_execute worked correctly)
[2007-09-26 11:00:15] sms at inbox dot ru
Description:
With PDO ODBC I can't get long binary data from Microsoft SQL Server
(image and varbinary(MAX) fields). PDO->query, PDOStatement->execute()
always result in PHP "Out of memory" error, even if output contains no
rows.
The same queries work fine with ODBC unified extension.
Reproduce code:
---
query("select [nbin] from [atts] where [id]=1");
?>
Expected result:
No PHP fatal errors
Actual result:
--
PHP Fatal error: Out of memory (allocated 262144) (tried to allocate
4294967295 bytes) in D:\Web\test.php on line 3
--
Edit this bug report at http://bugs.php.net/?id=42765&edit=1
#45146 [Opn->Bgs]: unixODBC (PDO) queries are causing segmentation error
ID: 45146 User updated by: csa at dside dot dyndns dot org Reported By: csa at dside dot dyndns dot org -Status: Open +Status: Bogus Bug Type: PDO related Operating System: Gentoo Linux PHP Version: 5.2.6 New Comment: Things turned out to been even more complicated :( The problem is fixed in current CVS version of unixODBC. Previous Comments: [2008-06-01 22:22:58] csa at dside dot dyndns dot org Description: ODBC (PDO) queries are causing segmentation error on 64 bit platforms under certain conditions if unixODBC is used to provide ODBC interface. The actual problem is definition of 'pdo_odbc_column' structure (in ext/pdo_odbc/php_pdo_odbc_int.h). The 'fetched_len' member is defined 'long'. However, in odbc_stmt.c (odbc_stmt_describe) the pointer on this member is passed as argument to SQLBindCol (ODBC library) which expects pointer on SQLINTEGER instead. On 64bit platforms unixODBC defines the 'SQLINTEGER' as 'int ' (a 32 bit number) and 'long' is a 64 bit number. On x86_64 this does not cause problems while negative numbers are not used. Therefore, the bug is rarely introduces itself. Unfortunately, in the cases of NULL valued-columns it is possible what '-1' is stored in this member variable. In this case the PhP while end up with segmentation fault. I don't have access to formal ODBC specification and, therefore,don't really know if unixODBC correct in its implementation or violates specification. [ MS defines SQLINTEGER as 'long int'. But 'long int' on win64 is 32bit number. In Linux, 'long int' is 64bit and 'int' is 32bit ]. However, in either case the fix is very simple and will save php developers from lot headache. The proposed patch is available here: http://dside.dyndns.org/projects/patches.dir/php-ds-odbc64.patch -- Edit this bug report at http://bugs.php.net/?id=45146&edit=1
#45146 [NEW]: unixODBC (PDO) queries are causing segmentation error
From: csa at dside dot dyndns dot org Operating system: Gentoo Linux PHP version: 5.2.6 PHP Bug Type: PDO related Bug description: unixODBC (PDO) queries are causing segmentation error Description: ODBC (PDO) queries are causing segmentation error on 64 bit platforms under certain conditions if unixODBC is used to provide ODBC interface. The actual problem is definition of 'pdo_odbc_column' structure (in ext/pdo_odbc/php_pdo_odbc_int.h). The 'fetched_len' member is defined 'long'. However, in odbc_stmt.c (odbc_stmt_describe) the pointer on this member is passed as argument to SQLBindCol (ODBC library) which expects pointer on SQLINTEGER instead. On 64bit platforms unixODBC defines the 'SQLINTEGER' as 'int ' (a 32 bit number) and 'long' is a 64 bit number. On x86_64 this does not cause problems while negative numbers are not used. Therefore, the bug is rarely introduces itself. Unfortunately, in the cases of NULL valued-columns it is possible what '-1' is stored in this member variable. In this case the PhP while end up with segmentation fault. I don't have access to formal ODBC specification and, therefore,don't really know if unixODBC correct in its implementation or violates specification. [ MS defines SQLINTEGER as 'long int'. But 'long int' on win64 is 32bit number. In Linux, 'long int' is 64bit and 'int' is 32bit ]. However, in either case the fix is very simple and will save php developers from lot headache. The proposed patch is available here: http://dside.dyndns.org/projects/patches.dir/php-ds-odbc64.patch -- Edit bug report at http://bugs.php.net/?id=45146&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45146&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45146&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45146&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45146&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45146&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45146&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45146&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45146&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45146&r=support Expected behavior:http://bugs.php.net/fix.php?id=45146&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45146&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45146&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45146&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45146&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45146&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45146&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45146&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45146&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45146&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45146&r=mysqlcfg
