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 for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

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 have more details and the strack-trace (below). The problem appears only if there are both oci8.so and pdo_oci.so loaded as dynamic modules. If there is none of them loaded or just one of them present, it works ok. When there are both of them, it segfaults. The static linking i have not tried. 

The stack trace (--disable-debug).

#3  0xb7f4eb30 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#4  0xb65c2115 in __do_global_dtors_aux ()
   from /usr/local/lib/oracli/libclntsh.so.10.1
#5  0xb71120be in _fini () from /usr/local/lib/oracli/libclntsh.so.10.1
#6  0xb7f4f8f4 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#7  0xb7cd75d7 in exit () from /lib/tls/i686/cmov/libc.so.6
#8  0x0805dd58 in ap_start_restart ()
#9  0x0805f070 in ap_update_child_status ()
#10 0x08060e0f in main ()
(gdb)

The stack trace (--enable-debug).
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1211394368 (LWP 13339)]
0xb7f593d3 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
(gdb) bt
#0  0xb7f593d3 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#1  0xb7f597c9 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#2  0xb7f5cbf6 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#3  0xb7f5cb30 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#4  0xb6303055 in A_X931RandomContextDestroy ()
   from /usr/local/lib/oracli/libnnz10.so
#5  0xb7c1f7d6 in ssl3_get_key_exchange ()
   from /usr/lib/i686/cmov/libssl.so.0.9.8
#6  0xb7c22207 in ssl3_connect () from /usr/lib/i686/cmov/libssl.so.0.9.8
#7  0xb7c345f4 in SSL_connect () from /usr/lib/i686/cmov/libssl.so.0.9.8
#8  0xb7c287ce in ssl23_connect () from /usr/lib/i686/cmov/libssl.so.0.9.8
#9  0xb7c345f4 in SSL_connect () from /usr/lib/i686/cmov/libssl.so.0.9.8
#10 0xb19a782e in php_openssl_enable_crypto (stream=0x8115de4,
    sslsock=0x8115d80, cparam=0xbfe5fd30)
    at /root/build/php/php-5.2.3/ext/openssl/xp_ssl.c:418
#11 0xb19a72a5 in php_openssl_sockop_set_option (stream=0x8115de4, option=8,
    value=0, ptrparam=0xbfe5fd30)
    at /root/build/php/php-5.2.3/ext/openssl/xp_ssl.c:666
#12 0xb1c13631 in _php_stream_set_option (stream=0x8115de4, option=8, value=0,
    ptrparam=0xbfe5fd30)
    at /root/build/php/php-5.2.3/main/streams/streams.c:1133
#13 0xb1c2132e in php_stream_xport_crypto_enable (stream=0x8115de4, activate=1)
    at /root/build/php/php-5.2.3/main/streams/transports.c:371
---Type <return> to continue, or q <return> to quit---

Are each and every one of those extensions linked with same SSL libraries? And none of them is linked with static ssl libs?

Yes, these extensions are built together with the main PHP engine. I am using libssl.so.0.9.8 that comes with Ubuntu 6.06. I think that Oracle (instant-client) is not linked to openssl (at least not dynamically). For details see below. Anyhow, with CLI the sames script works without problems (both oci modules loaded).

ldd /root/libphp5.so
 linux-gate.so.1 =>  (0xffffe000)
 libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7aa2000)
 librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7a9a000)
 libfbclient.so.2 => /root/build/bin/firebird/lib/libfbclient.so.2 (0xb7a09000)
 libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb79cb000)
 libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb789c000)
 libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xb7889000)
 libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7867000)
 libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7864000)
 libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb784f000)
 libz.so.1 => /usr/lib/libz.so.1 (0xb783a000)
 libiodbc.so.2 => /usr/lib/libiodbc.so.2 (0xb77f7000)
 libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb76e8000)
 libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb75b9000)
 libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb75a7000)
 /lib/ld-linux.so.2 (0x80000000)
 libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb74ec000)
 libncurses.so.5 => /lib/libncurses.so.5 (0xb74ab000)
 libiodbcinst.so.2 => /usr/lib/libiodbcinst.so.2 (0xb7499000)
 libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb748f000)



ldd oci8.so
 linux-gate.so.1 =>  (0xffffe000)
 libclntsh.so.10.1 => /usr/local/lib/oracli/libclntsh.so.10.1 (0xb7189000)
 libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7054000)
 libnnz10.so => /usr/local/lib/oracli/libnnz10.so (0xb6e50000)
 libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb6e4c000)
 libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb6e2a000)
 libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb6e18000)
 libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb6e03000)
 /lib/ld-linux.so.2 (0x80000000)

ldd pdo_oci.so
 linux-gate.so.1 =>  (0xffffe000)
 libclntsh.so.10.1 => /usr/local/lib/oracli/libclntsh.so.10.1 (0xb7194000)
 libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb705f000)
 libnnz10.so => /usr/local/lib/oracli/libnnz10.so (0xb6e5b000)
 libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb6e57000)
 libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb6e35000)
 libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb6e23000)
 libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb6e0e000)
 /lib/ld-linux.so.2 (0x80000000)

This looks like a symbol clash between OpenSSL and Oracle Client.
Try updating Oracle Client and searching their bug database.

Yes, I think you are right. It is probably some clash between the specific versions of Apache/mod_ssl, OpenSSL, PHP/OCI modules and Instantclient.

Even though I don't understand, why this clash isn't reported during the linking or the loading of the libraries.

I have tried with the newest instantclient and there is no change.

