VB COM, Memory keep growing

Memory keep growing

Author	Message
check #1 / 10	Memory keep growing i have a com which is running under MTS and COM+ environment. now my problem is each time i call the com the memory usage(shown in task manager dllhost) is growing and growing i already set the object = nothing but why the memory still growing even the com's status in the Component Service = 0
Sun, 31 Aug 2003 14:54:30 GMT

karl wetti #2 / 10	Memory keep growing You most probably have other objects you don't set to nothing. Check all your functions and class_Terminate if you set the private objects to nothing. Karl Quote: > i have a com which is running under MTS and COM+ environment. > now my problem is each time i call the com the memory usage(shown in task > manager dllhost) is growing and growing > i already set the object = nothing but why the memory still growing > even the com's status in the Component Service = 0
Sun, 31 Aug 2003 19:52:02 GMT

Steven A. Mitchel #3 / 10	Memory keep growing No! Read the up{filter} threads here and in microsoft.public.vb.general.discussion about "Set to Nothing". There is a memory leak somewhere in the app. Judicious use of "Set to Nothing" along with something else will probably handle the problem. Don't blindly set everything to nothing. Steven Quote: > You most probably have other objects you don't set to nothing. > Check all your functions and class_Terminate if you set the > private objects to nothing. >Karl >> i have a com which is running under MTS and COM+ environment. >> now my problem is each time i call the com the memory usage(shown in task >> manager dllhost) is growing and growing >> i already set the object = nothing but why the memory still growing >> even the com's status in the Component Service = 0
Mon, 01 Sep 2003 00:23:26 GMT

karl wetti #4 / 10	Memory keep growing Why would you not want to release the instance of an object when there is no more need for it? How would this be to blindly set them to nothing? Karl Quote: > No! Read the up{filter} threads here and in > microsoft.public.vb.general.discussion about "Set to Nothing". > There is a memory leak somewhere in the app. Judicious use of "Set to > Nothing" along with something else will probably handle the problem. > Don't blindly set everything to nothing. > Steven > > You most probably have other objects you don't set to nothing. > > Check all your functions and class_Terminate if you set the > > private objects to nothing. > >Karl > >> i have a com which is running under MTS and COM+ environment. > >> now my problem is each time i call the com the memory usage(shown in task > >> manager dllhost) is growing and growing > >> i already set the object = nothing but why the memory still growing > >> even the com's status in the Component Service = 0
Mon, 01 Sep 2003 02:18:04 GMT

Steven A. Mitchel #5 / 10	Memory keep growing If the object goes out of scope, VB releases it for you. The only times you have to set to nothing is when the object is not about to go out of scope but you want it released anyway. Prime examples are circular references and releasing early for performance reasons. In both cases, blind setting to nothing of all references accomplishes nothing. Consider: 1. Circular reference. If you have one, you cannot merely set everything to nothing. Rather, you must implement some kind of "Release" (or in DOTNET parlance, "Dispose") method to perform the Set to Nothing at the proper moment. And then you have to remember to call said method. If you don't have that done, then you can set ever object in the app to nothing and the memory leak will still exist. 2. Performance. Allocate object at top of routine. Do something. Done with it but routine does something else intensive. It's helpful to know to release the object "when done". But you have to recognize that the object is resource intensive and that the following code is time consuming enough to call for specific code. If someone thinks that the following accomplishes anything, then I submit that they will not adequately examine either of the above case. Public Sub Something Dim oThing As Thing Set oThing = New Thing oThing.Whatever Set oThing = Nothing ' Useless End Sub ' All objects that just went out of scope released by VB. Steven Quote: > Why would you not want to release the instance of an object when > there is no more need for it? How would this be to blindly set > them to nothing? >Karl >> No! Read the up{filter} threads here and in >> microsoft.public.vb.general.discussion about "Set to Nothing". >> There is a memory leak somewhere in the app. Judicious use of "Set to >> Nothing" along with something else will probably handle the problem. >> Don't blindly set everything to nothing.
Mon, 01 Sep 2003 05:06:01 GMT

