#24442 [NEW]: Accessing ADO via COM results in rapid memory leak

From: modea at hush dot com Operating system: Windows 2000 Server PHP version: 4.3.2 PHP Bug Type: COM related Bug description: Accessing ADO via COM results in rapid memory leak Description: ------------ When using the COM interface to access MS SQL server via ADO (per client's stringent requirements), we're finding that the PHP executable's memory use is increasing very rapidly, quickly resulting in a failure to instantiate any more COM. The COM is being called iteratively to load the data 100 rows at a time, so in some page loads the COM may be loaded and used up to 80 or 90 times. As each pass completes, the ADO Connection and Recordset objects are closed, and the local variables are unset(). We're finding that on our larger loads (the 80 to 90 COM loads), our memory consumption is increasing by as much as 9MB, whereas we'd expect an increase of nothing more than about 500k. If we swap the ADO with the mssql_ libraries, the memory increase is as expected. It takes about 40 such loads before COM fails to start. At that time, the PHP executable occupies about 290MB of memory. Reproduce code: --------------- // simplified. this is called in a loop 80x or more. $dbc = new COM("ADODB.Connection") or die ("Connection create failure"); $dbostr = "-connection details-"; $dbc->Open($dbostr); $RSet=$dbc->Execute("querystring"); //code to process rows in RSet $RSet->close; $dbc->close; unset($RSet); unset($dbc); Expected result: ---------------- Would expect the memory to be properly cleaned after calling the close method for both objects and unset'ing the local variables. The final data returned from this function is the same whether we use mssql_ or ADO, but with ADO the PHP exe's memory utilization increases much to rapidly. Actual result: -------------- Memory increase depends on size of result set. With every 8,000-10,000 rows loaded, we usually lose about 10MB. Once we hit ~290MB, ADO no longer instantiates, and we error out. -- Edit bug report at http://bugs.php.net/?id=24442&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24442&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24442&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24442&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24442&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24442&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=24442&r=support Expected behavior: http://bugs.php.net/fix.php?id=24442&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=24442&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=24442&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24442&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24442&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24442&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24442&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=24442&r=gnused