php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #7847 OCI8 support with Oracle 8.1.5 doesn't work
Submitted: 2000-11-16 12:15 UTC Modified: 2002-02-02 06:41 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: msquillace at sogei dot it Assigned:
Status: No Feedback Package: OCI8 related
PHP Version: 4.0.3pl1 OS: AIX 4.2
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: msquillace at sogei dot it
New email:
PHP Version: OS:

 

 [2000-11-16 12:15 UTC] msquillace at sogei dot 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

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-11-18 22:45 UTC] 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-20 10:16 UTC] msquillace at sogei dot 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 13:22 UTC] msquillace at sogei dot 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 13:29 UTC] 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-21 08:36 UTC] msquillace at sogei dot 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.

 [2000-11-22 11:10 UTC] msquillace at sogei dot 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-12-07 05:46 UTC] msquillace at sogei dot 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?

 [2001-01-07 19:42 UTC] sniper@php.net
Does this happen with latest snapshot from http://snaps.php.net/ ??

--Jani
 [2001-01-08 09:13 UTC] msquillace at sogei dot 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.
 [2002-01-11 16:49 UTC] lobbin@php.net
Can you reproduce this with PHP 4.1.1?
 [2002-02-02 06:41 UTC] sander@php.net
No feedback was provided for this bug, so it is being suspended.
If you are able to provide the information that was requested,
please do so and change the status of the bug back to "Open".
 
PHP Copyright © 2001-2017 The PHP Group
All rights reserved.
Last updated: Sun Nov 19 01:31:42 2017 UTC