|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #35144 odbc_connect segmentation fault
Submitted: 2005-11-07 22:25 UTC Modified: 2005-11-21 23:51 UTC
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: rberquist at sbdrepro dot com Assigned:
Status: Not a bug Package: ODBC related
PHP Version: 5CVS-2005-11-07 (snap) OS: Highly customized RH
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.
Block user comment
Status: Assign to:
Bug Type:
From: rberquist at sbdrepro dot com
New email:
PHP Version: OS:


 [2005-11-07 22:25 UTC] rberquist at sbdrepro dot com
As reported in Bug 34716, but I have a backtrace for you.

PHP/5.1.0RC5-dev (snapshot php5-200511071930)

php compiled with
./configure --with-apxs2=/usr/sbin/apxs --with-mysql=shared --with-unixODBC=shared --enable-debug

When accessing the script via brower or command line, results in a segfault.

`isql Customer -v` results as expected and able to execute queries.

Reproduce code:

//database connection
if (!$conn)
        {exit("Connection Failed: " . $conn);}

echo "Test";

Expected result:
I expect it to simply connect, print Test, then disconnect.

Actual result:
Segmentation fault with no output.

(gdb) bt
#0  0xb6eaa370 in ?? ()
#1  0xb6eea7b1 in ISAMOpen () from /usr/local/lib/
#2  0xb6eddace in SQLConnect () from /usr/local/lib/
#3  0xb6f3c26e in SQLConnect (connection_handle=0x8430540,
    server_name=0x842647c "CUSTOMER", name_length1=-3,
    user_name=0x84264fc "tsi", name_length2=-3, authentication=0x8426574 "",
    name_length3=-3) at SQLConnect.c:3819
#4  0xb6f8f7dc in odbc_sqlconnect (conn=0xbfffacb0, db=0x842647c "CUSTOMER",
    uid=0x84264fc "tsi", pwd=0x8426574 "", cur_opt=2, persistent=0)
    at /home/rberquist/php5-200511071930/ext/odbc/php_odbc.c:2174
#5  0xb6f900c4 in odbc_do_connect (ht=3, return_value=0x8434a94,
    return_value_ptr=0x0, this_ptr=0x0, return_value_used=1, persistent=0)
    at /home/rberquist/php5-200511071930/ext/odbc/php_odbc.c:2373
#6  0xb6f8f4d7 in zif_odbc_connect (ht=3, return_value=0x8434a94,
    return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
    at /home/rberquist/php5-200511071930/ext/odbc/php_odbc.c:2060
#7  0x0826b846 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffae10)
    at zend_vm_execute.h:188
#8  0x0826e50f in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xbfffae10)
    at zend_vm_execute.h:1578
#9  0x0826b4f6 in execute (op_array=0x8430444) at zend_vm_execute.h:88
#10 0x08243a0c in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /home/rberquist/php5-200511071930/Zend/zend.c:1087
#11 0x082025b2 in php_execute_script (primary_file=0xbfffd230)
    at /home/rberquist/php5-200511071930/main/main.c:1677
#12 0x082b17c6 in main (argc=2, argv=0xbfffd314)
    at /home/rberquist/php5-200511071930/sapi/cli/php_cli.c:1041

(gdb) frame 9
#9  0x0826b4f6 in execute (op_array=0x8430444) at zend_vm_execute.h:88
88                      if (EX(opline)->handler(&execute_data TSRMLS_CC) > 0) {
(gdb) print (char *)(executor_globals.function_state_ptr->function)->common.function_name
$1 = 0xb6f957e0 "odbc_connect"
(gdb) print (char *)executor_globals.active_op_array->function_name
$2 = 0x0
(gdb) print (char *)executor_globals.active_op_array->filename
$3 = 0x843459c "/opt/web/test2.php"


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2005-11-07 22:49 UTC]
Please try using this CVS snapshot:
For Windows:

 [2005-11-07 23:06 UTC]
Can you also try PDO_ODBC to see if it has a similar issue?
 [2005-11-07 23:50 UTC] rberquist at sbdrepro dot com
The latest snapshot is installed along with PDO and pdo_odbc. pdo_odbc was compile with 
./configure --with-unixODBC
Php (php5-200511072130) was compiled the same as before.

Using pdo_mysql connects fine to a mysql database. However, using odbc with the third party provided driver(Thoroughbred Proprietary DBMS), I'm getting segfaults again. However, still no problems using isql. The backtrace of using pdo is as follows. Please let me know if you would like another backtrace of just the vanilla odbc without pdo using the latest snapshot. I also have odbc trace files if needed.

#0  0x00000000 in ?? ()
#1  0xb6f66f05 in extract_sql_error (henv=0x0, hdbc=0x8434a78, hstmt=0x0,
    connection=0x8431480, head=0x84319f0, return_code=1) at __info.c:4365
#2  0xb6f67976 in function_return_ex (level=2, handle=0x8431480, ret_code=1,
    save_to_diag=138613888) at __info.c:4998
#3  0xb6f3ef17 in SQLDriverConnect (hdbc=0x8431480, hwnd=0x0,
    conn_str_in=0x8436bcc "DSN=CUSTOMER;UID=tsi", len_conn_str_in=-27102,
    conn_str_out=0xbfff95e0 "DSN=CUSTOMER;DBQ=.;HOST=;UID=tsi;SERVER=NotTheServer", conn_str_out_max=1023, ptr_conn_str_out=0xbfff95de,
    driver_completion=0) at SQLDriverConnect.c:1463
#4  0xb6ef1716 in pdo_odbc_handle_factory (dbh=0x84273fc, driver_options=0x0)
    at /home/rberquist/PDO_ODBC-1.0RC2/odbc_driver.c:395
