Experiencing Memory Leak using QODBC?

Is there a memory leak in the QODBC library?
Here are the scenarios:
SCENARIO 1:
I've got an application communicating with a Polyhedra IMDB via a Polyhedra 32-bit ODBC driver. It opens & queries & closes a database every 5th second. By monitoring the memory usage simply by using Task Manager/Process Explorer, I can see that the memory usage of my application increases by approx 4 kB every minute. This IS a memory leak: After some time , the memory usage was 1.4 Gb

SCENARIO 2:
I have made a simple test application: It opens and closes a database every 0.1 sec, doing nothing else. The database is a MySql database. When I connect using the QMYSQL driver, memory usage does NOT increase. When I connect using the QODBC driver, memory usage will steadily increase with each open/close
(Here, I use the newest MySql ODBC 5.1.8 driver)

SUMMARY:
I experience memory leak with two different ODBC drivers (Polyhedra from Ennea AB/MySQL ODBC 5.1.8) when I use the QODBC driver. With MySql ODBC the leak is approx 0.1 kB every time I open/close the database

When I use a direct MySql connection, no memory leak occurs.

I'm not sure what the relationship between "QODBC" and the actual driver used when setting up the ODBC source in Windows is, but it sure seems to me that the QODBC layer must be the culprit

NOTE. I know this is similar to QTBUG-8367, which was rejected earlier. Still, I cannot see why both MySQL and Polyhedra should leak memory..

NOTE2: I have attempted to use Purify (evaluation copy), but it does not report any memory leak! Strange, since I can observe the memory usage rising and rising...

Its not necessarily a memory leak.
It might be that memory is buffered or stays reserved once allocated to speed the next allocation.
There are all kinds of possibilities.
And if there is a memleak, I'd first look at YOUR code rather than at QODBC (that doesn't mean QODBC can't have a leak, but its more likely in your code that in QODBC's)

It is probably a memory leak: After a period of 2 weeks, my application (scenario 1) had allocated 1.4 Gb of memory (!)

My test application (scenario 2) is really simple, doing nothing but open() and close() repeatedly - and the memory use increases steadily by 0.1 kB every time.
(The test application is attached)

As mentioned earlier: When I switch to a direct MySQL connection using "QMYSQL" instead, my memory use settles nicely on a flat curve

Hmm...
Well, the reason for the bug rejection was:

Quote:

---

I've done a full valgrind memory leak profile. Qt Sql module doesn't leak memory, however unixODBC does under SqlConnectW.
Rejecting this as a bug, please report this upstream to your odbc provider.

---

So it might after all be the underlying ODBC driver.
The comment only mentions the unix driver, but if its a code sections that is the same in both unix and windows, then it might well be leaking under windows as well.
Did you look the ODBC bug tracking? (of the driver provider you are using)

Edit:
here is the windows part:

Quote:

---

I also used Rational Purify on windows. As stated before, Qt's SQL module is not leaking memory. ODBC is definitely leaking memory tho (Along with a massive slew of other places in windows).

---

Yes, according to the release notes for the most recent version of the MySql ODBC Driver (5.1.8), a memory leak has been fixed...but they sure didn't fix the one I'm experiencing. After browsing through earlier posts and release notes on the MySql ODBC driver, I notice that the phrase "memory leak" do pop up frequently...

And the thought has occured to me: The Polyhedra ODBC driver and the MySql ODBC driver might very well be based on the same faulty source code. That would explain why I experience this presumed memory leak with both products.

My immediate solution this problem is to keep the connections open, and rather reopen them if a query fails. This seems to keep the memory use stable & flat.

BUT: It sure is annoying to have to do this...

For the frequency of access (5/sec) keeping the connection open is probably a good idea anyway, especially if the DB server is ever going to be remote from the client application.