Memory leak advice needed

[Boni]

I use 3-d party component. In this component I must pass a reference to my
object. The problem is that this component has an ugly bug.When this
component is disposed, it incorrectly don't delete the reference to my
object from one of its shared lists.And since the operation repeats many
times the leak is huge.
Is there a way to kill my object anyway?
Thanks a lot,
Boni

[Ken Halter]

Re: Memory leak advice needed

"Boni" <oilia@nospam > wrote in message
news:%23rqn3wt6 FHA.3048@TK2MSF TNGP10.phx.gbl. ..[color=blue]
>I use 3-d party component. In this component I must pass a reference to my
>object. The problem is that this component has an ugly bug.When this
>component is disposed, it incorrectly don't delete the reference to my
>object from one of its shared lists.And since the operation repeats many
>times the leak is huge.
> Is there a way to kill my object anyway?
> Thanks a lot,
> Boni[/color]

You should contact that 3rd party provider.... have you tried passing a
reference to Nothing? Depending on how that 3rd party component works,
passing a ref to Nothing may clear the circular dependency.... then again,
it may raise an error (which you should be able to trap)

--
Ken Halter - MS-MVP-VB (visiting from VB6 world) - http://www.vbsight.com
Please keep all discussions in the groups..

[Boni]

Re: Memory leak advice needed

The 3-d party provider is Microsoft :). I am speeking about a memory leak
when I create a context menue items dynamically
(http://weblogs.asp.net/pwilson/archi...20/77451.aspx). They are not
disposed until the form is disposed.
It is documented bug and there is a workaround for that (using reflection).
But in general, somehow I don't see the reason of garbadge collection.
Before I started with it I was sure that it completely solve all memory leak
problems. But it seems, that it creates a new class of memory leak problems,
where you must think very much about all your references. And even then
there is no insurance that something went wrong because of 3-d party bugs.
I mean, .NET is a perfect libruary, easy to use. But the memory leak problem
should be revised once more. Currently there is even no appropriate software
which can automatically check those bug's (a-la bounds checker). For me
there was no problem to kill all created objects myself in c++. There are
coding guidlines and problem is quite managable. But in .NET I spend all my
time by looking for memory leaks, it is even more time then debugging. And I
am still not sure, when the debug level is acceptable.
Is it only my problem or all of you have it too?



"Ken Halter" <Ken_Halter@Use _Sparingly_Hotm ail.com> schrieb im Newsbeitrag
news:u4L9Zzt6FH A.3752@tk2msftn gp13.phx.gbl...[color=blue]
> "Boni" <oilia@nospam > wrote in message
> news:%23rqn3wt6 FHA.3048@TK2MSF TNGP10.phx.gbl. ..[color=green]
>>I use 3-d party component. In this component I must pass a reference to my
>>object. The problem is that this component has an ugly bug.When this
>>component is disposed, it incorrectly don't delete the reference to my
>>object from one of its shared lists.And since the operation repeats many
>>times the leak is huge.
>> Is there a way to kill my object anyway?
>> Thanks a lot,
>> Boni[/color]
>
> You should contact that 3rd party provider.... have you tried passing a
> reference to Nothing? Depending on how that 3rd party component works,
> passing a ref to Nothing may clear the circular dependency.... then again,
> it may raise an error (which you should be able to trap)
>
> --
> Ken Halter - MS-MVP-VB (visiting from VB6 world) - http://www.vbsight.com
> Please keep all discussions in the groups..
>[/color]

[Dennis]

Re: Memory leak advice needed

I saw the fix below in one of the MIcrosoft articles for MainMenu (they
apparently can also have the same memory leak problems as Context Menus so I
would assume this fix would also apply them them as well but not sure)

For any forms that have MainMenu components, add the following code to make
sure the components are disposed of correctly:
Protected Override Sub Dispose(disposi ng as boolean)
If disposing
If not components is Nothing
components.Disp ose()
components = Nothing
If not mainMenu1 is Nothing
‘Code to add
mainMenu1.Dispo se()
mainMenu1 = Nothing
base.Dispose(di sposing)
End If
End If
End If

--
Dennis in Houston


"Boni" wrote:
[color=blue]
> The 3-d party provider is Microsoft :). I am speeking about a memory leak
> when I create a context menue items dynamically
> (http://weblogs.asp.net/pwilson/archi...20/77451.aspx). They are not
> disposed until the form is disposed.
> It is documented bug and there is a workaround for that (using reflection).
> But in general, somehow I don't see the reason of garbadge collection.
> Before I started with it I was sure that it completely solve all memory leak
> problems. But it seems, that it creates a new class of memory leak problems,
> where you must think very much about all your references. And even then
> there is no insurance that something went wrong because of 3-d party bugs.
> I mean, .NET is a perfect libruary, easy to use. But the memory leak problem
> should be revised once more. Currently there is even no appropriate software
> which can automatically check those bug's (a-la bounds checker). For me
> there was no problem to kill all created objects myself in c++. There are
> coding guidlines and problem is quite managable. But in .NET I spend all my
> time by looking for memory leaks, it is even more time then debugging. And I
> am still not sure, when the debug level is acceptable.
> Is it only my problem or all of you have it too?
>
>
>
> "Ken Halter" <Ken_Halter@Use _Sparingly_Hotm ail.com> schrieb im Newsbeitrag
> news:u4L9Zzt6FH A.3752@tk2msftn gp13.phx.gbl...[color=green]
> > "Boni" <oilia@nospam > wrote in message
> > news:%23rqn3wt6 FHA.3048@TK2MSF TNGP10.phx.gbl. ..[color=darkred]
> >>I use 3-d party component. In this component I must pass a reference to my
> >>object. The problem is that this component has an ugly bug.When this
> >>component is disposed, it incorrectly don't delete the reference to my
> >>object from one of its shared lists.And since the operation repeats many
> >>times the leak is huge.
> >> Is there a way to kill my object anyway?
> >> Thanks a lot,
> >> Boni[/color]
> >
> > You should contact that 3rd party provider.... have you tried passing a
> > reference to Nothing? Depending on how that 3rd party component works,
> > passing a ref to Nothing may clear the circular dependency.... then again,
> > it may raise an error (which you should be able to trap)
> >
> > --
> > Ken Halter - MS-MVP-VB (visiting from VB6 world) - http://www.vbsight.com
> > Please keep all discussions in the groups..
> >[/color]
>
>
>[/color]

[AMercer]

Re: Memory leak advice needed

> The 3-d party provider is Microsoft :). I am speeking about a memory leak[color=blue]
> when I create a context menue items dynamically[/color]

