After switching to persistant OCI connections the error seems to be gone?!?!?!?!?!

Ok. Here is the unified diff


/usr/local/bin/diff -u php4-STABLE-200307080530/ext/oci8/oci8.c php-4.3.3RC2-dev/ext/oci8/oci8.c
--- php4-STABLE-200307080530/ext/oci8/oci8.c    2003-05-02 11:05:44.000000000 +0200
+++ php-4.3.3RC2-dev/ext/oci8/oci8.c    2003-07-08 12:57:41.150024000 +0200
@@ -2153,6 +2153,8 @@
        oci_session *session = 0, *psession = 0;
        OCISvcCtx *svchp = 0;
        char *hashed_details;
+       struct timeval tv;
+       int sec, usec;
 #ifdef HAVE_OCI_9_2
        ub2 charsetid = 0;
 #endif
@@ -2167,6 +2169,7 @@
           but only as pesistent requested connections will be kept between requests!
        */

+       if (! exclusive) {
        hashed_details = (char *) malloc(strlen(SAFE_STRING(username))+
                                                                         strlen(SAFE_STRING(password))+
                                                                         strlen(SAFE_STRING(server->dbname))+1);
@@ -2176,7 +2179,6 @@
                        SAFE_STRING(password),
                        SAFE_STRING(server->dbname));

-       if (! exclusive) {
                zend_hash_find(OCI(user), hashed_details, strlen(hashed_details)+1, (void **) &session);

                if (session) {
@@ -2191,6 +2193,15 @@
                                /* breakthru to open */
                        }
                }
+       } else {
+       gettimeofday((struct timeval *) &tv, (struct timezone *) NULL);
+       sec = (int) tv.tv_sec;
+       usec = (int) (tv.tv_usec % 1000000);
+       /* The max value usec can have is 0xF423F, so we use only five
+        hex digits for usec and eigth hex digits for sec. */
+       hashed_details = (char *) malloc(8+5+1); /* always enough */
+       sprintf(hashed_details, "%08x%05x", tv.tv_sec, tv.tv_usec);
+
        }

        session = calloc(1,sizeof(oci_session));
@@ -2679,7 +2690,7 @@
                persistent = 0;
        } else {
                /* if our server-context is not persistent we can't */
-               persistent = server->persistent;
+               persistent = server->persistent ? persistent : 0;
        }

        session = _oci_open_session(server,username,password,persistent,exclusive,charset);

See bug #26393, there it's said that this patch does not fix the problem..

Could you tell me the status of this issue? Its a showstopper for my development (See bug #26393)

I'm still using the php version 4.3.3-RC2-STABLE-200307080530 with this patch applied together with apache 1.3.27. 

There are no problems with non persistant Oracle connections. 

There are problems with persistant Oracle connections because the reuse of existing connections does not work properly and so the limit of parallel database connections to Oracle will be reached after a while. 

So we also use non persistant connections. In January 2004 we plan to move to the latest versions of apache 1.3 and to php-4.3.4 then i will be able to see what happens.

I'm almost sure I have the very same problem.  I managed to reproduce the error in my development machine using Apache 1.3.28, PHP 4.3.3, Oracle 8.1.7.  The production environtment is the same but uses Oracle 9.2.0 instead.

Operating Systems:
- Devel Machine: Mandrake 9.1 (Kernel 2.4.19)
- Production Machine: RedHat 9.0 (Kernel 2.4.20 SMP)

I used this configure options in Apache:
./configure --prefix=/usr/local/apache \
            --enable-module=most \
            --enable-shared=max

And this ones in PHP:
./configure --prefix=/usr/local/php-4.3.3-debug \
            --with-apxs=/usr/local/apache/bin/apxs \
            --with-config-file-path=/usr/local/php-4.3.3-debug/etc \
            --enable-shared \
            --disable-static \
            --enable-debug \
            --disable-rpath \
            --enable-pic \
            --enable-inline-optimization \
            --enable-track-vars \
            --with-versioning \
            --with-mod_charset \
            --with-regex=php \
            --enable-trans-sid \
            --enable-safe-mode \
            --with-zlib \
            --enable-bcmath=shared \
            --enable-calendar=shared \
            --with-dom=shared \
            --with-dom-xslt=shared \
            --with-dom-exslt=shared \
            --with-xmlrpc=shared \
            --enable-ftp=shared \
            --with-gettext=shared \
            --with-mysql=shared,/usr \
            --enable-shmop=shared \
            --enable-sysvmsg=shared \
            --enable-sysvsem=shared \
            --enable-sysvshm=shared \
            --with-bz2=shared \
            --with-tsrm-pthreads \
            --with-oci8=shared \
            --with-fdftk=shared,/usr

Please, note the --enable-debug  ;-)

I reproduced the problem this way: Configured the Apache directive MaxRequestPerChild to a very low value, let's say 30. then started Apache normally.

Then use GDB to track some httpd processes (I did this as root):
# gdb /usr/local/apache/bin/httpd <some-httpd-pid>

make gdb to continue the execution.

With a browser access a php page that establish an Oracle connection.  The problem show up with both, persistant and non-persistant connections.

Reload the page several times until the process being debuged terminates (due to the MaxRequestPerChild directive) and kaput! Segmentation Fault!

The backtrace I got is the following:
Program received signal SIGSEGV, Segmentation fault.
0x40f0645c in epc_exit_handler () from
/opt/OraHome81/lib/libclntsh.so.8.0
(gdb) bt
#0  0x40f0645c in epc_exit_handler () from
/opt/OraHome81/lib/libclntsh.so.8.0
#1  0x400d6ac1 in exit () from /lib/i686/libc.so.6
#2  0x0805c823 in clean_child_exit ()
#3  0x0805f672 in child_main ()
#4  0x0805fcc8 in make_child ()
#5  0x08060010 in perform_idle_server_maintenance ()
#6  0x0806062e in standalone_main ()
#7  0x08060c34 in main ()
#8  0x400c3082 in __libc_start_main () from /lib/i686/libc.so.6

The problem occurs only when the process terminates, so the web user isn't affected by this problem at all.

Now, debugging a process that doesn't establish an Oracle connection (even with the oci8 extension loaded), when the process terminates, gdb says: "Program exited normally."

Due to the high traffic in the production machine, this Segmentation falut is logged every five seconds average.

I hope this information helps to solve the problem.


-William

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

fixed in pecl