Bug #7847 Updated: OCI8 support with Oracle 8.1.5 doesn't work

ID: 7847 Updated by: lobbin Old Summary: OCI8 support with Oracle 8.1.5 doesn't work Reported By: msquillace@sogei.it Old Status: Open Status: Feedback Bug Type: OCI8 related Operating System: AIX 4.2 PHP Version: 4.0.3pl1 New Comment: Can you reproduce this with PHP 4.1.1? Previous Comments: ------------------------------------------------------------------------ [2001-01-08 09:13:58] msquillace@sogei.it Downloaded php4-200101080345 this morning and recompiled libphp4.so. The problems remain. I had to find out an AIX 4.3.3 server in order to keep the project in schedule; I successfully built a STATIC php module there, including a working OCI8 extension. I couldn't build a working AIX 4.3 DSO even though I followed the advice in bug #4630. ------------------------------------------------------------------------ [2001-01-07 19:42:19] sniper@php.net Does this happen with latest snapshot from http://snaps.php.net/ ?? --Jani ------------------------------------------------------------------------ [2000-12-07 05:46:25] msquillace@sogei.it I have been testing several other extensions and standard PHP functions on my AIX 4.2 server, and discovered the following: 1) can't successfully build PHP with socket support 2) fsockopen fails as described for OCI8 3) curl fails as described for OCI8 Since OCIServerAttach must certainly work with sockets at some point, may this point to some kind of incompatibility between PHP and AIX 4.2 socket code? ------------------------------------------------------------------------ [2000-11-22 11:10:55] msquillace@sogei.it Made some other tests ... 1) Recompiled gcc from sources, using both the binary AIX 4.2 gcc distro and the standard IBM cc compiler. Regenerated apache+mod_php+ oci8 support with the new gcc binary. I observed the exact same problems. 2) Returned to using the binary AIX 4.2 gcc distro from aixpdslib.seas.ucla.edu, I liberally inserted fprintf debug statements in oci8.c in order to pinpoint the instruction causing the error. Here is my final trace: Entering oci_do_connect function ... Before ecalloc After ecalloc Before _oci_open_server Entering _oci_open_server function ... Before zend_hash_find After zend_hash_find Before OCIHandleAlloc After OCIHandleAlloc Before OCIServerAttach pServer:20123f9c pError:2012420c dbname:f40_7 dbnamel:5 As you can see, oci8.c never returns from the OCIServerAttach call. The arguments to that call, listed on the last trace line, look valid enough to me ... (To Thies Arntzen: I receive all your emails, but our e-mail server apparently cannot deliver my replies to mail2.easyspace.com and is bouncing them all back ... please post your advice here) ------------------------------------------------------------------------ [2000-11-21 08:36:31] msquillace@sogei.it I'm sorry to report AIX doesn't include truss nor strace. I found out a program called sctrace that you can buy from The Kernel Group for $795 (single CPU) and seems to do what truss does for Solaris and strace does for Linux, but we don't have it here. Only thing I could do was using the trace program, as per Jason's advice: trace -a -o /tmp/my_trace_log; /opt/www/bin/httpd -X; trcstop trcrpt -o /tmp/my_trace -v /tmp/my_trace_log Here follows what I believe to be the most interesting section: (about 55000 lines deleted) 107 lookuppn: /ora815/network/admin/sqlnet.ora 107 lookuppn: file not found 104 return from access. error ENOENT [73 usec] 101 access LR = D0FE3AB4 108 access /ora815/network/admin/sqlnet.ora--------- 107 lookuppn: /ora815/network/admin/ldap.ora 107 lookuppn: file not found 104 return from access. error ENOENT [45 usec] 101 access LR = D0FE3AB4 108 access /ora815/network/admin/ldap.ora--------- 107 lookuppn: /.sqlnet.ora 107 lookuppn: file not found 104 return from access. error ENOENT [20 usec] 101 access LR = D0FE3AB4 108 access /.sqlnet.ora--------- 107 lookuppn: /etc/intchg.ora 107 lookuppn: file not found 104 return from access. error ENOENT [56 usec] 101 access LR = D0FE3AB4 108 access /etc/intchg.ora--------- ([Oracle] looks for several other files, until it finds tnsnames.ora) 101 open LR = D02ACB30 107 lookuppn: /ora815/network/admin/tnsnames.ora 10D vfs number=0022, inode number=296E 15B open /ora815/network/admin/tnsnames.ora fd=4 RDONLY 104 return from open [85 usec] 101 kioctl LR = D02D9B28 14C ioctl fd=4 command=5800 arg=0000 104 return from kioctl. error ENOTTY [10 usec] 101 kfcntl LR = D02D71F0 137 fcntl /ora815/network/admin/tnsnames.ora F_SETFD return value 0000 104 return from kfcntl [5 usec] 101 kioctl LR = D02D9B28 14C ioctl fd=4 command=5800 arg=0000 104 return from kioctl. error ENOTTY [5 usec] 101 kreadv LR = D02FC0A0 163 read(4,200D6780,1000) /ora815/network/admin/tnsnames.ora 10A PFS rdwr (vp,ip)=(5FDD330,5FDD360) /ora815/network/admin/tnsnames.ora 10A PFS readi VA.S=0000.C57B bcount=0000 ip=5FDD360 104 return from kreadv [80 usec] 101 kreadv LR = D02FC0A0 163 read(4,200D6780,1000) /ora815/network/admin/tnsnames.ora 10A PFS rdwr (vp,ip)=(5FDD330,5FDD360) /ora815/network/admin/tnsnames.ora 104 return from kreadv [10 usec] 101 close LR = D02B0D34 12E close /ora815/network/admin/tnsnames.ora fd=4 104 return from close [32 usec] 101 uname LR = D0F18814 104 return from uname [11 usec] 101 getuidx LR = D02C8BC8 104 return from getuidx [2 usec] 101 kfcntl LR = D02D71F0 137 fcntl F_GETFL return value 0002 104 return from kfcntl [7 usec] 101 kfcntl LR = D02D71F0 137 fcntl F_GETFL return value 0009 104 return from kfcntl [3 usec] 101 sigprocmask LR = D02C8CD4 104 return from sigprocmask [7 usec] 101 sigprocmask LR = D02A52C0 104 return from sigprocmask [3 usec] 101 _sigaction LR = D02A5414 180 sigaction signal SIGABRT <<<<====== THIS SHOULD BE THE CULPRIT! addr new sigaction=2FF1D6D8 addr old sigaction=00000000 104 return from _sigaction [14 usec] 101 sigprocmask LR = D02A5468 104 return from sigprocmask [2 usec] 101 kfcntl LR = D02D71F0 137 fcntl F_GETFL return value 0002 104 return from kfcntl [2 usec] 101 kfcntl LR = D02D71F0 137 fcntl F_GETFL return value 0009 104 return from kfcntl [3 usec] (long list of garbage collecting calls follows) The httpd exits without segmentation faults (very quietly indeed!), but I can't see what may cause the SIGABRT. ------------------------------------------------------------------------ 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/?id=7847 Edit this bug report at http://bugs.php.net/?id=7847&edit=1