php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #33533 PDO_ODBC: Segmentation Fault with selecting informix text column
Submitted: 2005-07-01 08:37 UTC Modified: 2005-09-24 01:00 UTC
Votes:3
Avg. Score:4.3 ± 0.5
Reproduced:3 of 3 (100.0%)
Same Version:2 (66.7%)
Same OS:1 (33.3%)
From: scott dot barnett at thuringowa dot qld dot gov dot au Assigned: wez (profile)
Status: No Feedback Package: PDO related
PHP Version: 5CVS-2005-07-04 OS: CentOS 4.1 / Redhat Enterprise 4
Private report: No CVE-ID: None
View Add Comment Developer Edit
Have you experienced this issue?
Rate the importance of this bug to you:

 [2005-07-01 08:37 UTC] scott dot barnett at thuringowa dot qld dot gov dot au 
Description:
------------
Apache 2.0.54
PHP 5.0.4
UnixODBC 2.2.11
Informix SDK 2.90.UC1


I'm trying to use ODBC to query an informix server. I can select char or int columns, and I can perform inserts on text fields fine. When I do a select on a text column the query executes fine. When I try and use any fetch function (eg. odbc_fetch_into, odbc_fetch_object) on the result, it seg faults.

Using isql at the shell on the web server works perfectly.

Reproduce code:
---------------
$sql="select * from tablename";

$result = odbc_prepare ($conn_id, $sql);
$result=odbc_exec($db,$sql);

while(odbc_fetch_into($result, $myarray)){
    for($i=0; $i<3; $i++){
        print "$myarray[$i] ";
    }
}

Expected result:
----------------
The contents of the table to appear! :)

Actual result:
--------------
[notice] child pid 4220 exit signal Segmentation fault (11)

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-07-01 09:38 UTC] sniper@php.net 
Please try using this CVS snapshot:

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

And try with the new PDO (pdo_odbc) extension.
See manual: http://www.php.net/pdo
 [2005-07-04 03:35 UTC] scott dot barnett at thuringowa dot qld dot gov dot au 
Same problem with the latest snapshot.


I've setup pdo_odbc and I get the exact same symptoms, can select char and int fields, but not text or blob. The error that comes up in err_log is different though:

FATAL:  emalloc():  Unable to allocate -2147483648 bytes


2147483648 is the maximum size of a text field. The most characters in any of the tuples in the test table is about 30.
 [2005-07-08 21:09 UTC] wez@php.net 
Please try using this CVS snapshot:

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

I fixed a few things that might have resolved your problem; please try the latest snapshot.  Would be nice to hear back from you ASAP if it doesn't work.
 [2005-07-08 21:14 UTC] wez@php.net 
(those fixes are in PDO_ODBC only)
 [2005-07-12 01:42 UTC] scott dot barnett at thuringowa dot qld dot gov dot au 
With snapshot 200507112030 using the ifx_ functions it comes back with:

[Tue Jul 12 09:34:05 2005] [notice] child pid 2175 exit signal Segmentation fault (11)
[Tue Jul 12 09:34:06 2005] [notice] child pid 2176 exit signal Segmentation fault (11)

I'm having some difficulties with PDO now, it comes back with : "Failed to connect:could not find driver". This is probably just a misconfiguration problem on my end that I haven't managed to track down yet.

Note: When I tryed the latest snapshot I just did a "make install" over the top of the old one.
 [2005-07-12 05:36 UTC] wez@php.net 
Sounds like you're missing an extension=pdo_odbc.so line from your php.ini.

Installing over the top of an existing install is usually ok, provided that you made a fresh, clean build for the new install.
 [2005-07-12 07:40 UTC] scott dot barnett at thuringowa dot qld dot gov dot au 
Rightio, it was user error. I did an strace and I had php.ini in the wrong place, I've corrected it. Previously I configured the extensions dir as a configure option and compiled my own pdo.so and pdo_odbc.so so it worked ok.

"php -m" shows up PDO and pdo_sqlite. I thought PDO was going to be included with PHP and therefore would be in the latest snapshot or do you want me to get it from pear?
 [2005-07-12 12:57 UTC] wez@php.net 
