Bug #2987 | Memory leak in SQLConnect incase of failure | ||
---|---|---|---|
Submitted: | 26 Feb 2004 22:52 | Modified: | 21 Jul 2004 18:59 |
Reporter: | Srinivas B.S.S | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | Connector / ODBC | Severity: | S2 (Serious) |
Version: | 3.51.06 | OS: | Solaris (Solaris 2.8 (sparc)) |
Assigned to: | Timothy Smith | CPU Architecture: | Any |
[26 Feb 2004 22:52]
Srinivas B.S.S
[27 Feb 2004 1:38]
Srinivas B.S.S
Updating to specify that I have used unixODBC as driver manager.
[29 Jun 2004 0:27]
Timothy Smith
Verified against 3.51.07 w/ unixODBC on FreeBSD 5.2
[18 Jul 2004 22:23]
Peter Harvey
I ran the test program using "top" to monitor memory usage. I was NOT able to create the problem in my default working environment; - Fedore Core 2 - unixODBC 2.2.9 (latest download) - MyODBC 3.51 (latest from source repository) - MySQL 4.0.20 I tried using valgrind but failed to get it to work on Fedora Core 2. I eventually got it to work on SuSE 9.0. I eventually tried the following and was able to see the problem. - SuSE 9.0 - unixODBC 2.2.6 (binary from SuSE Linux distro) - MyODBC 3.51 (latest from source repository) - MySQL 4.0.20 I used valgrind to verify what was pretty much obvious at this point - that the memory leak was in unixODBC. I then replaced unixODBC 2.2.6 with unixODBC 2.2.9 and the leak was gone. So the leak is in unixODBC and the solution is to use unixODBC 2.2.9 or better. I did NOT verify this on "Solaris 2.8 (sparc)" but it should solve the problem there as well.
[21 Jul 2004 18:59]
Timothy Smith
I tested on Linux w/ the latest MyODBC and unixODBC 2.2.9, and the bug leak is no longer there.