The logic below works for me with context menus built by my programs:

Dim cm As ContextMenu
' your code goes here to create cm including click event handler(s)
cm.Show(up to you, up to you)
Application.DoE vents() ' needed to raise and process the click event
cm.Dispose() ' required, else memory leak

[Cor Ligthert [MVP]]

Re: Memory leak advice needed

Boni,

What do you think that dispose does?

Cor

[Boni]

Re: Memory leak advice needed

Hi Amerser,
Why are u so sure? Have you checked with a profiler. This logic don't works
because of MS bug (in .NET 1.1.). There is still a static reference inside
of form (which you didn't created), but .NET did. So your cm will not be
disposed untill a form is disposed. Hope I don't disappoint you:). Take a
profiler and look yourself.


"AMercer" <AMercer@discus sions.microsoft .com> schrieb im Newsbeitrag
news:3237004F-77F4-4F2D-8FF2-A64A0130B8BD@mi crosoft.com...[color=blue][color=green]
>> The 3-d party provider is Microsoft :). I am speeking about a memory leak
>> when I create a context menue items dynamically[/color]
>
> The logic below works for me with context menus built by my programs:
>
> Dim cm As ContextMenu
> ' your code goes here to create cm including click event handler(s)
> cm.Show(up to you, up to you)
> Application.DoE vents() ' needed to raise and process the click event
> cm.Dispose() ' required, else memory leak
>[/color]

[Boni]

Re: Memory leak advice needed