Just to summarize, I have:
Ubuntu Linux 6.06
Apache 1.3.34 with mod_ssl 2.8.25
OpenSSL 0.9.8a
PHP 5.3.2 with oci8.so a pdo_oci.so as dynamic modules at the same time
Instantclient 10.1.0.5.

Last notice: If pdo_oci is compiled statically into PHP and oci8 dynamically (it refuses to be built static), it works fine. I think I can accept this as a workaround.

And if there is someone else unfortunate enough to meet the same circumstances as me, i hope this helps him at least a little bit ;-)

>Last notice: If pdo_oci is compiled statically into PHP and oci8
>dynamically (it refuses to be built static)
Huh? I _never_ build it as dynamic extension.

Ah, I see, I have checked it again and there must be something queer at the configure phase. I need almost all database drivers at the same time.

Doing this is ok:

--with-sybase-ct=/usr/local/lib/freetds \
--with-interbase=/usr/local/lib/firebird \
--with-oci8=shared,instantclient,/usr/local/lib/oracli

Doing this produces this error during configure:

--with-sybase-ct=/usr/local/lib/freetds \
--with-interbase=/usr/local/lib/firebird \
--with-oci8=instantclient,/usr/local/lib/oracli

checking for PostgreSQL support for PDO... no
checking for sqlite 3 support for PDO... yes
checking for PDO includes... checking for PDO includes... /root/build/php/php-5.2.3/ext
checking for char *... yes
checking size of char *... configure: error: cannot compute sizeof (char *), 77
See `config.log' for more details.
---
config.log
configure:96562: checking for PDO includes
configure:96568: checking for PDO includes
configure:96579: result: /root/build/php/php-5.2.3/ext
configure:97708: checking for char *
configure:97732: gcc -c -I/usr/include -g  -O0  conftest.c >&5
configure:97738: $? = 0
configure:97741: test -z                         || test ! -s conftest.err
configure:97744: $? = 0
configure:97747: test -s conftest.o
configure:97750: $? = 0
configure:97761: result: yes
configure:97764: checking size of char *
configure:98076: gcc -o conftest -I/usr/include -g  -O0  -L/usr/lib  -Wl,-rpath,/root/build/bin/firebird/lib -L/root/build/bin/firebird/lib -Wl,-rpath,/usr/local/lib/oracli -L/usr/local/lib/oracli conftest.c -lfbclient -lssl -lcrypto -lresolv -lm -ldl -lnsl  -lxml2 -lz -lm -lxml2 -lz -lm -ldl -lm -lnsl -lirc -lclntsh >&5
/usr/bin/ld: cannot find -lirc
collect2: ld returned 1 exit status
configure:98079: $? = 1
configure: program exited with status 1
configure: failed program was:
| /* confdefs.h.  */
|
...


There is some problem with -lirc but what is this library?

To complete my comment - these parameters of configure lead to the same error

./configure --prefix=/usr --with-config-file-path=/etc/php5 --with-apxs=/usr/bin/apxs \
--prefix=/build/install \
--enable-debug --without-pear --without-mysql \
--with-openssl \
--with-oci8=instantclient,/usr/local/lib/oracli

There seem to be a bug in Oracle Instant Client.
See http://forums.oracle.com/forums/thread.jspa?messageID=1508129 and 
http://forums.oracle.com/forums/thread.jspa?threadID=307303

Sorry again, it seems that there must be some part of configure information that is cached and it interferes when I run configure again. 

I have unpacked the sources to get a fresh, clean setup and I ran the above command again and it worked well. And it still worked when I added almost all the other database drivers.

BUT - there seems to be some kind of interference between oci8 and pdo-odbc in configure, because this command does not work even from the source files freshly unpacked:


./configure --prefix=/usr --with-config-file-path=/etc/php5
--with-apxs=/usr/bin/apxs \
--prefix=/build/install \
--enable-debug --without-pear --without-mysql \
--with-openssl \
--with-oci8=instantclient,/usr/local/lib/oracli \
--with-pdo-odbc=generic,/usr,iodbc

checking for SQLBindCol in -liodbc... no
configure: error: Your ODBC library does not exist or there was an error. Check config.log for more information

But it does exist, and changing the command to this (again from fresh sources), works:

./configure --prefix=/usr --with-config-file-path=/etc/php5
--with-apxs=/usr/bin/apxs \
--prefix=/build/install \
--enable-debug --without-pear --without-mysql \
--with-openssl \
--with-oci8=shared,instantclient,/usr/local/lib/oracli \
--with-pdo-odbc=generic,/usr,iodbc

I cannot figure why. Maybe it's getting late...(midnight has just passed here :-)

I add that --with-iodbc is not a problem and --with-pdo-oci is not a problem. Just having these two together (--with-oci8= and --with-pdo-odbc=generic,/usr,iodbc) seems to kick me.

Yes, you are right, the configure problem is a bug in the instantclinet, thank you a lot for the link, it saved my night :-))

I confirm the solution is to remove -lirc from ths file sdk/demo/sysliblist.

So, to summarize, configure is working fine for me now, I can build both modules static (oci8 and pdo-oci). The crash still remains under some circumstances:

PHP-CLI: OK
PHP-Apache2: OK
PHP-Apache1.3 + no oci: OK
PHP-Apache1.3 + oci8 dynamic: OK
PHP-Apache1.3 + pdo-oci dynamic: OK
PHP-Apache1.3 + oci8 dynamic + pdo-oci dynamic: SIGSEGV
PHP-Apache1.3 + oci8 dynamic + pdo-oci static: OK
PHP-Apache1.3 + oci8 static + pdo-oci static: OK

It's a rare situation and there is a workaround (static build), so let us leave it as bogus.