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

ID: 7847 User Update by: msquillace@sogei.it Status: Open Bug Type: OCI8 related Description: OCI8 support with Oracle 8.1.5 doesn't work 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. Previous Comments: --------------------------------------------------------------------------- [2000-11-20 13:29:47] jason@php.net If you are expecting a segfault, why dont you try running httpd -X, make the request and see if it fails. Does AIX have a signal tracing tool similar to truss or strace? If you are getting a seg, send us a bactrace. -Jason --------------------------------------------------------------------------- [2000-11-20 13:22:34] msquillace@sogei.it I rebuilt the entire environment while writing the bug database entry, and sqlplus works in this scenario. The details of several checks follow: 1) I log in as root. 2) set | grep ORACLE returns: ORACLE_HOME=/ora815 ORACLE_SID=8T ORACLE_TERM=hft ORACLE_UID=oracle LD_PRELOAD, LD_LIBRARY_PATH, NLS_LANG and ORA_NLS33 should not be needed in AIX 4.2. 3) sqlplus system/manager@ZZZ gives ORA-12154 sqlplus system/manager@f40_7 works perfectly. 4) I now try starting apache with 3 different httpd.conf: a) user=nobody group=nobody b) user=nobody group=dba (nobody has been added to the dba group in /etc/group) c) user=apache group=dba (I created a new user apache - uid=70 - with base group=dba - gid=203 - in order to avoid having user/group ids > 60000) 5) repeating all my tests gives me the same results as in the bug report. 6) I log in as user apache. Oracle environment is the same as in 2). 7) sqlplus system/manager@ZZZ gives ORA-12154 sqlplus system/manager@f40_7 works perfectly. This morning I created a new test script, to verify PHP to Oracle connectivity using tnsping: <?php function prnit($value, $key) { echo "$value<br>"; } $t0 = microtime(); exec("tnsping f40_7", $rows); $t1 = microtime(); $ta = explode(" ", $t0); $tb = explode(" ", $t1); $t = bcsub(bcadd($tb[1], $tb[0], 6), bcadd($ta[1], $ta[0], 6), 6); echo "exec time: $t sec<br>"; array_walk($rows, 'prnit'); ?> This script works very well, producing the following output: exec time: 0.212467 sec TNS Ping Utility for IBM/AIX RISC System/6000: Version 8.1.5.0.0 - Production on 20-NOV-00 16:49:09 (c) Copyright 1997 Oracle Corporation. All rights reserved. Attempting to contact (address=(protocol=tcp)(port=1521)(host=26.2.161.96)) OK (20 msec) I believe this confirms the Oracle environment is sound, as viewed from the httpd process and, therefore from PHP. --------------------------------------------------------------------------- [2000-11-20 10:16:07] msquillace@sogei.it I rebuilt the entire environment while writing the bug database entry, and sqlplus works in this scenario. The details of several checks follow: 1) I log in as root. 2) set | grep ORACLE returns: ORACLE_HOME=/ora815 ORACLE_SID=8T ORACLE_TERM=hft ORACLE_UID=oracle LD_PRELOAD, LD_LIBRARY_PATH, NLS_LANG and ORA_NLS33 should not be needed in AIX 4.2. 3) sqlplus system/manager@ZZZ gives ORA-12154 sqlplus system/manager@f40_7 works perfectly. 4) I now try starting apache with 3 different httpd.conf: a) user=nobody group=nobody b) user=nobody group=dba (nobody has been added to the dba group in /etc/group) c) user=apache group=dba (I created a new user apache - uid=70 - with base group=dba - gid=203 - in order to avoid having user/group ids > 60000) 5) repeating all my tests gives me the same results as in the bug report. 6) I log in as user apache. Oracle environment is the same as in 2). 7) sqlplus system/manager@ZZZ gives ORA-12154 sqlplus system/manager@f40_7 works perfectly. This morning I created a new test script, to verify PHP to Oracle connectivity using tnsping: <?php function prnit($value, $key) { echo "$value<br>"; } $t0 = microtime(); exec("tnsping f40_7", $rows); $t1 = microtime(); $ta = explode(" ", $t0); $tb = explode(" ", $t1); $t = bcsub(bcadd($tb[1], $tb[0], 6), bcadd($ta[1], $ta[0], 6), 6); echo "exec time: $t sec<br>"; array_walk($rows, 'prnit'); ?> This script works very well, producing the following output: exec time: 0.212467 sec TNS Ping Utility for IBM/AIX RISC System/6000: Version 8.1.5.0.0 - Production on 20-NOV-00 16:49:09 (c) Copyright 1997 Oracle Corporation. All rights reserved. Attempting to contact (address=(protocol=tcp)(port=1521)(host=26.2.161.96)) OK (20 msec) I believe this confirms the Oracle environment is sound, as viewed from the httpd process and, therefore from PHP. --------------------------------------------------------------------------- [2000-11-18 22:45:44] sniper@php.net Have you set the Oracle specific environment vars mentioned on http://www.php.net/manual/ref.oci8.php before starting Apache? --Jani --------------------------------------------------------------------------- [2000-11-16 12:15:18] msquillace@sogei.it I can't get OCI8 support to work on AIX 4.2. During the last few weeks I have been able to configure an Apache 1.3.12 server (with and without SSL support) to load PHP 4 and several extensions (cURL, zlib, ClibPDF, openLDAP) on this RS600 model F40 but the single extension that I absolutely need (OCI8) doesn't want to work. I use gcc and want to create a DSO module for PHP, but have also tried static compilation and the standard AIX 4.2 cc compiler without success; further, I started out with PHP 4.0.3 then tried 4.0.3pl1 and now downloaded the latest CVS, to no avail. In the following I detail the steps needed to create a "stripped down" version of Apache+PHP4+OCI8, and describe the behaviour I observe. I am available for whatever further information you may need in order to solve the problem; please reply as soon as possible since I need to meet a deadline and, more importantly, am trying to introduce this technology in a company where Open Source software is still viewed skeptically. Prerequisite packages installation and setup ------------------------------- 01) login as root 02) gcc-2.95.2 (AIX 4.2 binaries from aixpdslib.seas.ucla.edu) 03) (GNU) make-3.79 (AIX 4.2 binaries from aixpdslib.seas.ucla.edu) 04) perl.5.005_03 (AIX 4.2 binaries from aixpdslib.seas.ucla.edu) 05) bison-1.28 [./configure, make, make install] 06) flex-2.5.4 [./configure, make, make install] 07) setup environment in order to force usage of gcc and GNU make. 08) setup environment in order to connect to Oracle 8.1.5 and test connection via sqlplus. 09) untar in /opt/src Apache 1.3.12 and latest PHP 4 sources. Apache+mod_so installation -------------------- 01) delete const keyword from the char *dlerror definitions in /opt/src/apache_1.3.12/src/os/unix/os.h and /opt/src/apache_1.3.12/src/os/unix/os-aix-dso.c to avoid eventual make failure in the PHP4 step(s) 02) cd /opt/src/apache_1.3.12 03)./configure --enable-module=so --prefix=/opt/www 04) make 05) make install 06) uncomment ServerName directive in /opt/www/conf/httpd.conf Apache installation test (OK) -------------------- 01) /opt/www/bin/apachectl start 02) connect to the server via netscape 03) /opt/www/bin/apachectl stop Build PHP4 as a dynamic module via APXS with OCI8 support (Oracle 8.1.5) and a minumum of directly supported modules. Latest build (php4-200011151045) from snaps.php.net. Oracle 8.1.5 is the last version supported on AIX 4.2; I observed the exact same behaviour with Oracle 8.0.5. ------------------------------------------ 01) in /ora815/lib, execute the command ln -s libclntsh.a libclntsh.sx.8.0 to force correct detection of Oracle 8.1 in step 03. 02) cd /opt/src/php4-200011151045 mkdir /opt/www/php mkdir /opt/www/php/bin tar xvf ../number.tar 03) ./configure --prefix=/opt/www --mandir=/usr/man --with-config-file-path=/opt/www/conf --enable-safe-mode --with-exec-dir=/opt/www/php/bin --enable-track-vars --enable-magic-quotes --with-apxs=/opt/www/bin/apxs --with-mysql=no --enable-sigchild --enable-trans-sid --enable-versioning --enable-bcmath --enable-wddx --enable-xml --enable-calendar --without-gd --with-oci8=/ora815 04) make During this step I only observe the following warning: fsock.c: In function `connect_nonb': fsock.c:182: warning: passing arg 5 of `getsockopt' from incompatible pointer type 05) make install 06) cp php.ini-optimized /opt/www/conf/php.ini uncomment the following in /opt/www/conf/httpd.conf: #AddType application/x-httpd-php .php #AddType application/x-httpd-php-source .phps Test Apache+PHP+OCI8 ------------------ 01) /opt/www/bin/apachectl start 02) connect to the server via netscape ... OK 03) invoke the info.php script on the server via netscape ... OK info.php contains: <?php phpinfo(); ?> 04) invoke ociver1.php on the server via netscape ... NOK ociver1.php contains: <?php OCIInternalDebug(1); echo "Attempting OCILogon<br>"; error_log("Before OCILogon", 0); $conn = OCILogon("system","manager", "ZZZ"); error_log("After OCILogon", 0); echo "Connection handle: >".$conn."<<br>"; echo "Server Version: " . OCIServerVersion($conn); OCILogOff($conn); ?> This I expect to fail, since ZZZ is not a defined alias in Oracle's tnsnames.ora; accordingly on the browser I get: Attempting OCILogon Warning: _oci_open_server: ORA-12154: TNS:could not resolve service name in /opt/www/htdocs/ociver1.php on line 5 OCIDebug: _oci_open_server: FAILURE -> CLEANUP called OCIDebug: START _oci_close_server: detaching conn=0 dbname=ZZZ OCIDebug: _oci_close_server: closing DEAD server OCIDebug: oci_do_connect: FAILURE -> CLEANUP called OCIDebug: START _oci_conn_list_dtor: id=0 OCIDebug: END _oci_conn_list_dtor: id=0 Connection handle: >< Warning: Supplied argument is not a valid OCI8-Connection resource in /opt/www/htdocs/ociver1.php on line 8 Server Version: Furthermore, if I tail /opt/www/logs/error_log I can correctly see: [Thu Nov 16 17:18:09 2000] [error] Before OCILogon [Thu Nov 16 17:18:09 2000] [error] After OCILogon OCIDebug: START php_rshutdown_oci<br> OCIDebug: END php_rshutdown_oci<br> 05) invoke ociver2.php on the server via netscape ... NOK ociver2.php contains: <?php OCIInternalDebug(1); echo "Attempting OCILogon<br>"; error_log("Before OCILogon", 0); $conn = OCILogon("system","manager", "f40_7"); error_log("After OCILogon", 0); echo "Connection handle: >".$conn."<<br>"; echo "Server Version: " . OCIServerVersion($conn); OCILogOff($conn); ?> In this case I expect the script to _WORK_, since f40_7 _IS_ a defined alias in Oracle's tnsnames.ora; the browser instead sends a popup along the lines: The document contained no data. Try again later, or contact the server's administrator. The /opt/www/logs/error_log only registers: [Thu Nov 16 17:23:17 2000] [error] Before OCILogon and doing a ps aux | grep http I note that one of the original httpd daemons has disappeared WITHOUT tracing anything on the error_log (I'd expect a segfault). Since I am using net8 (SQL*Net), I have also tried to trace it and also activated tracing for the Oracle listener, but nothing gets written in either trace file. 06) /opt/www/bin/apachectl stop --------------------------------------------------------------------------- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. Full Bug description available at: http://bugs.php.net/?id=7847