Bug #2642 Updated: OpenLink odbc_exec() segfaults

ID: 2642 Updated by: sander@php.net Reported By: rlynch@ignitionstate.com -Status: Assigned +Status: Bogus Bug Type: ODBC related Operating System: Linux ruby.inet-images.com 2.2.5 PHP Version: 3.0.12 Assigned To: kara New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately, PHP 3 is no longer supported. Please download the latest version of PHP 4 from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. Previous Comments: ------------------------------------------------------------------------ [1999-11-28 12:10:30] kara@cvs.php.net From the backtrace it seems that you're trying to do a query on an invalid connection #3 php3i_odbc_get_conn (list=0x80c4240, ind=0) ^^^^ From there on, things get screwed up. Maybe it is related to PHP being compiled as CGI? ------------------------------------------------------------------------ [1999-10-30 22:30:08] rlynch@ignitionstate.com PHP compiled as CGI: ./configure --with-debugging --with-openlink=/home/l/i/lie/src/openlink (No other switches.) I am naive user, on a good day :-) OpenLink clients (and sdk) attempting to access NT box. An MS Access DSN via an OpenLink DSN. I am able to successfully connect and execute the same query via OpenLink's odbctest, and everything works hunky-dorie with PHP not in the picture, so am reasonably certain PHP is involved somehow. When run through the browser, it segfaults (I assume) as well as from the command line (backtrace below). The browser *does* run php through a shell script that sets up the OpenLink environment variables, which are also in my .bashrc, but I doubt that is involved since (A) the odbc_connect would puke (and it did until I got that worked out) and (B) it segfaults from the command line where this shell script is not involved. The actual query is: select faqID, FAQ.LearningOutcomeID, Question, Answer, LearningOutcome, Concepts.ConceptID, Concept, Sessions.SessionID, SessionName, Topics.TopicID, TopicName from FAQ, LearningOutcomes, Concepts, Sessions, Topics where FAQ.LearningOutcomeID = LearningOutcomes.LearningOutcomeID and LearningOutcomes.SessionID = Concepts.SessionID and LearningOutcomes.AIMRid = Concepts.AIMRid and Concepts.SessionID = Sessions.SessionID and Sessions.TopicID = Topics.TopicID order by FAQ.LearningOutcomeID, FAQid; if that helps. It's a mite long, but (as stated) odbctest is quite happy with it... A copy of the Linux (client-side) scripts and the odbc.ini are available at: http://l-i-e.com/openlink/ The NT (server) openlink.log is at: http://208.197.9.167:8080/xamprep2k/openlink.log And, finally, here is a backtrace: [lie@ruby src]$ gdb /home/l/i/lie/cgi/bin/php ./core GNU gdb 4.17.0.11 with Linux support Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `/home/l/i/lie/cgi/bin/php bfaq.php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libgd.so.1...done. Reading symbols from /usr/lib/libgdbm.so.2...done. Reading symbols from /home/l/i/lie/src/openlink/lib/libiodbc.so.2...done. Reading symbols from /lib/libpam.so.0...done. Reading symbols from /lib/libm.so.6...done. Reading symbols from /lib/libdl.so.2...done. Reading symbols from /lib/libcrypt.so.1...done. Reading symbols from /lib/libnsl.so.1...done. Reading symbols from /lib/libresolv.so.2...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/libpthread.so.0...done. Reading symbols from /lib/ld-linux.so.2...done. #0 _php3_hash_indestroy (ht=0x0, function=0x80a3619 "php3_hash.c", line=935) at php3_hash.c:83 83 if (ht->indestroy) { (gdb) bt #0 _php3_hash_indestroy (ht=0x0, function=0x80a3619 "php3_hash.c", line=935) at php3_hash.c:83 #1 0x805c273 in _php3_hash_index_find (ht=0x0, h=0, pData=0xbfffe75c) at php3_hash.c:935 #2 0x8061b39 in php3_list_do_find (list=0x0, id=0, type=0xbfffe780) at list.c:82 #3 0x80838a1 in php3i_odbc_get_conn (list=0x80c4240, ind=0) at functions/unified_odbc.c:506 #4 0x8084510 in php3_odbc_exec (ht=0x80dde68, return_value=0x80b31f8, list=0x80c4240, plist=0x80c4200) at functions/unified_odbc.c:1025 #5 0x805144c in phpparse () at control_structures_inline.h:934 #6 0x805a828 in php3_parse (yyin=0x80d0e30) at main.c:1553 #7 0x805adf3 in main (argc=2, argv=0xbffffb24) at main.c:1862 #8 0x400f4cb3 in __libc_start_main (main=0x805a934 <main>, argc=2, argv=0xbffffb24, init=0x804abf0 <_init>, fini=0x8092c6c <_fini>, rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffffb1c) at ../sysdeps/generic/libc-start.c:78 (gdb) quit Whew. Hope that's all you need. Let me know if not, and I'll try to generate/copy/provide anything more. I'm going to send all this to the OpenLink folks as well, just so they are aware of it: They' ve been *extremely* helpful to me to get this far. (It took me a couple weeks just to be able to connect.) ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=2642&edit=1