SqlDataAdapter memory leak?

  • Thread starter Thread starter Matt Weber
  • Start date Start date
M

Matt Weber

I've been trying to track down a memory leak in a project and have been
running around in circles for the past week or so. I've been using this
as an opportunity to evaluate Compuware's devPartner, but unfortunately
it seems to be doing more to confuse me than to help me. My problem can
be illustrated by the block of code attached to KB article 318263
(http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q318263). The
article gives this code as an example of a perceived, but not real,
memory leak. However, I think there is a real memory leak within the
SqlDataAdapter, unrelated to the perceived leaking that the article
talks about.

DataSet ds;
SqlConnection cn =
new SqlConnection("data source=localhost;initial
catalog=Northwind;user id=USER;password=PASSWORD");

cn.Open();
SqlDataAdapter da = new SqlDataAdapter("Select * from Employees", cn);
ds = new DataSet();
for (int i = 0; i < 1000; i++)
{
da.Fill(ds, "Table" + i.ToString());
}
cn.Close();

The leak is not major -- devPartner only reports ~50k being leaked, and
the entirety of it is reported as leaked by the da.Fill(...) method
call. But, 50k in this snippet could (and seems to have been within my
project) be amplified when adding larger tables to a DataSet. Has
anyone looked into this before? Is this a real issue with the
SqlDataAdapter, or am I hunting a snipe?

Thanks for reading,
-Matt
 
Hi Matt,

Note that when you open a connection for the first time, there is around
~50k allocated for the physicall connection.
When you later close it, it is not destroyed but it is kept open and
returned to the connection pool (thus those 50k are still allocated).

So, to verify this behaviour, you might just open/close the connection
without doing fill and without a dataadapter.
 
Miha said:
Hi Matt,

Note that when you open a connection for the first time, there is around
~50k allocated for the physicall connection.
When you later close it, it is not destroyed but it is kept open and
returned to the connection pool (thus those 50k are still allocated).

So, to verify this behaviour, you might just open/close the connection
without doing fill and without a dataadapter.
Click to expand...

Miha,

Thanks for the reply. If I profile the example with only the
DataAdapter fill call removed, devPartner reports only a very small leak
from closing the connection. It does not appear to be the same ~50k
leak that is reported from the DataAdapter fill.

Thanks,
-Matt
 
Miha said:
What if you call dataset.Dispose() at the end?
Click to expand...

Miha,

Disposing the DataSet seems to help substantially. There's still a
small (only 2.5k) leak reported from the call to Fill. That still
bothers me enough to look at it further, but at least the problem at
large has been somewhat alleviated.

Thanks,
-Matt
 
Hi Matt,

I don't think that there is an actualy memory leak - more like that memory
is being used by data you've filled.
 
Miha said:
Hi Matt,

I don't think that there is an actualy memory leak - more like that memory
is being used by data you've filled.
Click to expand...

Miha,

I would tend to agree, but since I'm disposing the DataSet that I've
just filled, shouldn't that release the memory in question?

The problem also seems to scale with the size of the DataSet being
filled. The 2.5k leak I'm seeing in my test application turns into a
500k leak in the actual project where I'm seeing the performance issues.

Thanks,
-Matt
 
Back
Top