#5  0x080d1182 in zif_PDO_dbh_constructor (ht=1, return_value=0x8435f3c,
    return_value_ptr=0x0, this_ptr=0x84273bc, return_value_used=0)
    at /home/rberquist/php5-200511072130/ext/pdo/pdo_dbh.c:374
#6  0x0826b846 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfff9ed0)
#7  0x0826bd92 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfff9ed0)
    at zend_vm_execute.h:310
#8  0x0826b4f6 in execute (op_array=0x8431304) at zend_vm_execute.h:88
#9  0x08243a0c in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /home/rberquist/php5-200511072130/Zend/zend.c:1087
#10 0x082025b2 in php_execute_script (primary_file=0xbfffc2f0)
    at /home/rberquist/php5-200511072130/main/main.c:1677
#11 0x082b17c6 in main (argc=2, argv=0xbfffc3d4)
    at /home/rberquist/php5-200511072130/sapi/cli/php_cli.c:1041
 [2005-11-08 21:44 UTC]
Are you absolutely sure this isn't a bug in unixODBC? As the backtrace would suggest it's crashing in there, not in PHP.
 [2005-11-08 22:01 UTC] rberquist at sbdrepro dot com
Well, using the isql command, the odbc works. With PHP, it does not. This is what has led me to believe that it's not a unixODBC issue. Also, setting up a mysql DSN entry in odbc.ini has proven successful. It connects fine and allows query execution.

I've recently found out that it could possibly be the driver and am currently working with the third party developers at the moment. The driver is /usr/local/lib/, which is referenced in the bt. However, they contend that if it works with isql, then the problem is not with the driver.

If you have any other ideas for troubleshooting and pinpointing the issue, I'd be happy to comply.
 [2005-11-20 19:40 UTC]
Please try using this CVS snapshot:
For Windows:

 [2005-11-21 17:16 UTC] rberquist at sbdrepro dot com
Nope, still segfaults. BT is below.

I've also attempted to switch to iodbc. I reformatted the odbc.ini files. Using iodbctest, I can connect and query fine. However, after a recompile of php and accessed with php cli, the script executes everything up to the odbc_connect statement. It then stops with no further output as if frozen. No errors are generated or segfaults.
If accessed with a browser, the browser simply waits. I have made the phpinfo temporarily available at the following URL.

(gdb) bt
#0  0xb6ec2370 in ?? ()
#1  0xb6f027b1 in ISAMOpen () from /usr/local/lib/
#2  0xb6ef5ace in SQLConnect () from /usr/local/lib/
#3  0xb6f5526e in SQLConnect (connection_handle=0x843a468,
    server_name=0x843047c "CUSTOMER", name_length1=-3,
    user_name=0x843ea44 "tsi", name_length2=-3, authentication=0x843eabc "",
    name_length3=-3) at SQLConnect.c:3819
#4  0xb6fa87dc in odbc_sqlconnect (conn=0xbfff7600, db=0x843047c "CUSTOMER",
    uid=0x843ea44 "tsi", pwd=0x843eabc "", cur_opt=2, persistent=0)
    at /home/rberquist/php5-200511211530/ext/odbc/php_odbc.c:2174
#5  0xb6fa90c4 in odbc_do_connect (ht=3, return_value=0x843eaf4,
    return_value_ptr=0x0, this_ptr=0x0, return_value_used=1, persistent=0)
    at /home/rberquist/php5-200511211530/ext/odbc/php_odbc.c:2373
#6  0xb6fa84d7 in zif_odbc_connect (ht=3, return_value=0x843eaf4,
    return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
    at /home/rberquist/php5-200511211530/ext/odbc/php_odbc.c:2060
#7  0x082751ab in zend_do_fcall_common_helper_SPEC (execute_data=0xbfff7760)
    at zend_vm_execute.h:188
#8  0x08277e74 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xbfff7760)
    at zend_vm_execute.h:1578
#9  0x08274e5b in execute (op_array=0x843a36c) at zend_vm_execute.h:88
#10 0x0824d2c0 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /home/rberquist/php5-200511211530/Zend/zend.c:1090
---Type <return> to continue, or q <return> to quit---
#11 0x0820bd51 in php_execute_script (primary_file=0xbfff9b80)
    at /home/rberquist/php5-200511211530/main/main.c:1704
#12 0x082bb12a in main (argc=2, argv=0xbfff9c64)
    at /home/rberquist/php5-200511211530/sapi/cli/php_cli.c:1039
 [2005-11-21 18:27 UTC]
So it doesn't crash, just hangs?
 [2005-11-21 18:34 UTC] rberquist at sbdrepro dot com
It crashes with unixODBC but hangs with iodbc.
 [2005-11-21 20:00 UTC]
In what will probably make sniper choke on his kossu, I took a look into this.  From what I can tell PHP's still doing the right thing via the odbc_connect call, and the error is in the ISAM driver.  I'd mark this not a PHP bug, but I'll leave that to the more active developers to confirm/deny.
 [2005-11-21 22:47 UTC] rberquist at sbdrepro dot com
I think we can safely say this is not a PHP bug. I apologize for wasting any time, but you all ahve been great.

I've written a python script using the module. It also segfaults at 
0xb73a97b1 in ISAMOpen () from /usr/local/lib/

The company providing the driver swears the driver is fine because "It works fine on our system!". However, it spits a segfault in unixODBC using any application and hangs in iodbc with any application. But they are still hanging onto the "If isql and iodbctest work fine, then it's not a driver issue" philosophy.

Again, thank you for your time and you may close this bug if/when you deem necessary.
 [2005-11-21 23:51 UTC]
Didn't I suggest earlier that this isn't PHP bug? :)
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Fri Feb 28 16:01:29 2020 UTC