php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #2642 OpenLink odbc_exec() segfaults
Submitted: 1999-10-30 22:30 UTC Modified: 2002-06-16 14:17 UTC
From: rlynch at ignitionstate dot com Assigned:
Status: Not a bug Package: ODBC related
PHP Version: 3.0.12 OS: Linux ruby.inet-images.com 2.2.5
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: rlynch at ignitionstate dot com
New email:
PHP Version: OS:

 

 [1999-10-30 22:30 UTC] rlynch at ignitionstate dot 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.)

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [1999-11-28 12:10 UTC] kara at cvs dot php dot 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?

 [2002-06-16 14:17 UTC] sander@php.net
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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 00:01:29 2024 UTC