Hi there,

It's now the morning, and I've verified this behaviour.

<?php
$conn = oci_connect("user", "pw", "db");
?>

'netstat -an | grep 1521.*ESTABLISHED | wc -l' reports an incremented number of connections after script execution ends.

That doesn't sound right (hence your bug report); can you verify that you really are using the latest PECL OCI8 extension?  Check your phpinfo() output.

Hi Wez,

It's definitely 1.1.1 - unless I've gone totally delirious.  phpinfo() reports oci8 '$Revision: 1.274 $' (??), and lists the new oci8 directives and default values.

If you'd like the URL to the phpinfo() page, give me a shout.

Thanks,
Gareth

Would the fact that it's being run with Apache2 using a threaded MPM have anything to do with it?

Just to be sure:
Do you have a debugger there?
If yes, please check that functions "php_oci_connection_close" and "OCIServerDetach" are being called (just set a breakpoint there), 'cause I'm absolutely sure I can't reproduce it on Linux.
Thanks.

Ahh Tony.  Last time I touched C was in 1997... there's no debugger installed... space on /usr/local is severely limited... this PHP project has got to be finished by Wednesday... and if anything breaks again tonight it'll be my head on a stick on Monday morning.

That is, I'd love to help right now but am not able to.  

Have reconfirmed the behaviour again.  Also, thought this snippet might be of some use:

<?php
$conn = oci_connect("user", "pw", "db");
echo oci_close($conn);
?>

oci_close($conn) returns 1 and 'netstat -an | grep 1521.*ESTABLISHED | wc -l' does NOT increment.  That is, if oci_close is called the connection closes, but if it doesn't it stays open forever.

It'll take some time for me to install OCI client at Solaris and build PHP --with-oci8, so I doubt I'll be able to do it in the nearest days. 
Though, that doesn't mean that I won't do it at all.
I believe it'd be easier to install debugger and to see if this is a problem of PHP or a problem of Oracle Client on Solaris (and to help *yourself* this way).
Reconfirming and re-re-confirming doesn't add any value, believe me.

I believe you.  We both want the same thing right?

In this role, I answer to my boss first.  To the University's students second.  And to the PHP community a far third.

I'm well aware that to fix this bug I should to help you, and that's why I shall schedule maintenance and take one of the web servers out of the load balancing circuit when is convenient for me and the organisation and the students it serves.

A traveller from Bug #29779, there's nothing more in PHP - and I'm a PHP fanatic - to see a reliable oci8 library.

I'm lurking on Undernet about to ambush you when you get on :p.

Just for the record: I can't reproduce on Linux and on Solaris with Apache2/prefork.

... and it works fine even if the MPM if "worker", so this is not a multithreading related issue.
Please try to build PHP with Oracle Instant Client and see if it helps.

Sorry for the delay in testing.

The connection is closed off correctly when compiled against InstantClient 10.

Tony,

Unfortunately it doesn't look like it picked up the instant client in compilation as the new style \\HOSTNAME\DBNAME referencing feature doesn't work.  So still it's unclear whether compiling with the instant client would reproduce the problem.

Will try again tonight.

oh and... as for the comment I made at 1:55am... that was a mistake.  I hadn't taken the oci_close statement out of the code.