karl wetti #6 / 10	Memory keep growing I hope you don't mind me asking you more questions. It is very interesting to hear other peoples view on things. My thougts might not be right, and then it is nice to be corrected. I have lots to learn. steven: Quote: > If the object goes out of scope, VB releases it for you. The only times you > have to set to nothing is when the object is not about to go out of scope > but you want it released anyway. Prime examples are circular references and > releasing early for performance reasons. In both cases, blind setting to > nothing of all references accomplishes nothing. Consider: > 1. Circular reference. If you have one, you cannot merely set everything to > nothing. Rather, you must implement some kind of "Release" (or in DOTNET > parlance, "Dispose") method to perform the Set to Nothing at the proper > moment. And then you have to remember to call said method. If you don't > have that done, then you can set ever object in the app to nothing and the > memory leak will still exist. About circular reference, I usually use a weak pointer to an object to get rith of those annoying helperclasses and strong references. Is this a bad methology? As long I know that the object exists or not this is, according to me, a good solution. I don't have to worry about anything when I release an object with circular reference that way. Or am I in another dimention now? Do you use strong references? How do you take care of object_A pointing to object_B pointing back to object_A without a helper-class? Quote: > Public Sub Something > Dim oThing As Thing > Set oThing = New Thing > oThing.Whatever > Set oThing = Nothing ' Useless > End Sub ' All objects that just went out of scope released by VB. I'm in line with you on this code. However, I don't trust the VB compiler for nothing, that is why I set it to nothing. Just in case the 'garbage- collector' wouldn't work. There are no extra IDispatch calls, just a few extra clockticks for setting the pointer. That I can survive to get rith of any _possible_ memoryleaks. If i'm stupid and the compiler is smart, it will hopefully optimize it automagically. Actually, I don't even trust the compiler to set my booleans to false by default. Might just be me beeing very untrusty. (And why is the VB booelan TRUE -1 and not 1, as in any other place?) Karl
Mon, 01 Sep 2003 07:27:30 GMT

