PHP :: Bug #29652 :: number of FD to ocius.msg is growing

Bug #29652

number of FD to ocius.msg is growing

Submitted:

2004-08-13 15:54 UTC

Modified:

2004-09-28 19:25 UTC

Votes:	3
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:

CVE-ID:

None

View Developer Edit

[2004-08-13 15:54 UTC] yannick at agl dot fr

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

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

[2004-08-13 17:36 UTC] tony2001@php.net

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] tony2001@php.net

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] tony2001@php.net

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.

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

[2004-08-19 12:15 UTC] tony2001@php.net

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.

[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 8.1.7.0.0 i have no problem at all.

[2004-08-23 16:19 UTC] yannick at agl dot fr

oci library: 9.2.0.3

[2004-09-15 13:59 UTC] rvs at angara dot ru

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

[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
JSC Sibron, RUSSIA

[2004-09-16 07:49 UTC] tony2001@php.net

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.

[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?

Sergei

[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] tony2001@php.net

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] tony2001@php.net

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.
[SKIPPED READING SYMBOLS]
(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] tony2001@php.net

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.

	php.net \| support \| documentation \| report a bug \| advanced search \| search howto \| statistics \| random bug \| login
go to bug id or search bugs for


Copyright © 2001-2025 The PHP Group All rights reserved.	Last updated: Wed Apr 09 05:01:28 2025 UTC