Remove old stuff:

- pear uninstall pdo_odbc
- pear uninstall pdo

Grab a PHP 5.1 snapshot from http://snaps.php.net:

- Extract it
- cd into the dir
- ./configure <your usual options> --with-pdo-odbc=unixODBC
- make
- make install

then test it
 [2005-07-13 01:36 UTC] scott dot barnett at thuringowa dot qld dot gov dot au 
Thanks wez, I've got PDO-ODBC working now with snapshot php5-200507122030.

If I use PDO this shows up in err_log:
FATAL:  emalloc():  Unable to allocate -2147483648 bytes
FATAL:  emalloc():  Unable to allocate -2147483648 bytes
FATAL:  emalloc():  Unable to allocate -2147483648 bytes

If I use the ifx_ functions this shows up in err_log:
[Wed Jul 13 09:26:51 2005] [notice] child pid 15980 exit signal Segmentation fault (11)
[Wed Jul 13 09:26:51 2005] [notice] child pid 15981 exit signal Segmentation fault (11)

Same problems basically, only happens when querying Informix text fields, char and int are fine.
 [2005-07-18 17:19 UTC] wez@php.net 
Can you do that again, this time type in:

bt
f 3
info locals

thanks!
 [2005-07-19 05:27 UTC] scott dot barnett at thuringowa dot qld dot gov dot au 
(gdb) bt
#0  0x0060f7a2 in ?? () from /lib/ld-linux.so.2
#1  0x0064fc76 in kill () from /lib/tls/libc.so.6
#2  0x00ec4f14 in _emalloc (size=2147483648, __zend_filename=0xf5c5b4 "/usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c", __zend_lineno=393, __zend_orig_filename=0x0,
    __zend_orig_lineno=0) at /usr/src/apache/php5-200507122030/Zend/zend_alloc.c:191
#3  0x00d58c90 in odbc_stmt_describe (stmt=0x8a1616c, colno=1) at /usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c:393
#4  0x00d5140c in pdo_stmt_describe_columns (stmt=0x8a1616c) at /usr/src/apache/php5-200507122030/ext/pdo/pdo_stmt.c:168
#5  0x00d508c3 in zif_PDO_query (ht=2, return_value=0x89b3b84, return_value_ptr=0x0, this_ptr=0x89b39dc, return_value_used=1) at /usr/src/apache/php5-200507122030/ext/pdo/pdo_dbh.c:912
#6  0x00f03eaa in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe0d160) at /usr/src/apache/php5-200507122030/Zend/zend_vm_execute.h:184
#7  0x00f04713 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfe0d160) at /usr/src/apache/php5-200507122030/Zend/zend_vm_execute.h:299
#8  0x00f03b8b in execute (op_array=0x89aeaec) at /usr/src/apache/php5-200507122030/Zend/zend_vm_execute.h:87
#9  0x00edd699 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/apache/php5-200507122030/Zend/zend.c:1087
#10 0x00e9c995 in php_execute_script (primary_file=0xbfe0f4e0) at /usr/src/apache/php5-200507122030/main/main.c:1672
#11 0x00f48616 in php_handler (r=0x899fbe0) at /usr/src/apache/php5-200507122030/sapi/apache2handler/sapi_apache2.c:555
#12 0x0809953a in ap_run_handler (r=0x899fbe0) at config.c:152
#13 0x08099905 in ap_invoke_handler (r=0x899fbe0) at config.c:364
#14 0x0808255d in ap_process_request (r=0x899fbe0) at http_request.c:249
#15 0x0807e225 in ap_process_http_connection (c=0x8999948) at http_core.c:251
#16 0x080a2a02 in ap_run_process_connection (c=0x8999948) at connection.c:43
#17 0x08097d15 in child_main (child_num_arg=0) at prefork.c:610
#18 0x08097f09 in make_child (s=0x882ea08, slot=0) at prefork.c:650
#19 0x08097fd0 in startup_children (number_to_start=5) at prefork.c:722
#20 0x080986a3 in ap_mpm_run (_pconf=0xbfe0f830, plog=0x8863190, s=0xbfe0f834) at prefork.c:941
#21 0x0809d7a3 in main (argc=2, argv=0xbfe0f9d4) at main.c:618
(gdb) f 3
#3  0x00d58c90 in odbc_stmt_describe (stmt=0x8a1616c, colno=1) at /usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c:393
393             S->cols[colno].data = emalloc(colsize+1);
(gdb) info locals
S = (pdo_odbc_stmt *) 0x8a16794
col = (struct pdo_column_data *) 0x8a12134
dyn = 0 '\0'
rc = 0
colnamelen = 7
colsize = 2147483647
 [2005-07-19 05:42 UTC] wez@php.net 