Steven A. Mitchel #7 / 10	Memory keep growing inline: Quote: > I hope you don't mind me asking you more questions. It is very >interesting > to hear other peoples view on things. My thougts might not be right, >and > then it is nice to be corrected. I have lots to learn. Not at all, though you might want to search back in the Dec, Jan timeframe for an extensive discussion of this topic. (There was a lot in Microsoft.public.vb.general.discussion, including several in depth posts from Matt Curland.) Quote: > About circular reference, I usually use a weak pointer to an object to >get > rith of those annoying helperclasses and strong references. Is this a >bad > methology? As long I know that the object exists or not this is, >according > to me, a good solution. I don't have to worry about anything when I >release > an object with circular reference that way. Or am I in another >dimention now? Nope, that's fine. The best way to release a circular reference is to not have it in the first place <grin>. My point is that if you have a circular reference a mere stand-alone set to nothing will not solve it. You may use the actual code "Set x to Nothing" in whatever solution you use (or you may not). But again, it isn't blind. Rather, it's a conscious design decision made to handle the issue. Quote: > Do you use strong references? How do you take care of object_A >pointing to > object_B pointing back to object_A without a helper-class? If I absolutely must have the circular logic, I usually use the strong reference and then wrap all of the code in a some other component so that I can verify that I call the "release" method. I find, however, that I only need this kind of design every once in a blue moon. What I usually do is factor out the "shared" data that makes the child refer to the parent. I find that this usually models the actual problem much better. Something like this: ' clsParent Private m_oShared As Shared Private m_colChildren as Collection Public Sub Init() Set m_oShared = New Shared ' Call code that loads or creates shared data or whatever Set m_colChildren = New Collection End Sub ' clsChild Private m_oShared As Shared Public Sub Init (ParentInfo As Shared) Set m_oShared = ParentInfo End Sub Note that it doesn't really matter what "Shared" has in it. The concept is that "Child" didn't really need to have 100% access to Parent. It isn't going to invoke all of Parent's methods or anything like that. Once you start thinking that way, you realize that Parent was doing two different things--which means that it should be split into two different classes. There's no circular reference at all here. When Parent goes out of scope, it releases its reference to Shared and the collection of Child objects. As each Child object goes out of scope, it releases the remaining references to the Shared object. Naturally, the whole thing is even more useful when Parent happens to be a class factory for the Child objects. Then you can hide the Shared object from Clients; ' add to clsParent Public Function Add() As Child Dim oChild As Child Set oChild = New Child oChild.Init m_oShared ' Init on Child can be Friend method, for example m_colChildren.Add oChild Set Add = oChild End Function I also occasionally use unique IDs and lookup tables. The objects hold the key instead of the object and use the lookup table to resolve the reference as needed. This works great when you very rarely need the parent reference. (In fact, that's just a less performant version of a weak reference that works dynamically with very little code or overhead when not in use.) Quote: >> Public Sub Something >> Dim oThing As Thing >> Set oThing = New Thing >> oThing.Whatever >> Set oThing = Nothing ' Useless >> End Sub ' All objects that just went out of scope released by VB. > I'm in line with you on this code. However, I don't trust the VB >compiler > for nothing, that is why I set it to nothing. Just in case the >'garbage- > collector' wouldn't work. There are no extra IDispatch calls, just a >few > extra clockticks for setting the pointer. That I can survive to get >rith > of any _possible_ memoryleaks. If i'm stupid and the compiler is >smart, > it will hopefully optimize it automagically. Why don't you trust it? No one on this board has been able to come up with a single example of code where it does not work. Matt Curland stated categorically that it always works. What really happens is that "blindly" setting to nothing creates the illusion that maybe you'll blindly cover for a design or code flaw. As I think I showed with the two examples in the previous post, the blind set does not accomplish that objective. I used to think that, so what, a few superflicious sets are not going to hurt anything. But like any other useless code, the net effect is that people start to believe the code is necessary or useful. Then they start to make decisions based on it being there. For example, they start doing this: On Error Goto Trap Dim oThing As Thing Set oThing = New Thing ' Do something with thing Set oThing = Nothing Exit Sub Trap: If Not (oThing Is Nothing) Then Set oThing = Nothing End If Not so bad, you say? Well there also has to be the actual error handling code in there. And The whole structure multiplies with each object and each potential error. Pretty soon, if your consistent, you have projects full of totally useless code. And as Matt Curland also explained, you can never be 100% consistent. VB creates all kinds of temporary objects, sets them to reference other objects, then releases them as required. For example, you trust VB to call release on the temp variable that "With" creates for you. The straw that breaks the camel's back is when you go to solve a real memory leak in the above type of project. In a clean project, I can usually eyeball it and find the circular reference. (Same kind of situation applies to solving performance problems.) In totally useless code, however, there are hundreds of lines of "release" code to scan through before the real problem can be found. And finally, every time someone on one of these boards asked how to solve a memory leak, someone answers "make sure you set all your objects to nothing". I have visions of all these programmers doing like a guy in our organization and spending several days following that advice and being no closer to solving his leak. <grin> Steven
Mon, 01 Sep 2003 08:18:05 GMT

