php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #19483 Null connection string results in runaway (100% cpu) process.
Submitted: 2002-09-18 16:45 UTC Modified: 2002-11-21 17:05 UTC
From: dboeke at eesus dot jnj dot com Assigned:
Status: No Feedback Package: OCI8 related
PHP Version: 4.2.1 OS: HPUX 11.0
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: dboeke at eesus dot jnj dot com
New email:
PHP Version: OS:

 

 [2002-09-18 16:45 UTC] dboeke at eesus dot jnj dot com
If an OCI8 connection is opened with a null connection string, the oracle client spawns a child process and attemps to connect to a default database (localhost:1521) using the user credential of the apache process, and using the oracle BEQ protocol.

In our case, there was no database running on the localhost, and the connection failed.  The default behavior of oracle at this point is to make the child process defunct. It assumes that the parent will notice that the process is defunct and clean it it up. However PHP/apache continue waiting for the process and never clean it up.  The PHP timout is never reached either, because the time spent in child processes is not included in calculating the amount of time PHP has been running.

The defunct processes continue to consume as much cpu time as is availible, resulting in continuous 100% CPU utilization.  Other Apache/php processes continue to run and serve requests, but with slower than normal processing times. (Because they are sharing CPU with the defunct process) Over time several of these processes can cause a huge performance impact on the server.

We have changed the default oracle behavior (through the sqlnet.ora file) so that oracle releases these defunct processes to the OS, and the OS cleans them up. The setting is BEQUEATH_DETACH = yes

We have also put better error checking in place to try and prevent sending a null connection string. However, I belive that this same error could occur with other child process that become defunct, like when executing a shell command.

Server Config:

'./configure' '--prefix=/www' '--with-config-file-path=/www/etc' '--with-apache=/www/src/apache_1.3.24' '--enable-static' '--enable-track-vars' '--enable-magic-quotes' '--enable-trans-sid' '--enable-safe-mode' '--enable-sigchild' '--enable-session' '--enable-bcmath' '--disable-debug' '--without-mysql' '--without-pear' '--with-oci8=/u01/app/oracle/product/8.1.7' '--with-gd=/opt/gd' '--with-png=/opt/libpng' '--with-xpm-dir=/opt/xpm' '--with-jpeg-dir=/opt/jpeg-6' '--with-ttf=/opt/freetype' '--with-zlib=/opt/zlib' '--with-pdflib=/opt/pdflib' '--with-openssl=/opt/openssl' '--with-ldap=/opt/openldap' '--with-tiff-dir=/opt/tiff' '--with-curl=/opt/curl'



Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-11-06 09:23 UTC] iliaa@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip


 [2002-11-21 17:05 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 25 11:01:30 2024 UTC