php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #45819 Segmentation fault in PHP + unixODBC on x86_64
Submitted: 2008-08-14 11:17 UTC Modified: 2008-11-07 11:50 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: gory at mail dot bg Assigned: iodbc (profile)
Status: Closed Package: ODBC related
PHP Version: 5.2.6 OS: CentOS 5.2 (x86_64)
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: gory at mail dot bg
New email:
PHP Version: OS:

 

 [2008-08-14 11:17 UTC] gory at mail dot bg
Description:
------------
Apache/2.2.9
PHP 5.2.6
unixODBC 2.2.12
all compiled from Fedora SRPM on CentOS 5.2 x86_64
Sybase SQL Anywhere 11 or 9 ODBC driver.
Segmentation fault in odbc_fetch_row
Same query runs fine in isql and retrieve data.

Reproduce code:
---------------
<?php
define("_AW_DSN", "******");
define("_AW_UID", "******");
define("_AW_PWD", "******");

	$product = 1;	
         $qry = "
  SELECT mod_id,
         mod_product
    FROM aw_products_modules
   WHERE mod_product = " . $product . " ORDER BY mod_order";

	$db_handle = odbc_connect( _AW_DSN, _AW_UID, _AW_PWD, SQL_CUR_USE_ODBC );
	$l_result = odbc_exec( $db_handle , $qry );
	
	while( odbc_fetch_row( $l_result) != FALSE ) {		
		echo "<br />" . odbc_result( $l_result, "mod_id" );
	}	
?> 


Expected result:
----------------
Print few rows just for test.

Actual result:
--------------
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47541093602656 (LWP 7696)]
0x00002b3d0396f105 in memcpy () from /lib64/libc.so.6
(gdb) bt
#0  0x00002b3d0396f105 in memcpy () from /lib64/libc.so.6
#1  0x00002aaab0002e63 in fetch_row (cl_statement=0x2aaaac00f8a0, row_number=0, offset=0) at /usr/include/bits/string3.h:51
#2  0x00002aaab00031a1 in fetch_rowset (cl_statement=0x2aaaac00f8a0, rows_in_set=1, row_offset=0, fetched_rows=0x7fffa90d48b4,
    row_status_array=0x7fffa90d4a70, rows_fetched_ptr=0x1) at SQLExtendedFetch.c:464
#3  0x00002aaab00033d7 in do_fetch_scroll (cl_statement=0x2aaaac00f8a0, fetch_orientation=1, fetch_offset=1, row_status_ptr=0x2b3d16983880,
    rows_fetched_ptr=0x1, ext_fetch=1) at SQLExtendedFetch.c:749
#4  0x00002aaab00038db in CLExtendedFetch (statement_handle=0x0, f_fetch_type=0, irow=12, pcrow=0x2b3d16983880, rgf_row_status=0x0)
    at SQLExtendedFetch.c:927
#5  0x00002b3d13f50546 in SQLExtendedFetch (statement_handle=0x2aaaac00f230, f_fetch_type=1, irow=1, pcrow=0x7fffa90d4a6c, rgf_row_status=0x7fffa90d4a70)
    at SQLExtendedFetch.c:290
#6  0x00002b3d13d13f13 in zif_odbc_fetch_row (ht=1, return_value=0x2b3d16893550, return_value_ptr=<value optimized out>, this_ptr=<value optimized out>,
    return_value_used=<value optimized out>) at /usr/src/debug/php-5.2.6/ext/odbc/php_odbc.c:1706
#7  0x00002b3d0ce98612 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fffa90d4f10) at /usr/src/debug/php-5.2.6/Zend/zend_vm_execute.h:200
#8  0x00002b3d0ce8840c in execute (op_array=0x2b3d168916f0) at /usr/src/debug/php-5.2.6/Zend/zend_vm_execute.h:92
#9  0x00002b3d0ce68d73 in zend_execute_scripts (type=8, retval=<value optimized out>, file_count=3) at /usr/src/debug/php-5.2.6/Zend/zend.c:1134
#10 0x00002b3d0ce29368 in php_execute_script (primary_file=0x7fffa90d73f0) at /usr/src/debug/php-5.2.6/main/main.c:2005
#11 0x00002b3d0ceeb53d in php_handler (r=0x2b3d169690e8) at /usr/src/debug/php-5.2.6/sapi/apache2handler/sapi_apache2.c:629
#12 0x00002b3d019fad4a in ap_run_handler (r=0x2b3d169690e8) at /usr/src/debug/httpd-2.2.9/server/config.c:157
#13 0x00002b3d019fe1cc in ap_invoke_handler (r=0x2b3d169690e8) at /usr/src/debug/httpd-2.2.9/server/config.c:372
#14 0x00002b3d01a08eb8 in ap_process_request (r=0x2b3d169690e8) at /usr/src/debug/httpd-2.2.9/modules/http/http_request.c:258
#15 0x00002b3d01a060e0 in ap_process_http_connection (c=0x2b3d168c83d8) at /usr/src/debug/httpd-2.2.9/modules/http/http_core.c:190
#16 0x00002b3d01a021a2 in ap_run_process_connection (c=0x2b3d168c83d8) at /usr/src/debug/httpd-2.2.9/server/connection.c:43
#17 0x00002b3d01a0d068 in child_main (child_num_arg=<value optimized out>) at /usr/src/debug/httpd-2.2.9/server/mpm/prefork/prefork.c:650
#18 0x00002b3d01a0d269 in make_child (s=0x2b3d0ae87dc8, slot=0) at /usr/src/debug/httpd-2.2.9/server/mpm/prefork/prefork.c:690
#19 0x00002b3d01a0debd in ap_mpm_run (_pconf=<value optimized out>, plog=<value optimized out>, s=<value optimized out>)
    at /usr/src/debug/httpd-2.2.9/server/mpm/prefork/prefork.c:966
#20 0x00002b3d019e8183 in main (argc=2, argv=0x7fffa90d79e8) at /usr/src/debug/httpd-2.2.9/server/main.c:730


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-11-07 11:50 UTC] iodbc@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

PHP versions upto 5.2.6 do not use the ODBC 3.52 API specification and 
are therefore not usable in a 64bit ODBC environment.

Fix is in CVS in 5.2, 5.3 and HEAD branch.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat May 11 01:01:31 2024 UTC