VB and Memory Leaks

[randem]

If you are doing operations and VB needs more memory, it will allocate it. But unlike C, C++ or .Net VB will not release it until sometime after your app closes (There is no garbage collection). This would be the reason that some app run out of memory or run low on memory while in repetitive loops due to no fault of their own (well, sometimes it is their fault).

Unfortunately there is nothing you can do to avoid this. All you can do it limit the damage by releasing the object you create (setting them to nothing). But, sooner or later if your app runs for any length of time... It will happen.

The only way to avoid this is to restart your app when resources get low. Not great but that's the way it is....

[penagate]

Does it still do it if the repetitive operations are in a class module and you set that to Nothing?

I've never had any memory problems with VB that weren't caused by me.

[randem]

penagate,

Not all repetitive operations, just some. Sometimes they do not even have to be repetitive. But if you have a memory leak and do repetitive operations, you can get the "Out of Memory" error. VB inherently has memory leaks. Here is a sample project to show you how it happens.

VB Memory Leak (www.***********/cgi-bin/countdown.cgi?VBMemLeak.zip) (11mb)

This is an ADO example.

[penagate]

This is an ADO example.
If it's ADO then doesn't that mean it could be an issue with ADO? Or does it happen in other situations as well?

Also, I can't get that link to work :(

[randem]

penagate,

Yes, Ado is the issue here but VB is still VB. If one component has it, then others have it. The link maybe slow right now but it does works.

[randem]

penagate,

Here is a DAO example where the same thing happens.

VB Memory Leak 2 (www.***********/cgi-bin/countdown.cgi?VBMemLeak2.zip) (25kb No database included, use database from other project)

[penagate]

I can't really see a huge issue with either of those... :confused:
In the first one (looking at the log files) the memory usage actually went down, with the second one it very slowly went up (but not by much).

[randem]

penagate,

You have to look at the big picture, about 30mb of memory space goes missing with a full database and never returns until the file is unloaded. if I were to use that in a loop, it would not be long before I had a memory issue.

Did you do the test with full database. There is a database VBMemLeak org.mdb that is full. Use the bat file to reset the database for each run.

[penagate]

penagate,

You have to look at the big picture, about 30mb of memory space goes missing with a full database and never returns until the file is unloaded. if I were to use that in a loop, it would not be long before I had a memory issue.
Yah, but wouldn't you load the database before the loop... and then once you are done with it, you unload it. If you keep a good track of what you are doing with your objects/files at all times, then you shouldn't run out of resources.

I have memory issues with badly written classes... but that's solvable by re-writing the code. I'm not really convinced that there are any serious memory leaks with VB itself ;)

[randem]

penagate,

No, you would not load the database then do the operation then close it. That is bad resource management. You would leave the database open for the whole time the app is open.

The issue would happen in the loop. Each iteration would lose memory.

I'm not really convinced that there are any serious memory leaks with VB itself

If your app runs out of memory, you would not consider that serious? A couple of bytes or words of memory no, but this can be much more as I have shown.

The Bold area is a serious memory leak just from running a simple SQL Statement.

5/28/2005 1:45:55 AM - ADOLeak vbMemLeak.txt Error Log -

Before .Execute - 164929536
Delete from ProgramCheckOut where SYS_ID = 1
After .Execute - 163868672

Before .Execute - 163852288
Delete from ProgramData where SYS_ID = 1
After .Execute - 131428352

Before .Execute - 131428352
Delete from ProgramList where SYS_ID = 1
After .Execute - 131293184

Before .Execute - 131293184
Delete from PathName where SYS_ID = 1
After .Execute - 131248128

Before .Execute - 131248128
Delete from Title where SYS_ID = 1
After .Execute - 131231744

Before .Execute - 131231744
Delete from LockOut where SYS_ID = 1
After .Execute - 131215360

[penagate]

Oh. I see your point. I misinterpreted the numbers :blush:

In that case yes there is some memory leak going on. I never really use databases so I haven't run into these sorts of problems before.