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]

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

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)

 

[Boni]

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/archive/2004/02/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?

 

[Guest]

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(disposing as boolean)
If disposing
If not components is Nothing
components.Dispose()
components = Nothing
If not mainMenu1 is Nothing
‘Code to add
mainMenu1.Dispose()
mainMenu1 = Nothing
base.Dispose(disposing)
End If
End If
End If

--
Dennis in Houston

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/archive/2004/02/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?

 

[Guest]

The 3-d party provider is Microsoft . I am speeking about a memory leak

when I create a context menue items dynamically

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.DoEvents() ' needed to raise and process the click event
cm.Dispose() ' required, else memory leak

 

[Cor Ligthert [MVP]]

Boni,

What do you think that dispose does?

Cor

 

[Boni]

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.

 

[Boni]

Wellcome in club you have the same memory leak, but you don't know about it.

 

[Boni]

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,

 

[Fredrik Melin]

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

 

[Guest]

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.

Wellcome in club you have the same memory leak, but you don't know about it.

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.ContextMenu 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]

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.ContextMenu is Nothing throughout all my operations, and tying a
cm
to a form is an essential ingredient to the problem you are talking about.

neither I did.I even had no form, just a control.
Look in internet for " allCreatedMenuItems ". 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.

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.

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

 

[Guest]

Look in internet for " allCreatedMenuItems ".

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 'allCreatedMenuItems' 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 'allCreatedMenuItems' 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]]

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/micr...emory+leak&qt_g=1&searchnow=Search+this+group

I hope this helps,

Cor