karl wetti #8 / 10	Memory keep growing This is exactly why I plan to stay reading these groups more. Great reading. Thanks! Karl- more wise than before. Quote: > inline: > > I hope you don't mind me asking you more questions. It is very > >interesting > > to hear other peoples view on things. My thougts might not be right, > >and > > then it is nice to be corrected. I have lots to learn. > Not at all, though you might want to search back in the Dec, Jan timeframe > for an extensive discussion of this topic. (There was a lot in > Microsoft.public.vb.general.discussion, including several in depth posts > from Matt Curland.) > > About circular reference, I usually use a weak pointer to an object to > >get > > rith of those annoying helperclasses and strong references. Is this a > >bad > > methology? As long I know that the object exists or not this is, > >according > > to me, a good solution. I don't have to worry about anything when I > >release > > an object with circular reference that way. Or am I in another > >dimention now? > Nope, that's fine. The best way to release a circular reference is to not > have it in the first place <grin>. My point is that if you have a > circular reference a mere stand-alone set to nothing will not solve it. You > may use the actual code "Set x to Nothing" in whatever solution you use (or > you may not). But again, it isn't blind. Rather, it's a conscious design > decision made to handle the issue. > > Do you use strong references? How do you take care of object_A > >pointing to > > object_B pointing back to object_A without a helper-class? > If I absolutely must have the circular logic, I usually use the strong > reference and then wrap all of the code in a some other component so that I > can verify that I call the "release" method. I find, however, that I only > need this kind of design every once in a blue moon. What I usually do is > factor out the "shared" data that makes the child refer to the parent. I > find that this usually models the actual problem much better. Something > like this: > ' clsParent > Private m_oShared As Shared > Private m_colChildren as Collection > Public Sub Init() > Set m_oShared = New Shared > ' Call code that loads or creates shared data or whatever > Set m_colChildren = New Collection > End Sub > ' clsChild > Private m_oShared As Shared > Public Sub Init (ParentInfo As Shared) > Set m_oShared = ParentInfo > End Sub > Note that it doesn't really matter what "Shared" has in it. The concept is > that "Child" didn't really need to have 100% access to Parent. It isn't > going to invoke all of Parent's methods or anything like that. Once you > start thinking that way, you realize that Parent was doing two different > things--which means that it should be split into two different classes. > There's no circular reference at all here. When Parent goes out of scope, > it releases its reference to Shared and the collection of Child objects. As > each Child object goes out of scope, it releases the remaining references to > the Shared object. Naturally, the whole thing is even more useful when > Parent happens to be a class factory for the Child objects. Then you can > hide the Shared object from Clients; > ' add to clsParent > Public Function Add() As Child > Dim oChild As Child > Set oChild = New Child > oChild.Init m_oShared ' Init on Child can be Friend method, for > example > m_colChildren.Add oChild > Set Add = oChild > End Function > I also occasionally use unique IDs and lookup tables. The objects hold the > key instead of the object and use the lookup table to resolve the reference > as needed. This works great when you very rarely need the parent reference. > (In fact, that's just a less performant version of a weak reference that > works dynamically with very little code or overhead when not in use.) > >> Public Sub Something > >> Dim oThing As Thing > >> Set oThing = New Thing > >> oThing.Whatever > >> Set oThing = Nothing ' Useless > >> End Sub ' All objects that just went out of scope released by VB. > > I'm in line with you on this code. However, I don't trust the VB > >compiler > > for nothing, that is why I set it to nothing. Just in case the > >'garbage- > > collector' wouldn't work. There are no extra IDispatch calls, just a > >few > > extra clockticks for setting the pointer. That I can survive to get > >rith > > of any _possible_ memoryleaks. If i'm stupid and the compiler is > >smart, > > it will hopefully optimize it automagically. > Why don't you trust it? No one on this board has been able to come up with > a single example of code where it does not work. Matt Curland stated > categorically that it always works. > What really happens is that "blindly" setting to nothing creates the > illusion that maybe you'll blindly cover for a design or code flaw. As I > think I showed with the two examples in the previous post, the blind set > does not accomplish that objective. > I used to think that, so what, a few superflicious sets are not going to > hurt anything. But like any other useless code, the net effect is that > people start to believe the code is necessary or useful. Then they start to > make decisions based on it being there. For example, they start doing this: > On Error Goto Trap > Dim oThing As Thing > Set oThing = New Thing > ' Do something with thing > Set oThing = Nothing > Exit Sub > Trap: > If Not (oThing Is Nothing) Then > Set oThing = Nothing > End If > Not so bad, you say? Well there also has to be the actual error handling > code in there. And The whole structure multiplies with each object and each > potential error. Pretty soon, if your consistent, you have projects full of > totally useless code. And as Matt Curland also explained, you can never > be 100% consistent. VB creates all kinds of temporary objects, sets them to > reference other objects, then releases them as required. For example, you > trust VB to call release on the temp variable that "With" creates for you. > The straw that breaks the camel's back is when you go to solve a real memory > leak in the above type of project. In a clean project, I can usually > eyeball it and find the circular reference. (Same kind of situation applies > to solving performance problems.) In totally useless code, however, there > are hundreds of lines of "release" code to scan through before the real > problem can be found. > And finally, every time someone on one of these boards asked how to solve > a memory leak, someone answers "make sure you set all your objects to > nothing". I have visions of all these programmers doing like a guy in our > organization and spending several days following that advice and being no > closer to solving his leak. <grin> > Steven
Mon, 01 Sep 2003 08:41:03 GMT

