In my project, I have a reference to a third-party .NET class library.
My application needs to create an instance of a class about every two
minutes, then discard it a short time later. I've found, however, that
each cycle causes my application to grow about 3 kb. The class does
not implement IDisposable, so I'm cleaning it up by setting the
variable = Nothing.
After the class is instantiated, I need to call a specific method
about 200 times. I've found that each time I call the method, my
application grows about 1 kb. This is a real killer. After a few days
of operation, I get an Out of Memory exception.
From my research, I've learned that the leak is affecting the
unmanaged memory heap. The problem is clearly in the third-party class
library. What can I do about it?
-TC
"TC" <golem...@yahoo.com> wrote in message
news:eb6c96fb-9bd3-417d...@m34g2000hsf.googlegroups.com...
Stephany,
Thank you for the reply. Since fixing the third-party component is out
of the question, however, I was hoping to hear about other options.
One solution I'm considering is to create a completely separate
application to execute the 2-minute bit of functionality that relies
on the third-party component. That seems very inelegant, however.
Perhaps there is a way to do something equivalent with threads?
In doing research, I saw a comment which mentioned that "AppDomain
teardown", although extreme, was a way to recover leaked memory in the
unmanaged heap. What is "AppDomain teardown", and is there any way I
can use it to solve this memory leak problem?
-TC
Two answers in a question like way:
Does this so called "leak" cost you noticable performance or whatever
Are you using taskmanager to get this information, because this is a
known problem from taskmanager.
Cor
Maybe the class exposes a close , shutdown or whatever they called it method
, i have eaven once found a objRelease method in a third party component
Did you declare the class in method scope , or did you declare the class in
an encapsulated (wrapper ) wich you dispose off ? iff so the GC should have
kicked in
you might show us some code ( how you declarer and call the object )
michel
"TC" <golem...@yahoo.com> schreef in bericht
news:eb6c96fb-9bd3-417d...@m34g2000hsf.googlegroups.com...
Why is that out of the question? Send them a support request and complain a
lot and they should fix it.
Michael
The OP wrote:
| After a few days of operation, I get an Out of Memory exception.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>
You are right, can it be that the Op is using something as a recursiving
code as I like it so much and from what you forever wrote in past: If there
is enough memory that is not problem.
:-)
(It is friday)
Cor
Sounds like you're giving up before you even try. This is a MAJOR bug if
it's happening as you describe so you might be suprised at their response.
It's certainly something you have to do any way and anything else is just a
temporary solution until the real problem is fixed.
Michael
- The leak does come at a cost. My application needs to run for weeks,
but I get an Out of Memory exception after ony a few days.
- Yes, I'm using Task Manager to monitor the memory. I know it isn't a
great tool for this purpose, but I'm watching it over a long period of
time (days), and it seems to be okay for that.
- I've looked for Close, Shutdown, Release, Dispose, and any other
method that may cleanup the class, but it just doesn't exist.
- I encapsulated the class in a wrapper, and I'm careful to dispose
the wrapper when I'm done. The memory leaks anyway.
- The reason it will be difficult to get the third-party component
fixed is that it isn't commercial software; it was written by
engineers in a distant branch of the company. They aren't accountable
for the performance of the software, and they aren't responsive to
requests for changes. I'm lucky to have what I've got. Nevertheless,
the point is well taken; I acknowledge that the ideal solution is to
fix their code.
I don't want to post my code because I'm not looking for specific
advice. I really just wanted to know if there was a standard solution
for the "What if a component leaks?" problem. From the replies I've
received, I conclude that there are three options: 1) get the
component fixed; 2) live with the leak; and 3) automatically shut down
and restart the application periodically (per CJ). In this case, I
think the best solution for me may be option 3.
Thanks again to everyone for the help.
-TC
A fourth solution was suggested which was to run the call to the component
via a seperate exe. Seeing that you call this once per 2 minutes, each 2
minutes you could fire up a seperate exe to make the calls for you. That was
your main app can keep running without needing to restart itself.
Michael
Little dramatic don't you think? :-)
Michael
For what it's worth in my app I have menu item to set the time of day
for the reboot to happen and you menu to check which days of the week to
reboot on. We figured the system should be the least busy at 2:00am so
we set it for then. I decided I wanted it to reboot on 2:00am of a day
I would be in at 8:00 in case it failed so selected Friday at 2:00am,
but it's all adjustable. The time and days selected are saved in a cfg
file with other program info. When the program starts or someone makes
adjustments to the reboot info it calculates when it will next reboot using.
Private Sub UpdateAutoReboot()
Dim testDate As Date
Dim tempStr As String
autoRebootActive = False
tempStr = "Auto Reboot Disabled"
For x As Int32 = 0 To 7
testDate =
Now.Date.AddDays(x).AddTicks(TimeValue(rebootTime).Ticks)
If testDate.DayOfWeek = DayOfWeek.Sunday And
SunMenuItem.Checked Or _
testDate.DayOfWeek = DayOfWeek.Monday And
MonMenuItem.Checked Or _
testDate.DayOfWeek = DayOfWeek.Tuesday And
TueMenuItem.Checked Or _
testDate.DayOfWeek = DayOfWeek.Wednesday And
WedMenuItem.Checked Or _
testDate.DayOfWeek = DayOfWeek.Thursday And
ThuMenuItem.Checked Or _
testDate.DayOfWeek = DayOfWeek.Friday And
FriMenuItem.Checked Or _
testDate.DayOfWeek = DayOfWeek.Saturday And
SatMenuItem.Checked Then
If testDate > Now Then 'if x=0 (today) it might be too
late in the day
autoRebootActive = True
nextReboot = testDate
tempStr = "Next Reboot" & vbCrLf & testDate.ToString
Exit For
End If
End If
Next
Label5.Text = tempStr
End Sub
A timer used in the program among other things checks to see if it's
time to reboot. If so it sets a flag and closes the program.
Private Sub Timer1_Tick(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Timer1.Tick
If autoRebootActive And Now() >= nextReboot Then
rebootNow = True
Me.Close()
End If
End Sub
During closing the program if the flag is set to reboot it will do so.
Private Sub Form1_FormClosing(ByVal sender As Object, ByVal e As
System.Windows.Forms.FormClosingEventArgs) Handles Me.FormClosing
Timer1.Enabled = False
If rebootNow = True Then
Dim WMIService, Computer As Object
WMIService =
GetObject("Winmgmts:{impersonationLevel=impersonate,(Debug,Shutdown)}")
For Each Computer In
WMIService.InstancesOf("Win32_OperatingSystem")
Computer.Win32Shutdown(2 + 4, 0) 'reboot
Next
End If
End Sub
Remember to have the pc automatically start your program when it starts.
Fair enough :-) I guess you've got to do whatever gives you the greatest
reliability and running an MS OS a weekly reboot might stop a lot of issues.
(how many times are server issues solved by a reboot :-).
Michael
you told in the thread that fixing the component by the third party is
probably not an option, you also describe that the solution is made inhouse
by another department , this is getting interesting cause in that case you
might have the option to rewrite the component yourself ( no issues with
copyright etc etc )
they probably did not bother to obfuscate the code
Downoad Lutz Roeder`s Reflector for .Net ( Free )
http://www.aisto.com/roeder/dotnet/ and start decompiling and copy pasting
in a new project
i have done this in the past several times and although the code needs some
fixing it is not so hard to rewrite a program from a compiled dll or exe
this way
hth
Michel
"TC" <golem...@yahoo.com> schreef in bericht
news:eb6c96fb-9bd3-417d...@m34g2000hsf.googlegroups.com...
Good idea, I missed the fact that the dll is written in dotnet also. The
other option of course is to just ask for the source code :-)
Michael
I'm trying to obtain the source code. That's going to be an uphill
battle.
This issue has taken an unexpected twist. Before applying any of the
solutions suggested here, I studied the code to see if I could reduce
the number of calls to the leaky component. I found that I don't need
to repeatedly create and discard any objects (Instead, I can create
persistent objects and reuse them). Also, I found I can reduce the
recurring calls to just one method (a benign one -- not the leaky
method mentioned in my original post). After applying those changes,
the leak vanished on the development computer. Yay!
Unfortunately, my tester reports that the leak is still rampant on the
test computer. We are completely baffled by this. We spent the past
day trying to find a difference in the two environments which could
explain why the leak exists on one computer, but not the other. So
far, we've come up with nothing.
In order to solve this, I suspect we will have to do a lot tedious
research, studying the system configurations, comparing precise
versions of dlls, etc. I don't think any advice from the newsgroup can
help us, but I'm posting this message just in case someone has an
inspiration and says "Of course! I know exactly what's happening...".
Thanks again for the earlier help.
-TC