|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #32099 After opening ADO connection and closing it repeatedly, Apache stops service
Submitted: 2005-02-25 01:52 UTC Modified: 2021-05-09 04:22 UTC
Avg. Score:4.4 ± 0.9
Reproduced:9 of 9 (100.0%)
Same Version:6 (66.7%)
Same OS:9 (100.0%)
From: terryoh at wins21 dot com Assigned: cmb (profile)
Status: No Feedback Package: COM related
PHP Version: 5CVS, 4CVS (2005-02-28) OS: win32
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
Solve the problem:
21 + 9 = ?
Subscribe to this entry?

 [2005-02-25 01:52 UTC] terryoh at wins21 dot com
Today, my apache server stopped service. So I tested whether the apache daemon was ok or not. It worked, because the telnet 80 connection(like C:/telnet.exe 80) was successful. But I could not open any php pages on the internet explorer.

I checked the memory with windows task manager and I found something strange. The allocated memory for apache was almost 1GB(998MB) and the count of the handles was almost 40000(39890). 

Finally I found that it was ADO-PHP problem. I could see memory and the count of handles increased when opening database and closing it repeatedly(1 try/1 second for an hour). Especially the handles were never decreased.

1) Register any ODBC DSN(driver=SQL Server)in the control panel.
2) In PHP.INI, set the key name(odbc.default_db) with the DSN;user ID;password.
3) Start an apache service.
4) Open a test page(in the reproduce code section)in your web browser.
5) Refresh the test page repeatedly once a second.
6) Open windows task manager. If you can not see handle column on the process tab, add it(Menu->View->Column Selection->Handle).
7) After 1 minute or later, you can see the count of apache handle increase like 400->401->402->403.... Also you can see the memory increase.

Reproduce code:
  $ConnectionString   = ini_get('odbc.default_db');

  $AdoConn = new COM("ADODB.Connection"); 


***** Web Server  : Apache 1.3.28
***** PHP         : 4.3.8
***** OS          : Windows 2000 Server
***** DBMS        : MSSQL2000 Enterprise Edition
***** OTHERS      : MDAC 2.8

Expected result:
Windows Task Manager(Process Tab)
Image name      Memory       Handle
Apache.exe      10,840KB     200         11:00 AM
Apache.exe      10,857KB     201         11:02 AM
Apache.exe      10,867KB     202         11:04 AM
Apache.exe      10,867KB     202         11:06 AM
Apache.exe      10,867KB     202         11:08 AM
Apache.exe      10,867KB     202         11:10 AM
Apache.exe      10,867KB     202         11:12 AM

Actual result:
Windows Task Manager(Process Tab)
Image name      Memory       Handle
Apache.exe      10,840KB     200         11:00 AM
Apache.exe      10,857KB     201         11:02 AM
Apache.exe      10,867KB     202         11:04 AM
Apache.exe      10,877KB     203         11:06 AM
Apache.exe      10,886KB     204         11:08 AM
Apache.exe      10,899KB     205         11:10 AM
Apache.exe      10,910KB     206         11:12 AM
Apache.exe      998MB        39890


Patch_for_PhpCrashInFCGIModeDuringCoUnintialzie.diff (last revision 2011-04-22 23:17 UTC by thangaraj at gmail dot com)

Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2005-02-28 02:43 UTC] terryoh at wins21 dot com
I downloaded the latest php.

After upgrading the php module, I tried the same test. But the result was same. Memory and the count of the handles were increased. After the session.gc_maxlifetime(php.ini), the result was same.

I read something about zend engine on a webpage(I can't remeber the web address exactly), it is that the zend engine doesn't release database connection to reuse exceptionally. It might be this process causes trouble between ADO and Zend engine.
 [2005-03-02 08:23 UTC]
Please try using this CVS snapshot:
For Windows:

This is PHP 5 snapshot which has better COM support.

 [2005-03-02 09:43 UTC] terryoh at wins21 dot com
In my test, PHP 5 has same problem.

I really want to know the solution, please..
 [2005-03-19 00:08 UTC]
We don't know a solution, sorry.

 [2011-04-23 01:20 UTC] thangaraj at gmail dot com
I faced a similar crash in my App, fixed the COM issue and was trying to post it as a new bug, somehow PHP bug system smartly pointed out this defect. Tested my fix on the sample script and PHP doesn't crash. Therefore uploading patch here.

This crash is reproducible in old and latest SVN builds too.

OS          : WindowsServer 2003 R2 EE SP2 x86
PHP Version : 5.3.6 NTS build or below in fast cgi mode.
Web Server  : Apache 2.2.16 / mod_fcgid 2.3.5
DBMS        : MSSQL 2005 Enterprise Edition 
OTHERS      : MDAC 2.8

Root Cause: 
When PHP fastcgi engine Initializes and Shuts down ADO COM objects fastly within a second, Crash happens, i.e., Comsvcs.dll PingThread method access violates and crashes php-cgi.exe 

Patch provided: 
PHP non Thread safe builds using "fast cgi mode" is made to cache COM CoInit call and release COM subsystem only during php-cgi.exe process shutdown. 
By not calling CoUnint during every request shutdown, Comsvcs.dll is not unloaded and PingThread method does not access violate. Note that MS recommends to use CoUnint API during process shutdown, and this patch does it.

[PATCH uploaded] 
DIFF of 5.3SVN-2011-04-22

 [2011-05-29 17:32 UTC]
-Assigned To: wez +Assigned To: pajoye
 [2013-01-07 17:51 UTC] mike at edcsi dot com
Has this patch been included in the latest PHP builds? I am running on Windows 2003 server and have experienced the same problem.
 [2017-10-24 07:35 UTC]
-Status: Assigned +Status: Open -Assigned To: pajoye +Assigned To:
 [2021-04-27 22:17 UTC]
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2021-04-27 22:17 UTC]
I'm pretty confused here.  The OP reports resource leakage, and
Thanga suggests to move CoUninitialize() from RSHUTDOWN to
MSHUTDOWN to solve that.  I can definitely see the point of the
latter, but not how that could solve the resource leakage.

Anyhow, is this still relevant for anyone using any of the
actively supported PHP versions[1]?

[1] <>
 [2021-05-09 04:22 UTC] php-bugs at lists dot php dot 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 "Re-Opened". Thank you.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Jul 16 02:01:27 2024 UTC