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.

I did'nt get any backtrace, running gdb resulted in:
gdb httpd
(gdb) run -X
procfs: 4265 -- process not stopped
procfs: ...giving up...

httpd is running, I see it via "ps -ef"
calling OCILogin results in Segmentation fault, but the process doesn't stop, I don't get the core file

Well.. I can't get a backtrace for you too. 
Btw, you didn't tell your version of Apache (or whatever you use). If you use Apache2, you'd better read this: http://www.php.net/manual/en/install.apache2.php

You're right, 
I use apache 1.3.29

what does this mean ?
procfs: 4265 -- process not stopped
procfs: ...giving up...

Seems to be a Solaris-specific GDB bug.
Have a look at these messages: 
http://www.mail-archive.com/bug-gdb@gnu.org/msg00818.html
http://www.mail-archive.com/bug-gdb@gnu.org/msg00452.html

Btw, what Oracle client version do you use and does it correspond to Oracle server version?

I'm using Oracle 9.2.0 same product as I am connecting to. 
Oracle is 64 bit ( -m64 switch for gcc ). I started it 
under truss, here the last few lines: 
 
 
lstat("/opt/apache/itweb/htdocs", 0xFFFFFFFF7FFF80F0) = 0 
getuid()                                        = 60001 
[60001] 
door_info(4, 0xFFFFFFFF7FFF5D68)                = 0 
door_call(4, 0xFFFFFFFF7FFF5D38)                = 0 
sigprocmask(SIG_SETMASK, 0xFFFFFFFF7C91D500, 
0xFFFFFFFF7FFF7C90) = 0 
sigprocmask(SIG_SETMASK, 0xFFFFFFFF7FFF7C7C, 0x00000000) = 
0 
sigaction(SIGINT, 0xFFFFFFFF7FFF7AF0, 0xFFFFFFFF7FFF7CE8) 
= 0 
sigprocmask(SIG_SETMASK, 0xFFFFFFFF7C91D500, 
0xFFFFFFFF7FFF7C90) = 0 
sigprocmask(SIG_SETMASK, 0xFFFFFFFF7FFF7C7C, 0x00000000) = 
0 
brk(0x1004C6210)                                = 0 
brk(0x1004CA210)                                = 0 
brk(0x1004CA210)                                = 0 
brk(0x1004CE210)                                = 0 
brk(0x1004CE210)                                = 0 
brk(0x1004D2210)                                = 0 
door_info(4, 0xFFFFFFFF7FFF4538)                = 0 
door_call(4, 0xFFFFFFFF7FFF4508)                = 0 
brk(0x1004D2210)                                = 0 
brk(0x1004D6210)                                = 0 
so_socket(PF_INET, SOCK_STREAM, IPPROTO_IP, "", 1) = 7 
connect(7, 0xFFFFFFFF7FFF67F4, 16, 1)           = 0 
getsockname(7, 0xFFFFFFFF7FFF67F4, 0xFFFFFFFF7FFF6804, 1) 
= 0 
setsockopt(7, tcp, TCP_NODELAY, 0xFFFFFFFF7FFF6964, 4, 1) 
= 0 
fcntl(7, F_SETFD, 0x00000001)                   = 0 
brk(0x1004D6210)                                = 0 
brk(0x1004DA210)                                = 0 
brk(0x1004DA210)                                = 0 
brk(0x1004DE210)                                = 0 
brk(0x1004DE210)                                = 0 
brk(0x1004FE210)                                = 0 
    Incurred fault #6, FLTBOUNDS  %pc = 0xFFFFFFFF7D63C1AC 
      siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000 
    Received signal #11, SIGSEGV [default] 
      siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000

Maybe there are problems with the 64 bit Environment ? Is PHP + Oracle 64bit safe ? ( Pointer casted into int or unsigned int ? conversions between int ? adress arithmetic used ? )  I am using 64bit Oracle.

Finally I have the trace: 
Starting program: /opt/apache/itweb/sbin/httpd_php/httpd 
-X 
 
Program received signal SIGSEGV, Segmentation fault. 
0xff0b347c in strlen () from /usr/lib/libc.so.1 
(gdb) bt 
#0  0xff0b347c in strlen () from /usr/lib/libc.so.1 
#1  0xfe79f8f8 in snauca_check_adapter () from /opt/oracl/
product/9.2.0/lib32/libclntsh.so.9.0 
#2  0xfe79d8f0 in nau_viat () from /opt/oracl/
product/9.2.0/lib32/libclntsh.so.9.0 
#3  0xfe7944f4 in nau_gettab () from /opt/oracl/
product/9.2.0/lib32/libclntsh.so.9.0 
#4  0xfe7922b8 in nau_ini () from /opt/oracl/
product/9.2.0/lib32/libclntsh.so.9.0 
#5  0xfe783f8c in nainit () from /opt/oracl/product/9.2.0/
lib32/libclntsh.so.9.0 
#6  0xfe734c3c in nsnainit () from /opt/oracl/
product/9.2.0/lib32/libclntsh.so.9.0 
#7  0xfe7271dc in nsopen () from /opt/oracl/product/9.2.0/
lib32/libclntsh.so.9.0 
#8  0xfe70d188 in nscall1 () from /opt/oracl/
product/9.2.0/lib32/libclntsh.so.9.0 
#9  0xfe70c7a8 in nscall () from /opt/oracl/product/9.2.0/
lib32/libclntsh.so.9.0 
#10 0xfe7b8df0 in niotns () from /opt/oracl/product/9.2.0/
lib32/libclntsh.so.9.0 
#11 0xfe7b2954 in nigcall () from /opt/oracl/
product/9.2.0/lib32/libclntsh.so.9.0 
#12 0xfe744de0 in osncon () from /opt/oracl/product/9.2.0/
lib32/libclntsh.so.9.0 
#13 0xfe55f190 in kpuadef () from /opt/oracl/
product/9.2.0/lib32/libclntsh.so.9.0 
#14 0xfe55108c in upiini () from /opt/oracl/product/9.2.0/
lib32/libclntsh.so.9.0 
#15 0xfe55108c in upiini () from /opt/oracl/product/9.2.0/
lib32/libclntsh.so.9.0 
Previous frame identical to this frame (corrupt stack?) 
(gdb)

The backtrace shows, that the bug has nothing to do with PHP, but most likely is a Oracle Client problem.
Could you please search Oracle bug database ?

No feedback was provided for this bug for over a week, 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".