php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #35223 Memory Leak (odbc_connect and odbc_close)
Submitted: 2005-11-15 09:25 UTC Modified: 2005-11-24 01:00 UTC
Votes:11
Avg. Score:5.0 ± 0.0
Reproduced:11 of 11 (100.0%)
Same Version:11 (100.0%)
Same OS:-11 (-100.0%)
From: manelcaro at gmail dot com Assigned:
Status: No Feedback Package: ODBC related
PHP Version: 5CVS, 4CVS (2005-11-15) (snap) OS: Windows 2003 Server
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: manelcaro at gmail dot com
New email:
PHP Version: OS:

 

 [2005-11-15 09:25 UTC] manelcaro at gmail dot com
Description:
------------
We have a memory leak using Apache 2.0.54 and php 4.4.1 with odbc_connect and odbc_close functions. The memory leak is about 150 KB using only this two functions. We use odbc for connect to MAXDB database version 7.6.00.12. It produce a crash of Apache when it have about 100 MB.

Thanks.
Manel.

Reproduce code:
---------------
<?php

$cID= odbc_connect(...);
----
more code here {we try without the code and only with this functions and the result is the same }
----
if($cID){
 odbc_close($cID);
}

?>


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-11-15 09:31 UTC] sniper@php.net
Please try using this CVS snapshot:

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

And use the PDO ODBC.
 [2005-11-15 11:08 UTC] manelcaro at gmail dot com
I test php5-win32-lastest.zip and the result is the same, I test two methods:

1) with odbc_connect and odbc_close

2) with PDO
   $dbh = new PDO('odbc:NMSTOC', "xxxx", "xxxx");
   $dbh = null;

Thanks 
Manel
 [2005-11-15 13:25 UTC] sniper@php.net
Does it leak when you don't use any of those funcs? ie. with something like:

<?php echo "foobar"; ?>

 [2005-11-15 15:24 UTC] manelcaro at gmail dot com
With this it does not happen:

<?php echo "foobar"; ?>

Manel.
 [2005-11-16 00:19 UTC] tony2001@php.net
Why did you decide it's a memory leak?
How exactly did you discover it?
How exactly does it crash? (if possible, please try it on a real OS where you're able to get a backtrace, not just a useless address that points to nowhere). Thanks.
 [2005-11-16 00:49 UTC] kalowsky@php.net
Woah, wait a second here Tony.  Unfortunatley Windows 2003 is a real OS, so please keep the OS advocacy out of this forum.  Let's stick to the bug.  

A better series of questions will be:
What driver manager are you using?
What exactly is MAXDB, and which version of ODBC is it compliant to?
Have you tried altering your cursor to a different type?
 [2005-11-16 01:00 UTC] tony2001@php.net
I think you've got what I meant.
If there is a crash, I'd like to get a backtrace.
 [2005-11-16 11:29 UTC] manelcaro at gmail dot com
Hi kalowsky, I don't have backtrace for apache proc in windows 2003 (I'm sorry for inconvenience), only I see an access memory error and it restarts.

You can found MAXDB in: http://dev.mysql.com/downloads/maxdb/7.6.00.html

I want to test change odbc driver to release 7.5 and I think is possible the bug are in this driver. 

Thanks

Manel.

>>Why did you decide it's a memory leak?
If a memory increments without control, what do you think? 

>>How exactly did you discover it?
Read the first POST, only with this 2 functions.

>>if possible, please try it on a real OS ...
what is a real OS? I think is not possible
 [2005-11-16 13:42 UTC] sniper@php.net
Can you try with a different driver?
 [2005-11-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".
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Dec 09 10:01:27 2024 UTC