Steven A. Mitchel #9 / 10	Memory keep growing inline: Quote: >assume that i built a ASP page and two COMs >the code in asp page as below >... >Set oA = createObject("A.A") >Set oC = createObject("B.C") >oA.Name = "Buddy" This expects a "Set" property called "Name". I don't see one in the objects below. Also, I'm assuming that something else happens with oA and oC, because the objects have no relation with each other at all, given this code. Quote: >... >Set oA = nothing >Set oC = nothing >Now the code in COM 1 as below >Function A() > Property Get Name() as string > .... > Set oB = createObject("B.B") > Set oC = CreateObject("B.C") > oB.Name = mvarName > oC.Name = mvarName > .... > Set oC = nothing > Set oB = nothing oB and oC are presumably declared as class variables for some reason? Otherwise, the two Set x = Nothing statements are useless. Quote: >End Function >Now the code in COM 2 as below (contain 2 classes B and C) >Class B >-------- >Function B() > Property Get Name() as string > .... > Set oC = CreateObject("B.C") > oC.Name = mvarName > .... > Set oC = nothing See previous comment. Quote: >End Function >Class C >-------- >Function C() > Property Get Name() as string > .... > Do some work without createobject > .... >End Function >Now my question is >1) If I set oA = Nothing and set oC = nothing in asp page, will all object >being destroyed? With the code given, there is not link to the oC created in the asp page and the later ones. When you set oC = nothing (either explicitly or when it goes out of scope), the oC reference is released. If that is the last reference to the oC in question, then VB (via COM) will destroy the object. Quote: >2)The above code shown function C, function B, (property Name) is referring >back to its parent variable. It this so called "Circular references" ?? It's not referring back to anything. It's creating a new, separate object. Quote: >3)since i found some article say object will not be destroyed even set to >nothing so the following code should be work. >...... >set X = nothing 'assume X is not unloaded or destroyed >If isObject(X) then 'so X still an Object so this statement is true > X.Name = "In Memory" 'valid to call the X function >End IF Assuming you represented the article correctly, the article is incorrect. However, I make the caveat because there appears to be some confusionon your part :-) Quote: >4) if component status in Component Service is showing 0, is this mean all >object is being destroyed? No idea. Quote: >5)If memory usage in Task Manager is increasing and will decrease once i >initialize an application. Is this mean there is no memory leak? If you exit your application and nothing is left running, then there is probably no leak. Or at least if there is one, it's one that VB is cleaning up for you. (It's possible that you could be{filter} onto memory during the application run that you really shouldn't. Properly speaking, this isn't a leak but a mere performance, resource issue.) Quote: >6)When I start the component (total of 100 kb check by right click and >select properties) in Component Service, a dllhost will appear in task >manager and its memory usage is above 4000 KB. Why this happen?? (after >calling the COM's function it shot up to above 8000KB) No idea. This code demonstrates a circular reference in its most basic form (warts and all): ' clsParent Private m_oChild As Child Public Sub Init () Set m_oChild = New Child m_oChild.Attach Me End Sub ' clsChild Private m_oParent As Parent Public Sub Attach(Parent As Parent) Set m_oParent = Parent End Sub If client code calls "Init" on a Parent object, then Parent refers to Child and vice versa. If you then release the Parent object in the client code, whether via Set oParent = Nothing or simply letting it go out of scope, you now have a leak. Parent Class_Terminate will never be called, because the Child still has the reference to Parent. And Child will never release that reference because Parent still has a reference to Child. Ergo, you must avoid this issue or code around it. An effective and simple, but potentially error prone, way to handle it is to provide an explicit "Release" method on the Child object(s) (and on the Parent as well, if the Child is not exposed to the Client): ' clsChild extended Public Sub Release() Set m_oParent = Nothing End Sub ' clsParent extended Public Sub Release() m_oChild.Release End Sub Now your client code works like this: Public Sub Something() Dim oParent As Parent Set oParent = New Parent oParent.Init ' Child object allocated as well ' Do something with parent oParent.Release ' Circular refs in Parent handled ' Here oParent can safely go out of scope. End Sub So note that you do need to use the actual line of code "Set x = Nothing"--but in the Child code. If you (or more likely, your client coding buddy) forgets to call oParent.Release, he has a memory leak. If he then goes back and adds "Set oParent = Nothing" in his Something sub, he still has the memory leak. The only reason to "Set oParent = Nothing" is because you are done with it but it isn't about to go out of scope--as in, for example, the Something sub had more work to do after oParent.Release. That's why I said that when I use this method, I usually wrap the whole thing. In other words, my wrapper object is the only way that the client can allocate or release my object. In the wrapper code, I can make sure that I always call "Release" when required. And I can test for the same. Based on the kind of leaks that we keep seeing on this board, I expect that the vast majority could be eliminated if folks simply made such a wrapper for their ADO, Excel, or other code. Steven
Wed, 03 Sep 2003 02:19:42 GMT

