Please check this page:

http://www.php.net/manual/en/ref.oci8.php

And especially the note about linking Apache with libpthread..

[root@einstein root]# ldd /usr/sbin/httpd
[...SNIP...]
        libwtc9.so => /home/oracle/product/9.0.1/lib/libwtc9.so (0x40adc000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x40adf000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Apache IS linked with libpthread - i have compiled working php/apache combos with OCI support before and knew of this.

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

Please read the instructions of how to generate useful
gdb backtraces.. 

Configure Command './configure' '--with-db' '--with-apache=../apache_1.3.26' '--with-gd=../gd-1.8.4' '--with-mysql=/usr' '--with-zlib' '--with-oci8=/home/oracle/product/9.0.1' '--enable-debug' '--enable-track-vars=yes' '--with-jpeg-dir=/usr' '--with-tiff-dir=/usr' '--with-png-dir=/usr' '--with-xml' '--with-calendar' '--enable-sigchild' '--with-xpm-dir=/usr/X11R6' '--enable-calendar' '--with-ttf=/usr'

[root@einstein src]# gdb ./httpd
GNU gdb Red Hat Linux (5.1-1)
Copyright 2001 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"...
(gdb) run -X -f /etc/httpd/conf/httpd.conf
Starting program: /root/build/apache_1.3.26/src/./httpd -X -f /etc/httpd/conf/httpd.conf

Program received signal SIGSEGV, Segmentation fault.
0x4082b997 in lmsaicmt () from /home/oracle/product/9.0.1/lib/libclntsh.so.9.0
(gdb) bt
#0  0x4082b997 in lmsaicmt () from /home/oracle/product/9.0.1/lib/libclntsh.so.9.0
#1  0x407c0063 in kpugeml () from /home/oracle/product/9.0.1/lib/libclntsh.so.9.0
#2  0x403550a7 in kpusebf () from /home/oracle/product/9.0.1/lib/libclntsh.so.9.0
#3  0x4030dd3f in kpuatch () from /home/oracle/product/9.0.1/lib/libclntsh.so.9.0
#4  0x403a0aaa in OCIServerAttach () from /home/oracle/product/9.0.1/lib/libclntsh.so.9.0
#5  0x080a71c4 in _oci_open_server (dbname=0x829fc04 "wbldb.femu", persistent=1) at oci8.c:2422
#6  0x080a792a in oci_do_connect (ht=3, return_value=0x829fbc4, this_ptr=0x0, return_value_used=1, persistent=1, exclusive=0) at oci8.c:2578
#7  0x080abe16 in zif_ociplogon (ht=3, return_value=0x829fbc4, this_ptr=0x0, return_value_used=1) at oci8.c:4217
#8  0x0816548f in execute (op_array=0x829be2c) at ./zend_execute.c:1598
#9  0x08141caa in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:810
#10 0x08082a4a in php_execute_script (primary_file=0xbfffe2e0) at main.c:1381
#11 0x0814d2c2 in apache_php_module_main (r=0x829331c, display_source_mode=0) at sapi_apache.c:90
#12 0x0807ede8 in send_php ()
#13 0x0807ee41 in send_parsed_php ()
#14 0x0816f313 in ap_invoke_handler ()
#15 0x08183e77 in process_request_internal ()
#16 0x08183ed8 in ap_process_request ()
#17 0x0817aee1 in child_main ()
#18 0x0817b08c in make_child ()
#19 0x0817b200 in startup_children ()
#20 0x0817b878 in standalone_main ()
#21 0x0817c0db in main ()
#22 0x409ba707 in __libc_start_main () from /lib/libc.so.6
(gdb) frame 8
#8  0x0816548f in execute (op_array=0x829be2c) at ./zend_execute.c:1598
1598                                                    ((zend_internal_function *) EX(function_state).function)->handler(EX(opline)->extended_value, EX(Ts)[EX(opline)->result.u.var].var.ptr, EX(object).ptr, return_value_used TSRMLS_CC);
(gdb) print (char *)(executor_globals.function_state_ptr->function)->common.function_name
$1 = 0x81a4d5d "ociplogon"

The same issue was experienced on sun-sparc-solaris2.8, with Oracle 8.0.5. Both php 4.0.4pl1, 4.0.6 and 4.2.2 are affected.

Please, solve this issue as soon as possible - this is a serious showstopper.

Thanks!

I've been experiencing this issue on a production webserver since I upgraded the client to Oracle 9i.  Previously, the install worked fine when the client was Oracle 8.  I tried this out on my development box and everything works fine.  The production box is running:

Linux 2.4.2 (early RH 7.1 or 7.2)
glibc-2.2.2-10
gcc-2.96

My development box is running:

Linux 2.4.18
glibc-2.2.5
gcc-3.1.4

Both machines are running Apache 1.3.26 with pthreads.  Both have the Oracle 9.2 client.  PHP was configured in both cases with:

./configure --with-apxs=/opt/apache/bin/axps --with-oci8=/opt/oracle --with-mysql=/opt/oracle --with-gettext --enable-track-vars --enable-force-cgi-redirect

In both cases, Apache was compiled with:

./configure --prefix=/opt/apache-1.3.26 --enable-rule=SHARED_CORE --enable-module=so --enable-module=rewrite

and then later recompiled with pthread w.r.t. to the OCI8 directions.  I cannot seem to get a gdb dump trace from the production box (probably becuase of missing development tools) but it does generate a core file if someone is interested in me sending them output from that (e-mail me at jason.mccormick@lexi.com and give me instructions).  Please advise how I can help debug this issue as it is critial to me.

I found a core file from apache:

[root@yew apache]# gdb bin/httpd ./core
GNU gdb 5.0rh-5 Red Hat Linux 7.1
Copyright 2001 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"...

warning: core file may not match specified executable file.
Core was generated by `/opt/apache-1.3.26/bin/httpd'.
Program terminated with signal 11, Segmentation fault.
#0  0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x4042e195 in ?? ()
#2  0x40069708 in ?? ()
#3  0x40067c48 in ?? ()
#4  0x40067cd7 in ?? ()
#5  0x40067c1a in ?? ()
#6  0x40067cd7 in ?? ()
#7  0x40078155 in ?? ()
#8  0x4007b46e in ?? ()
#9  0x4007bb4a in ?? ()
#10 0x0805d621 in ?? ()
#11 0x401b4177 in ?? ()
(gdb)

Not sure if this is a legit core becuase I've played with a dozen combinations of configurations.

I was getting a Seg Fault connecting to Oracle 7.3.4 -- but not on 8.0.x

I had this path wrong before attempting the OCIPLogon.. 
 putenv("ORA_NLS33=/../oracle/product/8.0.6/ocommon/nls/admin/data");

Once it was correct.. no more seg fault.
sorry, no gdb on the system to check the backtrace though.

I resolved my own issue.  I determined that the httpd user wasn't picking up the ORACLE_HOME environment variable.  Forcing that variable into the startup script has fixed the problem.

So does this final solution fix the problem for everyone?  Solution being that mentioned by jason.mccormick

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".