Description:
------------
i see the number of file descriptor to ocius.msg is growing for each
apache child. so i reproduce problem with this script.

Reproduce code:
---------------
<?
while (1) {
$conn=OCILogon($username,$password,$database);
$stmt=OCIParse($conn,"select 50 as toto from dual");
OCIDefineByName($stmt,"TOTO",&$total);
OCIExecute($stmt);
OCIFetch($stmt);
echo ":::$total:::\n";
OCILogoff($conn);
OCILogoff($conn);
sleep(10);
}
?>

Expected result:
----------------
1 file descriptor to ocius.msg
1 connection to database

Actual result:
--------------
the number of file descriptor to ocius.msg is growing.
1 connection to database

Does it grow constantly or it stops after reaching the number of apache
childs?
Can you please try the same with OCINLogon ?
Btw, ocilogoff() does nothing for a long time (connections are closed by
Oracle after a timeout).

the number of FD is growing constantly for each child. 
for example:

>ps -ef  | grep httpd
root       469     1  0 Aug05 ?        00:00:00
/usr/local/apache/bin/httpd -f /
web       6853   469  0 07:57 ?        00:01:09
/usr/local/apache/bin/httpd -f /
web       7035   469  0 08:02 ?        00:00:18
/usr/local/apache/bin/httpd -f /
web       7138   469  0 08:07 ?        00:00:25
/usr/local/apache/bin/httpd -f /
web       8408   469  0 08:52 ?        00:00:21
/usr/local/apache/bin/httpd -f /
web       8428   469  0 08:53 ?        00:00:17
/usr/local/apache/bin/httpd -f /
web       8429   469  0 08:53 ?        00:00:17
/usr/local/apache/bin/httpd -f /
web      10107   469  0 09:54 ?        00:00:04
/usr/local/apache/bin/httpd -f /
web      10402   469  0 10:05 ?        00:00:01
/usr/local/apache/bin/httpd -f /
web      10413   469  0 10:06 ?        00:00:01
/usr/local/apache/bin/httpd -f /
web      10626   469  1 10:11 ?        00:00:00
/usr/local/apache/bin/httpd -f /
web      10630   469  0 10:11 ?        00:00:00
/usr/local/apache/bin/httpd -f /
web      10631   469  0 10:11 ?        00:00:00
/usr/local/apache/bin/httpd -f /
web      10661   469  0 10:12 ?        00:00:00
/usr/local/apache/bin/httpd -f /

number of child: 14

> cd /proc/7035/fd
> ls -l |grep ocius |wc
> 235
i think each request make a new FD...

So, what the problem with it? It exceedes your FD limit?
It's most likely to be an OCI trouble, 'cos PHP knows nothing about
ocius.msg.

Yes the limit of FD is exceeded...
This issue occurs only with php not with JDBC under OCI.

Tested under Linux with Oracle 9.2.0.1, Apache 1.3.31 and latest PHP5 &
PHP4 versions.
Cannot reproduce your situation - there is still only one ocius.msb's
descriptor.
Plz, provide more info about software installed - versions of Oracle,
Apache etc.

Same problem here with Solaris SunOS SPARC 5.9 - Apache 1.3.29 - PHP
4.3.8 - OCI 9.2.0.1.0
The number of opened ocius.msg grows costantly reaching the fd limit.

No problem with Linux Debian, Apache 1.3.29, PHP 4.3.8 and OCI 8.1.7.0.0
or with Linux RedHat 8, Apache 1.3.26, PHP 4.3.4 and OCI 9.2.0.1.0

I'll try with an older version of php and let you know what happens.

It would be better if you could try it with newer versions of PHP,
especially latest snapshots from http://snaps.php.net. Older versions
are not so important, 'cos I'm unable to fix them.

tony, i've already tested it with php 4.3.8 (cannot try with php 5) and
with Solaris SunOS always gives the same problem. I'll try with the
latest snapshot but always in the 4.x tree.

tested with php 4.2.3 and php 5.0.1, there is no problem

i tried with 4.3.8 without HAVE_OCI_9_2
there is no problem. if i defined HAVE_OCI_9_2 the issue occurs.

