Bug #63075 [Com]: PHP Segfault in PDO ODBC Execute

[email protected] ("kubaszymanowski at gmail dot com")
Newsgroups php.bugs
Message-ID <[email protected]>
Edit report at https://bugs.php.net/bug.php?id=63075&edit=1

 ID:                 63075
 Comment by:         kubaszymanowski at gmail dot com
 Reported by:        Ew6jQ8tSJhf3 at dyweni dot com
 Summary:            PHP Segfault in PDO ODBC Execute
 Status:             Open
 Type:               Bug
 Package:            PDO ODBC
 Operating System:   Linux x86_64 (CentOS 5.8 final)
 PHP Version:        5.4.6
 Block user comment: N
 Private report:     N

 New Comment:

I get the same error running PHP 5.6 and 7.1 on Ubuntu 16.04.1

Files I used for testing:

<?php
$c = odbc_connect("DSN_NAME", "Master", "pass");
odbc_exec($c, "SELECT COUNT(*) FROM dp");

<?php
$pdo = new PDO("odbc:DSN_NAME");
$pdo->query("SELECT COUNT(*) FROM dp");


Previous Comments:
------------------------------------------------------------------------
[2012-09-12 19:51:50] Ew6jQ8tSJhf3 at dyweni dot com

The 5.2.17-6.ius.el5 version of PHP from the IUS repositories works OK too.

FYI IUS is http://iuscommunity.org/

------------------------------------------------------------------------
[2012-09-12 19:44:03] Ew6jQ8tSJhf3 at dyweni dot com

I tested the 5.3.16-1.ius.el5 version of PHP from the IUS repository... These have the same issue.

I tested the 5.3.3-13.el5_8 version of PHP from the CentOS5 Updates repository... These work OK.

------------------------------------------------------------------------
[2012-09-12 19:22:30] Ew6jQ8tSJhf3 at dyweni dot com

Breaking GDB at /usr/src/debug/php-5.4.6/ext/pdo/pdo_stmt.c:514:


(gdb) p stmt
$6 = (pdo_stmt_t *) 0x2aaaab283960
(gdb) p *stmt
$7 = {std = {ce = 0xbbd490, properties = 0x0, properties_table = 0x2aaaab284440, guards = 0x0}, methods = 0x2aaab09b9640, driver_data = 0x2aaaab283ad8, executed = 0, 
supports_placeholders = 2, _reserved = 0, column_count = 0,
  columns = 0x0, database_object_handle = {value = {lval = 46909632806913, dval = 2.3176438028923198e-310, str = {val = 0x2aaa00000001 <Address 0x2aaa00000001 out of 
bounds>, len = -1336223392}, ht = 0x2aaa00000001, obj = {handle = 1,
        handlers = 0x2aaab05ad960}}, refcount__gc = 2, type = 5 '\005', is_ref__gc = 0 '\000'}, dbh = 0x2aaaab2842b0, bound_params = 0x0, bound_param_map = 0x0, 
bound_columns = 0x0, row_count = 0,
  query_string = 0x2aaaab284c20 "SELECT fid, original_filename, dateUploaded, filesize, client FROM upload ORDER BY dateUploaded DESC", query_stringlen = 100, 
active_query_string = 0x0, active_query_stringlen = 0, error_code = "00000",
  lazy_object_ref = {value = {lval = 0, dval = 0, str = {val = 0x0, len = 0}, ht = 0x0, obj = {handle = 0, handlers = 0x0}}, refcount__gc = 0, type = 0 '\000', is_ref__gc 
= 0 '\000'}, refcount = 1, default_fetch_type = PDO_FETCH_BOTH,
  fetch = {column = 0, cls = {ce = 0x0, ctor_args = 0x0, retval_ptr = 0x0, fci = {size = 0, function_table = 0x0, function_name = 0x0, symbol_table = 0x0, retval_ptr_ptr = 
0x0, param_count = 0, params = 0x0, object_ptr = 0x0,
        no_separation = 0 '\000'}, fcc = {initialized = 0 '\000', function_handler = 0x0, calling_scope = 0x0, called_scope = 0x0, object_ptr = 0x0}}, func = {function = 
0x0, fetch_args = 0x0, object = 0x0, fci = {size = 0,
        function_table = 0x0, function_name = 0x0, symbol_table = 0x0, retval_ptr_ptr = 0x0, param_count = 0, params = 0x0, object_ptr = 0x0, no_separation = 0 '\000'}, 
fcc = {initialized = 0 '\000', function_handler = 0x0,
        calling_scope = 0x0, called_scope = 0x0, object_ptr = 0x0}, values = 0x0}, into = 0x0}, named_rewrite_template = 0x0}