Sorry :(

Okay, for real this time:

Using the 32-bit instantclient 10 doesn't seem to have an effect on the behaviour in question.

<?
oci_connect('user', 'pw', '//HOST/DBNAME');
?>

After browsing to a script such as this via the web, the connection to the database remains.

Works fine here, both on Linux and Solaris.
Please provide an account on this server or try on a different server yourself.

We've tried it on Linux with Instant Client 10 - it works fine.

I shall speak with my superiors about providing an account but it seems unlikely we will be able to do so.  Is there no other way to progress this bug report further?

Since I can't reproduce it even on Solaris, you have to make a research on your own:
Enable oci_internal_debug(true); and check its output.
Make sure php_oci_connection_close() function is called on every connection resource.

Antony, I've looked at session cleanup.

Problem 1:

    Incorrect order of OCISessionEnd and OCIServerDetach calls in
    php_oci_connection_close()

    The "Terminating the Application" section in chapter 2 of the OCI
    manual: http://download-west.oracle.com/docs/cd/B19306_01/
    appdev.102/b14250/oci02bas.htm#sthref217 says to call
    OCISessionEnd before calling OCIServerDetach.

Problem 2:

    In php_oci_connection_close(), connection->session is used after
    it has been freed.

Problem 3:

    In php_oci_connection_close() why are there some "free" and some
    "efree" calls?

Problem 4:

    In php_oci_cleanup_global_handles() the error handle should be of
    type OCI_HTYPE_ERROR, not OCI_HTYPE_ENV

Problem 5 (minor suggestion):

    Calls to OCIEnvInit, OCIHandleAlloc, OCIErrorGet & OCIHandleFree in
    php_oci_init_global_handles() could use PHP_OCI_CALL() so debug trace
    is generated.

    Call to OCIInitialize in PHP_MINIT_FUNCTION() could use
    PHP_OCI_CALL().

    Call to OCITerminate in PHP_MSHUTDOWN_FUNCTION() could use
    PHP_OCI_CALL().

A suggested patch is below.  Please review and test as I may have
misunderstood the solutions for problems 3 and 5, or not have taken
care of some special cases.

I have been unable to verify the patch solves the problem because I
only see the problem on Windows, but can only build on Linux.


--- oci8.c.1.283	2005-11-25 15:52:57.000000000 +1100
+++ oci8.c	2005-11-25 17:18:41.006806296 +1100
@@ -396,13 +396,13 @@
   sb4 error_code = 0;
   text tmp_buf[PHP_OCI_ERRBUF_LEN];

-  errcode = OCIEnvInit (&OCI_G(env), OCI_DEFAULT, 0, NULL);
+  errcode = PHP_OCI_CALL(OCIEnvInit, (&OCI_G(env), OCI_DEFAULT, 0, NULL));

   if (errcode == OCI_ERROR) {
     goto oci_error;
   }

-  errcode = OCIHandleAlloc (OCI_G(env), (dvoid **)&OCI_G(err), OCI_HTYPE_ERROR, 0, NULL);
+  errcode = PHP_OCI_CALL(OCIHandleAlloc, (OCI_G(env), (dvoid **)&OCI_G(err), OCI_HTYPE_ERROR, 0, NULL));

   if (errcode == OCI_ERROR || errcode == OCI_SUCCESS_WITH_INFO) {
     goto oci_error;
@@ -412,7 +412,7 @@

 oci_error:

-  OCIErrorGet(OCI_G(env), (ub4)1, NULL, &error_code, tmp_buf, (ub4)PHP_OCI_ERRBUF_LEN, (ub4)OCI_HTYPE_ERROR);
+  PHP_OCI_CALL(OCIErrorGet, (OCI_G(env), (ub4)1, NULL, &error_code, tmp_buf, (ub4)PHP_OCI_ERRBUF_LEN, (ub4)OCI_HTYPE_ERROR));

   if (error_code) {
     int tmp_buf_len = strlen(tmp_buf);
@@ -424,7 +424,7 @@
     if (errcode != OCI_SUCCESS_WITH_INFO) {
       php_error_docref(NULL TSRMLS_CC, E_WARNING, "OCI_ERROR: %s", tmp_buf);

-      OCIHandleFree((dvoid *) OCI_G(env), OCI_HTYPE_ENV);
+      PHP_OCI_CALL(OCIHandleFree, ((dvoid *) OCI_G(env), OCI_HTYPE_ENV));

       OCI_G(env) = NULL;
       OCI_G(err) = NULL;
@@ -441,7 +441,7 @@
 static void php_oci_cleanup_global_handles(TSRMLS_D)
 {
   if (OCI_G(err)) {
-    PHP_OCI_CALL(OCIHandleFree, ((dvoid *) OCI_G(err), OCI_HTYPE_ENV));
+    PHP_OCI_CALL(OCIHandleFree, ((dvoid *) OCI_G(err), OCI_HTYPE_ERROR));
     OCI_G(err) = NULL;
   }

@@ -480,7 +480,7 @@
 #endif

 #if !HAVE_OCI_ENV_CREATE
-  OCIInitialize(PHP_OCI_INIT_MODE, NULL, NULL, NULL, NULL);
+  PHP_OCI_CALL(OCIInitialize, (PHP_OCI_INIT_MODE, NULL, NULL, NULL, NULL));
 #endif

   ZEND_INIT_MODULE_GLOBALS(oci, php_oci_init_globals, NULL);
@@ -609,7 +609,7 @@
 #endif

 #if !HAVE_OCI_ENV_CREATE
-  OCITerminate(OCI_DEFAULT);
+  PHP_OCI_CALL(OCITerminate, (OCI_DEFAULT));
 #endif

   return SUCCESS;
@@ -1408,10 +1408,18 @@
     }
   }

+  if (connection->svc && connection->session && connection->is_open) {
+    PHP_OCI_CALL(OCISessionEnd, (connection->svc, OCI_G(err), connection->session, (ub4) 0));
+  }
+
   if (connection->is_attached) {
     PHP_OCI_CALL(OCIServerDetach, (connection->server, OCI_G(err), OCI_DEFAULT));
   }

+  if (connection->svc) {
+    PHP_OCI_CALL(OCIHandleFree, ((dvoid *) connection->svc, (ub4) OCI_HTYPE_SVCCTX));
+  }
+
   if (connection->err) {
     PHP_OCI_CALL(OCIHandleFree, ((dvoid *) connection->err, (ub4) OCI_HTYPE_ERROR));
   }
@@ -1424,23 +1432,15 @@
     PHP_OCI_CALL(OCIHandleFree, ((dvoid *) connection->server, (ub4) OCI_HTYPE_SERVER));
   }

-  if (connection->svc) {
-    if (connection->session && connection->is_open) {
-      PHP_OCI_CALL(OCISessionEnd, (connection->svc, OCI_G(err), connection->session, (ub4) 0));
-    }
-
-    PHP_OCI_CALL(OCIHandleFree, ((dvoid *) connection->svc, (ub4) OCI_HTYPE_SVCCTX));
-  }
-
   if (connection->env) {
     PHP_OCI_CALL(OCIHandleFree, ((dvoid *) connection->env, OCI_HTYPE_ENV));
   }

   if (connection->is_persistent) {
     if (connection->hash_key) {
-      free(connection->hash_key);
+      efree(connection->hash_key);
     }
-    free(connection);
+    efree(connection);
   }
   else {
     if (connection->hash_key) {

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.

Thanks, Chris.
Patch applied (well, partly).

>In php_oci_connection_close() why are there some "free" 
>and some "efree" calls?
free() for persistent handles and efree() for usual ones.
memory allocated by efree() is freed at the end of request by Zend memory manager.