I've added an arbitrary limit of 64k per text column for now, so that PHP doesn't kill your apache instance off (it was trying to allocate 2GB + 1 bytes per text column).

It is likely that PDO_ODBC will now truncate any text columns that are longer than 64k; I'm working on a better long term fix.

The very next snapshot should give you a more decent experience until then.
 [2005-07-19 17:27 UTC] wez@php.net 
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

Current CVS (and thus the next snapshot) now handle arbitrary length columns; enjoy!
 [2005-08-03 06:32 UTC] scott dot barnett at thuringowa dot qld dot gov dot au 
Still having build problems. Thanks.

(gdb) bt
#0  0x00000000 in ?? ()
#1  0x002e7ef2 in CLGetData (statement_handle=0x83a5590, column_number=2, target_type=1, target_value=0x83a5a74,
    buffer_length=256, strlen_or_ind=0x83a57c4) at SQLGetData.c:336
#2  0x00498f0c in SQLGetData (statement_handle=0x83a4fb8, column_number=2, target_type=1, target_value=0x83a5a74,
    buffer_length=256, strlen_or_ind=0x83a57c4) at SQLGetData.c:412
#3  0x00d63d9e in odbc_stmt_get_col (stmt=0x83ae01c, colno=1, ptr=0xbff2e70c, len=0xbff2e708, caller_frees=0xbff2e704)
    at /usr/src/apache/php5-200508030230/ext/pdo_odbc/odbc_stmt.c:434
#4  0x00d5caa5 in fetch_value (stmt=0x83ae01c, dest=0x83a7724, colno=1)
    at /usr/src/apache/php5-200508030230/ext/pdo/pdo_stmt.c:447
#5  0x00d5d776 in do_fetch (stmt=0x83ae01c, do_bind=1, return_value=0x834b8cc, how=PDO_FETCH_OBJ, ori=PDO_FETCH_ORI_NEXT,
    offset=0, return_all=0x0) at /usr/src/apache/php5-200508030230/ext/pdo/pdo_stmt.c:870
#6  0x00d60903 in pdo_stmt_iter_get (ce=0x83004e0, object=0x834b94c)
    at /usr/src/apache/php5-200508030230/ext/pdo/pdo_stmt.c:2135
#7  0x00f42baf in ZEND_FE_RESET_SPEC_CV_HANDLER (execute_data=0xbff2ebf0)
    at /usr/src/apache/php5-200508030230/Zend/zend_vm_execute.h:19523