check #10 / 10	Memory keep growing thank you for you both response. seem like you both are really expert in VB com i think i found the right person to ask for more difficulty question assume that i built a ASP page and two COMs the code in asp page as below ... Set oA = createObject("A.A") Set oC = createObject("B.C") oA.Name = "Buddy" ... Set oA = nothing Set oC = nothing Now the code in COM 1 as below Function A() Property Get Name() as string .... Set oB = createObject("B.B") Set oC = CreateObject("B.C") oB.Name = mvarName oC.Name = mvarName .... Set oC = nothing Set oB = nothing End Function Now the code in COM 2 as below (contain 2 classes B and C) Class B -------- Function B() Property Get Name() as string .... Set oC = CreateObject("B.C") oC.Name = mvarName .... Set oC = nothing End Function Class C -------- Function C() Property Get Name() as string .... Do some work without createobject .... End Function Now my question is 1) If I set oA = Nothing and set oC = nothing in asp page, will all object being destroyed? 2)The above code shown function C, function B, (property Name) is referring back to its parent variable. It this so called "Circular references" ?? 3)since i found some article say object will not be destroyed even set to nothing so the following code should be work. ...... set X = nothing 'assume X is not unloaded or destroyed If isObject(X) then 'so X still an Object so this statement is true X.Name = "In Memory" 'valid to call the X function End IF 4) if component status in Component Service is showing 0, is this mean all object is being destroyed? 5)If memory usage in Task Manager is increasing and will decrease once i initialize an application. Is this mean there is no memory leak? 6)When I start the component (total of 100 kb check by right click and select properties) in Component Service, a dllhost will appear in task manager and its memory usage is above 4000 KB. Why this happen?? (after calling the COM's function it shot up to above 8000KB) Quote: > No! Read the up{filter} threads here and in > microsoft.public.vb.general.discussion about "Set to Nothing". > There is a memory leak somewhere in the app. Judicious use of "Set to > Nothing" along with something else will probably handle the problem. > Don't blindly set everything to nothing. > Steven > > You most probably have other objects you don't set to nothing. > > Check all your functions and class_Terminate if you set the > > private objects to nothing. > >Karl > >> i have a com which is running under MTS and COM+ environment. > >> now my problem is each time i call the com the memory usage(shown in task > >> manager dllhost) is growing and growing > >> i already set the object = nothing but why the memory still growing > >> even the com's status in the Component Service = 0
Tue, 02 Sep 2003 09:33:03 GMT

Page 1 of 1

[ 10 post ]