Wellcome in club you have the same memory leak, but you don't know about it.
"AMercer" <AMercer@discus sions.microsoft .com> schrieb im Newsbeitrag
news:3237004F-77F4-4F2D-8FF2-A64A0130B8BD@mi crosoft.com...[color=blue][color=green]
>> The 3-d party provider is Microsoft :). I am speeking about a memory leak
>> when I create a context menue items dynamically[/color]
>
> The logic below works for me with context menus built by my programs:
>
> Dim cm As ContextMenu
> ' your code goes here to create cm including click event handler(s)
> cm.Show(up to you, up to you)
> Application.DoE vents() ' needed to raise and process the click event
> cm.Dispose() ' required, else memory leak
>[/color]

[Boni]

Re: Memory leak advice needed

Hi Cor, hi all,
I know about dispose and try to explicitely call it, but as you see, for
examle with context menus this don't prevent memory leak.
In general,my point is following.
IMHO it is much harder to find memory leaks in .NET. There are no tools for
this, and application don't crash. I miss a possibility to find such bugs.
(profiler can't really help if your app creates and disposed many objects,
you can't manually filter out correced objects from leaked objects. A have
programmed many years C++ and there are programming rules and tools which
allow to minimize memory leak (in my whole carrier the leak finding time was
not higher then a development time). But in .NET it is very hard to attack
memory leak problems. This is absolutely manual and time consuming process,
which kills .NET productivity win. The problem in .NET is even bigger
(IMHO), then in unmanaged code. If you don't deleted only 1 reference the
whole chain of objects can stay undeleted and you will even NOT notice it.
I think, that we need some possibility, at least to automatically detect
exact point of memory leaks. (but so far I have no idea how it would be
possible)
Are you agree with me or is it only my problem and nobody except me has it.
Thanks a lot for your opinions,


"Cor Ligthert [MVP]" <notmyfirstname @planet.nl> schrieb im Newsbeitrag
news:Of7rHx06FH A.2716@TK2MSFTN GP11.phx.gbl...[color=blue]
> Boni,
>
> What do you think that dispose does?
>
> Cor
>[/color]

[Fredrik Melin]

Re: Memory leak advice needed

Just a tip, when I suspect an object for memory leak, I do a simple program
to test it, within a for i as integer = 0 to 10000 or something, so you can
see if that is really the object causing the problem..


- Fredrik

"Boni" <oilia@nospam > wrote in message
news:O7FbO466FH A.3388@TK2MSFTN GP11.phx.gbl...[color=blue]
> Hi Cor, hi all,
> I know about dispose and try to explicitely call it, but as you see, for
> examle with context menus this don't prevent memory leak.
> In general,my point is following.
> IMHO it is much harder to find memory leaks in .NET. There are no tools
> for this, and application don't crash. I miss a possibility to find such
> bugs. (profiler can't really help if your app creates and disposed many
> objects, you can't manually filter out correced objects from leaked
> objects. A have programmed many years C++ and there are programming rules
> and tools which allow to minimize memory leak (in my whole carrier the
> leak finding time was not higher then a development time). But in .NET it
> is very hard to attack memory leak problems. This is absolutely manual and
> time consuming process, which kills .NET productivity win. The problem in
> .NET is even bigger (IMHO), then in unmanaged code. If you don't deleted
> only 1 reference the whole chain of objects can stay undeleted and you
> will even NOT notice it.
> I think, that we need some possibility, at least to automatically detect
> exact point of memory leaks. (but so far I have no idea how it would be
> possible)
> Are you agree with me or is it only my problem and nobody except me has
> it.
> Thanks a lot for your opinions,
>
>
> "Cor Ligthert [MVP]" <notmyfirstname @planet.nl> schrieb im Newsbeitrag
> news:Of7rHx06FH A.2716@TK2MSFTN GP11.phx.gbl...[color=green]
>> Boni,
>>
>> What do you think that dispose does?
>>
>> Cor
>>[/color]
>
>[/color]

[AMercer]

Re: Memory leak advice needed

> Why are u so sure? Have you checked with a profiler. This logic don't works[color=blue]
> because of MS bug (in .NET 1.1.). There is still a static reference inside
> of form (which you didn't created), but .NET did. So your cm will not be
> disposed untill a form is disposed. Hope I don't disappoint you:). Take a
> profiler and look yourself.[/color]
[color=blue]
> Wellcome in club you have the same memory leak, but you don't know about it.[/color]

No - no such leak. I know it works for two reasons. First, I don't
associate the cm with a form - no form contains a "static reference" to the
cm. Form.ContextMen u is Nothing throughout all my operations, and tying a cm
to a form is an essential ingredient to the problem you are talking about.

The second reason is that I use a tool (a vb function I wrote) when I am
worried about a memory leak. The tool minimizes the working set, and it
garbage collects until diminishing returns, and it then reports memory
figures to me. The testing I did was to popup and dismiss (all ways of
dismissing) a cm many times while running the memory tool every 5 seconds or
so. The cm approach I described yields no memory growth.

[Boni]

Re: Memory leak advice needed

[color=blue]
> No - no such leak. I know it works for two reasons. First, I don't
> associate the cm with a form - no form contains a "static reference" to
> the
> cm. Form.ContextMen u is Nothing throughout all my operations, and tying a
> cm
> to a form is an essential ingredient to the problem you are talking about.[/color]
neither I did.I even had no form, just a control.
Look in internet for " allCreatedMenuI tems ". This is internal static
hashtable of the control class. AFAIK there is no chance to avoid the leak,
if you create CM. The reference to this CM will be added into static
hashtable of an active control, you don't have to assign something.There is
a workaround, how to free this hashtable using reflection or memory is
automatically fried, when control dies.
[color=blue]
> The second reason is that I use a tool (a vb function I wrote) when I am
> worried about a memory leak. The tool minimizes the working set, and it
> garbage collects until diminishing returns, and it then reports memory
> figures to me. The testing I did was to popup and dismiss (all ways of
> dismissing) a cm many times while running the memory tool every 5 seconds
> or
> so. The cm approach I described yields no memory growth.[/color]
Hmm..., ok you must know it. In any case thanks for the idea. May be I will
write something like this for all my classes.
Best wishes,
Boni

[AMercer]

Re: Memory leak advice needed

> Look in internet for " allCreatedMenuI tems ".

Good idea, just finished doing that. Very interesting and very disturbing.
I thought this problem had been fixed by MS many months ago. (I'm using .net
fw 1.1 sp1, windows xp, all updates suggested by MS have been installed). In
all cases, I do

Dim mi As new MenuItem("blah blah", ClickHandler) ' always this
constructor
mi.Enabled = Enabled ' a previously computed boolean
mi.Checked = Checked ' ditto

Then, mi is added to the cm (others created and added similarly), and then
the logic proceeds as discussed in my earlier post. MenuItems are never
reused or updated in any way after they are shown, but creation is always a
new menuitem, update Enabled, and update Checked.

I don't think the 'allCreatedMenu Items' issue is biting me, and I don't know
why. It sounds from the internet discussion that it has to bite everybody.
It seems to me that MS must have fixed it within the last year or so. A
search of MS web site for 'allCreatedMenu Items' yields nothing. A search for
menuitem and leak is unproductive - they have a fix in an MDI situation.

FYI, one contributor to the discussions indicated that he thought a disabled
menuitem was an essential ingredient to creating the problem. I ran a test
with my procedures that included a disabled menuitem. No problems, no leaks.

I still think my procedures work ok, at least in my environment and with the
kinds of programs that I write. Maybe my procedures won't work in a
different setting, and that makes me nervous.

[Cor Ligthert [MVP]]

Re: Memory leak advice needed

Boni,

The name "managed" code is mainly to prevent memory leaks, the Framework
should tackle that for you.

In the sample you gave the object should stay undeleted. An object should
stay as long as it has its own reference, however as well as any object is
referenced to it, what can be a long chain. Therefore are 3 types of
processes the GC to look if an object is ready to release.

If you want an explanation more in dept of this, have than a look what Willy
has written in the dotnet General newsgroup about this.

http://groups.google.com/group/microsoft.public.dotnet.general/search?group=microsoft.public.dotnet.general&q=willy+memory+leak&qt_g=1&searchnow=Search+this+group

I hope this helps,

Cor