#8  0x00f0f51c in execute (op_array=0x83468fc) at /usr/src/apache/php5-200508030230/Zend/zend_vm_execute.h:87
#9  0x00ee8ec9 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /usr/src/apache/php5-200508030230/Zend/zend.c:1078
#10 0x00ea8058 in php_execute_script (primary_file=0xbff30f70) at /usr/src/apache/php5-200508030230/main/main.c:1672
#11 0x00f53f8e in php_handler (r=0x8337be0) at /usr/src/apache/php5-200508030230/sapi/apache2handler/sapi_apache2.c:562
#12 0x0809953a in ap_run_handler (r=0x8337be0) at config.c:152
#13 0x08099905 in ap_invoke_handler (r=0x8337be0) at config.c:364
#14 0x0808255d in ap_process_request (r=0x8337be0) at http_request.c:249
#15 0x0807e225 in ap_process_http_connection (c=0x8331948) at http_core.c:251
#16 0x080a2a02 in ap_run_process_connection (c=0x8331948) at connection.c:43
#17 0x08097d15 in child_main (child_num_arg=138040732) at prefork.c:610
#18 0x08097f09 in make_child (s=0x81c5a08, slot=0) at prefork.c:650
#19 0x08097fd0 in startup_children (number_to_start=5) at prefork.c:722
#20 0x080986a3 in ap_mpm_run (_pconf=0xbff312c0, plog=0x81fa190, s=0xbff312c4) at prefork.c:941
#21 0x0809d7a3 in main (argc=2, argv=0xbff31464) at main.c:618
 [2005-08-03 08:41 UTC] sniper@php.net 
Wez, the fix didn't quite fix it? :)
(note to myself: need to get my eyes checked)
 [2005-09-10 21:47 UTC] wez@php.net 
That crash looks like the informix libraries are trying to call a NULL callback handler.

There's no way I can debug this without being able to sit down at the machine with my hands on gdb; Can I get a non-privileged account on that machine, so that I can build a CLI php and test it?
 [2005-09-16 20:34 UTC] wez@php.net 
I've poked around, and this really looks like either a unixODBC or informix bug (perhaps both).

It's quite possible that PDO is doing something that unixODBC or informix doesn't like, but the problem is that unixODBC is trying to call a function that is set to NULL.

(gdb) info linkmap
00000000
00000000 /lib/libcrypt.so.1
00000000 /usr/lib/libz.so.1
00000000 /lib/libresolv.so.2
00000000 /lib/tls/libm.so.6
00000000 /lib/libnsl.so.1
00a40000 /usr/local/lib/libodbc.so.1
00000000 /lib/libdl.so.2
00000000 /lib/tls/libpthread.so.0
00000000 /lib/tls/libc.so.6
00000000 /lib/ld-linux.so.2
005e1000 /usr/lib/gconv/ISO8859-1.so
001f7000 /opt/informix/lib/cli/iclis09b.so
007d5000 /opt/informix/lib/esql/libifgls.so
00d89000 /opt/informix/lib/esql/libifglx.so
0039e000 /lib/libnss_files.so.2
00198000 /opt/informix/lib/esql/igo4a304.so
0098d000 /usr/local/lib/libodbccr.so.1

(gdb) where
#0  0x00000000 in ?? ()

fault here, calling a NULL function.

#1  0x00990ef2 in CLGetData (statement_handle=0x8faec48, column_number=2, target_type=1,
    target_value=0x8fb383c, buffer_length=256, strlen_or_ind=0x8fb36c4) at SQLGetData.c:336

this address is in libodbccr.so.1, part of unix odbc

#2  0x00a58f0c in SQLGetData (statement_handle=0x8fae670, column_number=2, target_type=1,
    target_value=0x8fb383c, buffer_length=256, strlen_or_ind=0x8fb36c4) at SQLGetData.c:412

this address is in libodbccr.so.1, part of unix odbc

#3  0x080abd8a in odbc_stmt_get_col (stmt=0x8fb7f94, colno=1, ptr=0xbfe6083c, len=0xbfe60838,
    caller_frees=0xbfe60834) at /home/wez/php5-200509161630/ext/pdo_odbc/odbc_stmt.c:434

this address is in the pdo odbc driver.


What I suspect is the problem is that either informix doesn't set a flag to tell unixodbc about the functions it supports, or that unixodbc doesn't respect a flag that it should.

Ultimately, unixODBC should catch that NULL and report an error properly.

I don't think I can do anything while this crash problem exists, and I think you should file a bug report with the unix ODBC guys so that we can figure out what is going wrong, and then we can figure out how to make things work for you.

I'm happy to co-operate with them in tracking this down.
 [2005-09-24 01:00 UTC] php-bugs at lists dot php dot net 
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Tue Apr 16 04:01:27 2024 UTC