|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2009-04-25 14:52 UTC] jani@php.net
[2009-05-03 01:00 UTC] php-bugs at lists dot php dot net
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Mon Dec 08 00:00:01 2025 UTC |
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)] 0x00002af315aa93e4 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 0x00002af315aa93e4 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 0x00002af312debb4e 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 0x00002af3138eacd7 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 0x00002af313068c35 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 0x00002af31306a2d9 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 0x00002af31306b9fa 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 0x0000000000676642 in ?? () #7 0x0000000000666cac in execute () #8 0x0000000000647cd3 in zend_execute_scripts () #9 0x0000000000606288 in php_execute_script () #10 0x00000000006d0960 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.)