|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #29652 number of FD to ocius.msg is growing
Submitted: 2004-08-13 15:54 UTC Modified: 2004-09-28 19:25 UTC
Avg. Score:5.0 ± 0.0
Reproduced:3 of 3 (100.0%)
Same Version:1 (33.3%)
Same OS:1 (33.3%)
From: yannick at agl dot fr Assigned:
Status: Closed Package: OCI8 related
PHP Version: 4.3.7 OS: Linux Redhat 7.3
Private report: No CVE-ID: None
 [2004-08-13 15:54 UTC] yannick at agl dot fr
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) {
$stmt=OCIParse($conn,"select 50 as toto from dual");
echo ":::$total:::\n";

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


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2004-08-13 17:36 UTC]
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).
 [2004-08-16 10:15 UTC] yannick at agl dot fr
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...
 [2004-08-17 07:38 UTC]
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.
 [2004-08-17 11:34 UTC] yannick at agl dot fr
Yes the limit of FD is exceeded...
This issue occurs only with php not with JDBC under OCI.
 [2004-08-18 18:43 UTC]
Tested under Linux with Oracle, 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.

 [2004-08-19 12:06 UTC] esartoni at omniaglobal dot net
Same problem here with Solaris SunOS SPARC 5.9 - Apache 1.3.29 - PHP 4.3.8 - OCI
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 or with Linux RedHat 8, Apache 1.3.26, PHP 4.3.4 and OCI

I'll try with an older version of php and let you know what happens.
 [2004-08-19 12:15 UTC]
It would be better if you could try it with newer versions of PHP, especially latest snapshots from Older versions are not so important, 'cos I'm unable to fix them.
 [2004-08-20 09:13 UTC] esartoni at omniaglobal dot net
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.
 [2004-08-20 10:26 UTC] yannick at agl dot fr
tested with php 4.2.3 and php 5.0.1, there is no problem
 [2004-08-20 14:43 UTC] yannick at agl dot fr
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.
 [2004-08-23 16:08 UTC] esartoni at omniaglobal dot net
Hey Yannick, could you please tell us what version of oci libraries are you using?

With php 4.3.8 using oci i have no problem at all.
 [2004-08-23 16:19 UTC] yannick at agl dot fr
oci library:
 [2004-09-15 13:59 UTC] rvs at angara dot ru
I have the same error on php4.3.8/ora9. 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 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
 [2004-09-15 14:58 UTC] rvs at angara dot ru
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
 [2004-09-16 07:49 UTC]
Please, try this patch:
It was done against HEAD, so please use latest snapshot from

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.
 [2004-09-16 11:42 UTC] rvs at angara dot ru
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?

 [2004-09-16 11:47 UTC] rvs at angara dot ru
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.
 [2004-09-16 14:16 UTC]
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.
 [2004-09-16 14:35 UTC] rvs at angara dot ru
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 :-)
 [2004-09-16 14:42 UTC]
Please, generate a gdb backtrace, it works fine for me.
 [2004-09-16 18:48 UTC] rvs at angara dot ru
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.
(gdb) bt
#0  0x002c4b74 in shutdown_memory_manager ()
#1  0x0027d3d0 in php_module_shutdown ()
#2  0x0033525c in main ()
 [2004-09-20 21:34 UTC] rvs at angara dot ru
Tony I've sent you an experiment results
in reply to your private email. Hope you
did received it.
 [2004-09-24 01:00 UTC] php-bugs at lists dot php dot net
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".
 [2004-09-28 19:25 UTC]
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
Thank you for the report, and for helping us make PHP better.

PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Jul 24 19:01:28 2024 UTC