php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #25472 Iterative calls to ODBC_DO seems to cause memory leak.
Submitted: 2003-09-10 12:27 UTC Modified: 2003-10-22 19:44 UTC
From: chris dot neale at somerfield dot co dot uk Assigned:
Status: Not a bug Package: ODBC related
PHP Version: 5CVS-2003-09-10 (dev) OS: Winnt SP6a Build 1381
Private report: No CVE-ID: None
 [2003-09-10 12:27 UTC] chris dot neale at somerfield dot co dot uk
Description:
------------
I am trying to generate 700 static HTML pages each containing a table of data. The loop appends the SQL string with the loop value and then calls ODBC_DO. I've taken out all the table formatting routines out of the code below, but it still replicates the same fault.

ODBC connects to an Access 97 SR1 database. I have installed the Jet SP 7_9NT service pack too.

When I run it, PHP.exe shows up in task manager's process monitor, eating away at memory fast - about 1 meg every second gets consumed by php's process and it generates about 7000 page faults every second too. But the script still works, and the information comes out as expected. The memory is then freed when PHP exits.

I'm concerned this bug will cause problems when I scale the project up to generate 20000 + reports.

I've run this code not only from a web page, but also from the command line with some additional code which waits for a user keystroke before continuing to the next loop iteration, hoping to slow down the process. The same problem occurred.

I'm using the latest Win32 CVS snapshot at the time of writing.

Same problem when using latest stable build of PHP 4.

php.ini - memory_limit = 8M

I've seen the memory climb as high as 40mb when running this script.

PHP.ini modifications:

extension=php_gd2.dll enabled.
doc_root, extension_dir

That's about all the info I can find... Really hope someone can shed some light on this one as I've been trying to solve it for about 2 weeks! Many thanks,

Chris

Reproduce code:
---------------
$dbCon = odbc_connect('AccessDbSystemDSN', '', '');

for ($nval=1;$nval<=700;$nval++)
{
$query = "SELECT * from [tablename] where ID = ".$nval;
$results = odbc_do($dbCon, $query);
}

odbc_close($dbCon); 



Expected result:
----------------
I expected the memory to remain fairly constant throughout execution, but it keeps on rising and not always at a constant rate.



Actual result:
--------------
The reports generates successfully on my desktop machine despite the memory rising, however PHP crashes when I run it on my laptop which has less RAM than my desktop.

Same NT build and PHP CVS snapshot on Laptop. No error message, just 'Internal Server Error' message. No Apache error log generated.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-09-10 20:33 UTC] sniper@php.net
Approximately HOW much data is in one row in your query..?

 [2003-09-11 07:20 UTC] chris dot neale at somerfield dot co dot uk
Each row contains

2 x Integers
1 x 255-Character Text value
11 x Doubles
 [2003-09-17 18:56 UTC] iliaa@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

To free memory you should use the odbc_free_result() function. Otherwise you are forcing PHP to keep all results for your query in memory. Since one of those fields is a string (varying length?) the memory increase is not linear.
 [2003-09-22 06:04 UTC] chris dot neale at somerfield dot co dot uk
I have used odbc_free_result($results) in an attempt to solve the problem but it has not worked as you described. The memory problem persists. I have put the odbc_free_result line below the odbc_do line.

kind regards,

Chris
 [2003-10-22 19:44 UTC] kalowsky@php.net
While there are (more than likely) memory leaks in the ODBC module, this isn't one of them.  It's either the cursor or the client holding this memory.  
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri May 10 08:01:33 2024 UTC