Memory keep growing 
Author Message
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 
 [ 10 post ] 

 Relevant Pages 

1. mtx memory usage keeps growing?

2. Access 97 Temporary File keeps growing and growing for the same very large tx

3. Database Keeps Growing (Paradox 4.x) HELP!

4. Trying to Keep Details From Growing

5. help: ODBC, dbSqlPassThrough, and Memory Leak/grow?

6. My data base grows and grows just by run a code

7. Database grows and grows

8. Component keeping old variables in memory

9. Internet Transfer Control Keeps Eating Memory

10. WebBrowser keep memory

11. How to keep modifications in memory ?

 

 
Powered by phpBB® Forum Software