What's your Oracle, Apache, Oracle Client version?
What OS do you use?

Oracle Server EE with client 8.1.7.4
Apache 2.0.50
Windows 2000 Pro SP4

Please, try with Apache 1.3.x first (or using PHP CLI interface in console).

It not an output. We use Apache 2.X because at us dual-processor system. Apache 2.X just for this purpose it is intended.
Work through the CLI interface in console will considerably reduce productivity of a server.

I do not propose you to change buggy and poorly tested Apache2 to CLI. I just want to know if you're able to reproduce it with Apache1 and/or CLI.

I was not capable to reproduce this mistake. The matter is that the mistake arises spontaneously! The system can work long enough without occurrence of a mistake. For this time occurs thousand connections and disconnections.

There are no connections/disconnections between two different requests served by the same apache child. PHP's OCI8 module doesn't close connection even with ocilogoff/oci_close because of performance (and other) reasons and leaves this responsibility to the Oracle server.
I.e. even "usual" connections behave as "persistent" ones.

So, you aren't able to reproduce it with CLI? Or Apache1? What exactly did you try?

I have this behaviour with the following scenario:

Oracle 8i, server and client 8.1.7.4
Apache 1.3.31
Windows 2000 SP4
PHP 5.0.1

Please try using this CVS snapshot:

  http://snaps.php.net/php5-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.0-win32-latest.zip

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".

The current code is returning cached connections that are no longer valid. If the oracle instance is bounced without restarting Apache, the cached connections will no longer function (they will return ORA-24237), but they are still being returned to oci_connect (and oci_new_connect).

The connection either needs to be tested for "liveness" before being returned, or closed properly. They really should be closed instead of cached (unless using pconnect).

We're going to have to switch to CLI mode on our production systems until this is fixed.

My client is a billion dollar corporation. We are using PHP / Oracle to run a financial reporting portal that the high level executives use to access static reports generated by Business Object's broadcast agent. The PHP / Oracle layer is used to provide security and enforce business rules around SEC regulation. We are having the same problem.

We get get an error similar to this:
[Fri Jul 29 11:09:39 2005] [notice] child pid 15530 exit signal Segmentation fault (11)

It seems that this is caused by the DBAs fiddling around with the Oracle server and the connection drops. Because there isn't good coordination between the Unix admins and the DBAs, Apache doesn't get restarted when the connection drops. We are currently having to manually restart the Apache process, which usually involves someone getting woken up at an ungodly hour. 

We're using Apache 2, PHP 5.0.3, on Solaris 2.9. Our database is Oracle9i Enterprise Edition Release 9.2.0.6.0. Here are snippets of our configuration:

PHP Version => 5.0.3

System => SunOS servernamegoeshere 5.9 Generic_117171-14 sun4u
Build Date => Feb 11 2005 07:22:47
Configure Command =>  './configure' '--with-pear' '--with-db4=/local/applications/bdb' '--with-freetype-dir=/opt/gnu' '--with-
jpeg-dir=/opt/gnu' '--with-oci8=/local/www/httpd/instantclient10_1' '--enable-mbstring' '--enable-ftp' '--disable-ipv6' '--wit
h-ldap=/local/applications/openldap' '--with-ldap-lib=/local/applications/openldap/lib' '--with-ldap-include=/local/applicatio
ns/openldap/include' '--with-mysql=/local/www/httpd' '--with-libxml-dir=/local/www/httpd' '--with-imap=/local/development/mail
/imap-2004a' '--with-openssl=/local/ssl' '--with-zlib' '--with-zlib-include=/opt/gnu/include' '--with-zlib-lib=/opt/gnu/lib' '
--with-zlib-dir=/opt/gnu/lib' '--with-gd=/opt/gnu' '--with-inifile' '--with-flatfile' '--with-bz2=/opt/gnu' '--prefix=/local/w
ww/httpd' '--with-apxs2=/local/www/httpd/bin/apxs'
Server API => Command Line Interface
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /conf/net/www/php/php.ini.finportprd01
PHP API => 20031224
PHP Extension => 20041030
Zend Extension => 220040412
Debug Build => no
Thread Safety => disabled
IPv6 Support => disabled
Registered PHP Streams => php, file, http, ftp, compress.bzip2, compress.zlib, https, ftps
Registered Stream Socket Transports => tcp, udp, unix, udg, ssl, sslv3, sslv2, tls

...

oci8

OCI8 Support => enabled
Revision => $Revision: 1.257.2.5 $
Active Persistent Links => 0
Active Links => 0
Oracle Version => 10.1
Compile-time ORACLE_HOME => /local/www/httpd/instantclient10_1
Libraries Used =>
Temporary Lob support => enabled
Collections support => enabled

...

I don't belive that this is rightfully a PHP bug. It has more to do with the fact that Oracle and the way it manages connections sucks ass. But, I did want to document it, because it is a real problem, as andreys suggests, and it will not be solved through the conventional debugging techniques that are being suggested. Better to write a script to monitor your logs and make it your admin's headache, if you are lucky enough not to be the admin, of course. ;-)

The bug has been fixed in OCI8 v.1.1, which is available in CVS HEAD and PECL (use `pear install oci8-beta` to install it).