(gdb) n
515                     if (stmt->active_query_string && stmt->active_query_string != stmt->query_string) {


(gdb) p stmt
$12 = (pdo_stmt_t *) 0x2aaaffffffff
(gdb) p *stmt
Cannot access memory at address 0x2aaaffffffff

------------------------------------------------------------------------
[2012-09-12 19:17:09] Ew6jQ8tSJhf3 at dyweni dot com

Description:
------------
PHP 5.4.6
Microsoft SQL Server ODBC Driver V1.0 for Linux

PHP Segfaults while executing the call '$sth->execute()'

GDB Backtrace is:


Program received signal SIGSEGV, Segmentation fault.
zim_PDOStatement_execute (ht=<value optimized out>, return_value=0x2aaaab284210, 
return_value_ptr=<value optimized out>, 
this_ptr=<value optimized out>, return_value_used=<value optimized out>)
    at /usr/src/debug/php-5.4.6/ext/pdo/pdo_stmt.c:515
515                     if (stmt->active_query_string && stmt-
>active_query_string != stmt->query_string) {
(gdb) bt
#0  zim_PDOStatement_execute (ht=<value optimized out>, 
return_value=0x2aaaab284210, return_value_ptr=<value optimized out>, 
this_ptr=<value optimized out>, return_value_used=<value optimized out>)
    at /usr/src/debug/php-5.4.6/ext/pdo/pdo_stmt.c:515
#1  0x00000000006005e5 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x2aaaab250060) at /usr/src/debug/php-
5.4.6/Zend/zend_vm_execute.h:642
#2  0x000000000060643e in execute (op_array=0x2aaaab282fc8) at 
/usr/src/debug/php-5.4.6/Zend/zend_vm_execute.h:410
#3  0x00000000005d1a8e in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /usr/src/debug/php-5.4.6/Zend/zend.c:1289
#4  0x0000000000576c38 in php_execute_script (primary_file=0x7fffffffc190) at 
/usr/src/debug/php-5.4.6/main/main.c:2473
#5  0x00000000006785ed in do_cli (argc=2, argv=0x7fffffffd4b8) at 
/usr/src/debug/php-5.4.6/sapi/cli/php_cli.c:988
#6  0x0000000000678f6d in main (argc=2, argv=0x7fffffffd4b8) at 
/usr/src/debug/php-5.4.6/sapi/cli/php_cli.c:1364


Valgrind Output is:

==9423== Memcheck, a memory error detector
==9423== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==9423== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==9423== Command: php test.php
==9423==
==9423== Invalid read of size 8
==9423==    at 0xA7588B4: zim_PDOStatement_execute (pdo_stmt.c:515)
==9423==    by 0x6005E4: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:642)
==9423==    by 0x60643D: execute (zend_vm_execute.h:410)
==9423==    by 0x5D1A8D: zend_execute_scripts (zend.c:1289)
==9423==    by 0x576C37: php_execute_script (main.c:2473)
==9423==    by 0x6785EC: do_cli (php_cli.c:988)
==9423==    by 0x678F6C: main (php_cli.c:1364)
==9423==  Address 0x10000008f is not stack'd, malloc'd or (recently) free'd
==9423==
==9423==
==9423== Process terminating with default action of signal 11 (SIGSEGV)
==9423==  Access not within mapped region at address 0x10000008F
==9423==    at 0xA7588B4: zim_PDOStatement_execute (pdo_stmt.c:515)
==9423==    by 0x6005E4: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:642)
==9423==    by 0x60643D: execute (zend_vm_execute.h:410)
==9423==    by 0x5D1A8D: zend_execute_scripts (zend.c:1289)
==9423==    by 0x576C37: php_execute_script (main.c:2473)
==9423==    by 0x6785EC: do_cli (php_cli.c:988)
==9423==    by 0x678F6C: main (php_cli.c:1364)
==9423==  If you believe this happened as a result of a stack
==9423==  overflow in your program's main thread (unlikely but
==9423==  possible), you can try to increase the size of the
==9423==  main thread stack using the --main-stacksize= flag.
==9423==  The main thread stack size used in this run was 10485760.
==9423==
==9423== HEAP SUMMARY:
==9423==     in use at exit: 4,021,443 bytes in 19,132 blocks
==9423==   total heap usage: 22,569 allocs, 3,437 frees, 5,755,940 bytes 
allocated




Test script:
---------------
<?php

$pdo = new PDO('odbc:TestDB', "TestUser", "TestPassword");
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

$stmt = 'SELECT fid, original_filename, dateUploaded, filesize, client FROM upload ORDER BY dateUploaded DESC';
$sth = $pdo->prepare($stmt);
$sth->execute();
var_dump($sth->fetchAll());





Expected result:
----------------
The script should output the results from $sth->fetchAll.

Actual result:
--------------
The script crashes with a Segmentation Fault.



------------------------------------------------------------------------



--
Edit this bug report at https://bugs.php.net/bug.php?id=63075&edit=1
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.