Hey Yannick, could you please tell us what version of oci libraries are
you using?

With php 4.3.8 using oci 8.1.7.0.0 i have no problem at all.

oci library: 9.2.0.3

I have the same error on php4.3.8/ora9.2.0.1.0/Solaris 9/sparc.

Some details: the .msb file descriptors grow in the following cases:
A. using ocinlogon()
B. using ocilogon() and working as a Apache module
C. using oci*logon() with invalid credentials.

The following code of case "C" may exhaust filedescriptor limit very
easily and quickly.

for ($i=0; $i < 200; $i++)
 @ocilogon($i, $i, $db);

After extensive researching I've found that:
1. the .msb file openings occur when OCIEnvNlsCreate() is called.
2. in ext/oci8.c,v 1.183.2.12 line 2257, function _oci_open_session()
the OCIEnvNlsCreate() invoked when session is not persistent, not
cached, or is exclusive.
3. if the session setup is unsuccessful, the environment handle is not
freed.
4. the environment handle is freed only when PHP shuts down, see line
613.

The result will be filedescriptor and memory leakage in all cases A,B,C
mentioned above. This could lead to security/DOS problem for websites
which use ocilogon()/ocinlogon() or passthrough Oracle authentication in
their php scripts.

Recommendations, workaround:
1. in module mode, avoid using ocilogon(), use ociplogon() instead.
2. avoid using Oracle pass-through authentication (i.e. when username
and password for ociplogon() is given from the website user).
3. fixing oci8.c code to free env handle at least after unsuccessful
logon is necessary.

With regards,
Sergei V. Rozinov
Leading RISC-Systems engineer
JSC Sibron, RUSSIA

Also note that PHP 5 has similar code for OCIEnvNlsCreate() and frees
environment handle (OCI_HTYPE_ENV) only at shutdown.
So the problem seems to be in PHP 5 also.

Sergei V. Rozinov
Leading RISC-Systems engineer
JSC Sibron, RUSSIA

Please, try this patch:
http://tony2001.phpclub.net/dev/tmp/bug29652.diff.txt
It was done against HEAD, so please use latest snapshot from
http://snaps.php.net

The problem becomes complicated because I still can't reproduce this
under Linux and Apache 1.3.31, no matter with or without the patch.

Tried your patch, it resolves the problem partially.

In fact, only one bad case remains:
C'. using ocilogon()/ociplogon() with invalid credentials.

I mean if you use ocinlogon() with invalid credentials, all works
because the ENV handle is freed for exclusive session explictly by your
patch. So I suppose you should free ENV handle explicitly in the case of
a failed connection/invalid logon also.
Then all will work fine, hope :-)

How about these patches for 4.3.x?

Sergei

P.S. I think you can't reproduce this under Linux because of the Oracle
Client software design for Linux may be quite different from Solaris'
one.

Well, yes, of course Solaris & Linux clients are different, but initial
report states that this issue was reproduced under Linux.
I updated the patch (revers the old one before applying this), you can
get at the same URL.
Btw, this version of the patch should fix another issue: it reports
memleaks for me with ocilogon() and invalid password/login. 
Try it out and tell me if it works under Solaris.

Yes it works perfectly for FDs but introduces segfault at php shutdown,
when I use the code:

for ($i=0; $i < 200; $i++)
 {
    $c1 = @ociplogon($valid_user, $valid_password, $db);
 }

Note that the credentials are valid here.
It seems that the ENV handle is freed more than once somewhere :-)

Please, generate a gdb backtrace, it works fine for me.

Well the backtrace is quite simple:

GNU gdb 6.2.1
This GDB was configured as "sparc-sun-solaris2.9"...
Core was generated by `./php ./x.php'.
Program terminated with signal 11, Segmentation fault.
[SKIPPED READING SYMBOLS]
(gdb) bt
#0  0x002c4b74 in shutdown_memory_manager ()
#1  0x0027d3d0 in php_module_shutdown ()
#2  0x0033525c in main ()

Tony I've sent you an experiment results
in reply to your private email. Hope you
did received it.

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

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.