Should this simple code consume memory?

[Chris]

Hey C# Folks. I have some database code that is eating up tremendous
amounts of memory. I wrote a little test class to simulate the problem and
after executing the loop 100,000 times, my app has used 350,000,000 bytes of
unmanaged memory. I'm not leaking handles and the managed heaps are all
staying very small. I have a case open with the DB Vendor but thought I
would post the test class for review to see if there is something really
dumb I'm doing. (I plugged SqlClient Classes into the same class structure
and it doesn't have any memory issues but I still want to check.) It seems
very simple to me but it's hard for me to believe a memory leak as bad as
I'm experiencing got through Sybase QA.

So, is there anything about the code below that would prevent memory from
being cleaned up?

Thanks!

-Chris

___________________________________________________

I'm calling the class below from a Windows form and here is the click event
where I call it.
___________________________________________________

private void button1_Click(object sender, System.EventArgs e)

{

loops = Convert.ToInt32(numericUpDown1.Value);

InstanceTests instTest = new InstanceTests();

instTest.execScalerLoop(loops);

instTest = null;

totalLoops += loops;

label3.Text = totalLoops.ToString();

}

__________________________________________________

Here is the class:
__________________________________________________
using System;

using System.Data;

using Sybase.Data.AseClient;



namespace SybMemLib

{

public class InstanceTests

{

public InstanceTests(){}



public void execScalerLoop(int loopCount)

{

string connString = @"Port=<removed>;Data
Source=<removed>;UID=<removed>;PWD=<removed>";


for (int i = 0; i < loopCount; i++)

{

AseConnection conn = new AseConnection(connString +
";Database=<removed>;");


AseCommand comm = new AseCommand("select
max(<numeric_column>) from <table>", conn);


try

{

conn.Open();

object queryResult = comm.ExecuteScalar();

}

catch(Exception e)

{

Console.WriteLine(e.ToString());

}

finally

{

conn.Close();

comm.Dispose();

conn.Dispose();

}

}

}

}

}

 

[Bob Grommes]

That's pretty ordinary, straightforward code. Shouldn't cause any problems.
In any case, the CLR isn't responsible for unmanaged memory.

The only thing I'd do different is a using statement for the connection:

conn.Open();

using (conn) {
// try/catch block here, without the finally.
}

This is cleaner, less error prone, less code. However, you are effectively
doing the same thing, even to the point of disposing of the command object,
which I don't normally bother with.

Talking to the vendor is a good idea. It may well be caused by some obscure
configuration issue that got past testing.

You might also make sure the query is properly optimized -- that you have an
index on the numeric column, etc.

--Bob

 

[Chris]

Thanks for the feedback, Bob. It seems pretty straight forward to me too
but I wanted to check...

-Chris