Memory Leaks

[LegoPiece]

Hi All!

I have a program, which I run six discrete instances of for multi-processing, and use a shared memory interface between them to communicate.

The programs all run fine for the first two weeks of operation before they start to slooooow down and grind to a halt. Looking at the NT Task manager, each instance of the executable has increased it's memory usage by a ridiculous amount, thus forcing the OS to page virtual memory.

Each instance of the executable contains an ActiveX control for a robot system (a TCP/IP interface behind the scenes). The program also has an OLE Interface to an external device (PLC) to receive instructions in real time. Could these be the cause of the memory leak, or is it more likely to be a source code-induced phenomenon?

Basically, what the heck causes this?
Thanks!
LeGo PiEcE

"The Computer Spock! Destroy it!" - Captain James T. Kirk

 

[Francis]

Have a look at the Processes in NT task manager and see if they are multplying. Something is not behaving gracefully. I have seen similar things with SCADA packages

 

[MikeCox]

Just a generic solution to a generic cause of memory leaks in VB, any object variable (i.e. anything but a simple data type like long or variant) needs to be set to Nothing when it goes out of scope. Note that includes objects passed ByVal to functions (the function should set it to Nothing), and any reference to ActiveX UserControls (i.e. for every "Dim Robot As MyRobotActiveXControl", there should be a cooresponding "Set Robot = Nothing", in Form_Unload() if nowhere else). You can make sure your classes aren't the culprit by declaring a temporary global integer that gets updated accordingly as each class instance is created and destroyed. If this number keeps climbing, you know your classes aren't being destroyed when they should. At any rate, that's the first thing I'd look for.

Hope that helps!

~Mike
Any man willing to sacrifice liberty for security deserves neither liberty nor security.

-Ben Franklin

 

[LegoPiece]

Francis,

Wow... I've never used any SCADA packages, however our company is looking at Intellution Dynamics for a forthcoming process management application in future - I'll definitely have my guard up for that!

As far as my problem goes, it turns out that the memory leak is related to the OLE interface to RS Linx, which good ol' Allen Bradley / Rockwell provides. We were told "Hey, use Windows 98 + it'll work fine", but since that's not really a viable solution, my customer is now going to kick up a big fuss to AB!

Anyway, thanks for your help bro!
Lego

--------
Ben,

You know I've always been curious about that one! if I have an object which is instantiated within a function (in say, a standard module), then shouldn't that object get automatically destroyed when the function is exited? (i.e. The reference count automatically gets set to 0 when you exit the function)

But to let you know, we took the appropriate precautions you suggested, on top of knocking on a few doors belonging to a certain vendor! So thanks for your help!

Peace Thanks!
LeGo PiEcE

"The Computer Spock! Destroy it!" - Captain James T. Kirk

 

[MikeCox]

When you say 'Ben', I assume ur talking to me?

The way I understand it, if a function declares a long integer, the variable goes out of scope when the function does, like you say. But that's only a convenience provided by the compiler, it knows it can safely clear it off the stack at the end of the function. But it can't do this with objects, because your destructor (Class_Terminate event) may not have a chance to run. I suppose there must be other reasons, but I'm not sure what they may be. For example, in C++ you have to set your pointers to NULL when they're out of scope, but a pointer isn't an object (actually it's just a number), therefore there should be no concern as to wheather a destructor method would be skipped. But failure to set them to NULL will cause memory leaks, and there has to be a good reason why the compiler can't destroy them for you. It knows the size and scope, but it's still up to the programmer to clean up.

Good luck, and I'm glad you got to the bottom of it!

~Mike Any man willing to sacrifice liberty for security deserves neither liberty nor security.

-Ben Franklin

 

[LegoPiece]

Hey Mike!

Sorry about calling you 'Ben'! I think that demonstrates the ludicrous amounts of stress I'm under on a perennial basis! =)

Interesting post! I agree with you 100%, however the Dan Appleman book did allude that objects with a 0 reference count will automatically kill themselves. I guess that applies to an out-of-process object (like a Mutex) - when it no longer has any clients making reference to it, it'll wipe itself out, pure and simple. I can understand why in-process objects have to be taken care of by the programmer, to prevent 'stacked' instances leading to memory leaks!

Anyway, thanks again dude!




Thanks!
LeGo PiEcE

"The Computer Spock! Destroy it!" - Captain James T. Kirk

 

[JohnYingling]

Object references ARE supposed to be freed automatically when they go "Out of Scope". At one time, there was some problem with a DAO object that caused a memory leak if the object reference was not specifically set to Nothing.
I just ran the following code 140,000 time in the VB IDE under Win 2000. Memory usage was 13,368K before execution and 13,464K while running with no increase.

Private Sub Command1_Click()
Dim i As Long
    For i = 0 To 4000000
        MakeObject
    Next
End Sub
Private Sub MakeObject()
    Dim obj As Scripting.Dictionary
    Set obj = New Scripting.Dictionary
    
End Sub

It is still good practice to set all objects to Nothing when you are done with them, especially Out of Process objects like Word because they CAN go way EVEN if you hold a reference an cause real probems if you use the reference. See

http://msdn.microsoft.com/library/d...ml/vbconvisualbasiccomponentshutdownrules.asp

"For example, suppose an out-of-process component is being used by two clients, and that client A releases all of its object references before client B does. If the component is holding internal references to the objects client A was using, they will go on taking up memory and resources until the component shuts down — which will not happen until client B releases the last of its objects."

http://www.VBCompare.com

Compare Code (Text)

http://www.VBSortGen.com

Generate Sort in VB or VBScript

 

[LegoPiece]

John,

Help me understand this please! So, let's say Client A starts running and makes reference to an Out-of-process component OPC1, which in turn makes references to objects within Client A. Client B starts executing and also makes reference to OPC1. When Client A shuts down, OPC1 continues to exist because Client B still makes reference to it, HOWEVER... are you essentially saying that the objects within Client A could continue to exist (even though ClientA has shut down) because OPC1 continues to make reference to them, while being kept alive by Client B?

Whew... sounds like a soap opera, but I THINK I get it! Thanks!
LeGo PiEcE

"The Computer Spock! Destroy it!" - Captain James T. Kirk

 

[JohnYingling]

Hey, Lego.

I did not say that. I said that Micriosoft said that . So if you relate this to anyone, say that I said that Microsoft said that circular references have driven Microsoft to give up on counting reference to objects in .NET and call in Tony Soprano for waste management i.e. garbage collection.

http://www.VBCompare.com

Compare Code (Text)

http://www.VBSortGen.com

Generate Sort in VB or VBScript