#33533 [Fbk]: PDO_ODBC: Segmentation Fault with selecting informix text column

ID: 33533 Updated by: wez@php.net Reported By: scott dot barnett at thuringowa dot qld dot gov dot au Status: Feedback Bug Type: PDO related Operating System: CentOS 4.1 / Redhat Enterprise 4 PHP Version: 5CVS-2005-07-04 Assigned To: wez New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2005-09-10 21:47:04] 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-08-03 08:41:40] sniper@php.net Wez, the fix didn't quite fix it? :) (note to myself: need to get my eyes checked) ------------------------------------------------------------------------ [2005-08-03 06:32:45] 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-07-19 17:27:19] 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-07-19 05:42:25] 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. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/33533 -- Edit this bug report at http://bugs.php.net/?id=33533&edit=1