[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.sdk

Re: C# memory problem: no end for our problem ?

Ted Miller

9/13/2003 8:46:00 PM

Isn't this what GC.WaitForPendingFinalizers is for?

For example I use an external COM object over which I have no control, that
keeps a file open for exclusive access. When the COM object is destroyed,
the file is released. Fine in COM but the rest of my C# program wants to
open that file for read access once I've finished using the COM object to
manipulate the file.

The following:

MyComObject obj = new MyComObject("filename");
//...
obj = null;
GC.Collect();

does not work reliably, but the addition of

GC.WaitForPendingFinalizers()

seems to do the trick.

--

"Andre" <food_crazy@hotmail.com> wrote in message
news:3EE60105.7000004@hotmail.com...
> Who even suggested to you that a Garbage Collector frees up memory
> instantly? No there's not bug in the algorithm and there's nothing wrong
> with the garbage collector; you guys should know a little more about
> garbage collectors before thinking there's something wrong. C#
> implements a generational garbage collector (not that it helps answer
> your concerns, but thought you should know)... this garbage collector
> (when invoked manually) does not collect garbage instantly.. it calls
> the finalize method on each object and waits for all the finalizers to
> finish before collecting. This is because some object at a later stage
> might require an object's services which is supposedly dead, in which
> case the object is "resurrected".. this is why you will not always see
> the call to GC apparently successful and you should *NEVER* rely on the
> GC thinking that calling GC would clean everything up.. try cleaning
> things as much as you can, for example scarce resources or shared
> resources, and leave the rest to the GC because the GC will happen in
> its own time - it is *not* deterministic.
>
>
> Andre
>
> Matthew Phillips wrote:
> > Have you called GarbageCollector.Collect (?) to free up manually. If mem
> > usage goes down it just means the GC hasn't got round to it yet.
> >
> > Have you looked at the IDispose interface/pattern - required for classes
> > which hold non-managed resourcse?
> >
> > Matt
> >
> >
> > "Kedar Agarkar" <kedar.agarkar@patni.com> wrote in message
> > news:900a3723.0306030549.653a317f@posting.google.com...
> >
> >>Dear Friends,
> >>
> >>PROBLEM SUMMARY:
> >>
> >>A C# .NET based application at our end has memory leak problem.
> >>Application uses COM inter-op to take the services of an ATL ActiveX
> >>control.
> >>
> >>The leak is not being detected.
> >>
> >>The ATL ActiveX is free from leaks as shown by BoundsChecker 7.0 run
> >>with application and ActiveX. But the C# allocations are not probably
> >>getting freed. Team suspects this to be the failure of C# garbage
> >>collection algorithm.
> >>
> >>PROBLEM IN DETAIL:
> >>
> >>Work Environment:
> >>Visual C++ 7.0 - .NET, ATL with Visual C++ 7.0, Visual C# .NET,
> >>Windows XP.
> >>
> >>The said ActiveX controls wraps up the Win32 calls for serial
> >>communication. The controls help the Container application to use the
> >>multithreaded framework in itself to poll multiple serial ports in
> >>real time fashion. The serial ports are connected to industrial
> >>automation instruments at other end.
> >>
> >>The C# application that uses this ActiveX control via COM inter-op
> >>makes calls to this control in separate thread(s). Each C# thread is
> >>exclusively dedicated to polling from only one serial port. The thread
> >>function of this thread is of following nature:
> >>
> >>ThreadProc()
> >>{
> >> /*Activex.OpenComPort()*/
> >>
> >> (go on loop-ing till exit event is set)
> >> {
> >> /*ActiveX.PollForData()*/
> >>
> >>/* Wait for kernel event set by ActiveX to indicate that data is
> >>ready after serial port interration */
> >>
> >>/*ActiveX.GetData()*/
> >>
> >>/*Send the data fetched to views asynchronously*/
> >> }
> >>
> >>
> >>}
> >>
> >>As the polling for data needs to be in as fast manner as possible, the
> >>thread goes on doing these activities consuming relatively more CPU.
> >>
> >>As the application is left running for more than few hours, the memory
> >>that has been allocated goes on increasing as indicated by Task
> >>Manager of Windows. As the ActiveX is free of leaks as done with the
> >>help of BoundsChecker 7.0, the team suspects that the memory that has
> >>been allocated continuously by this infinite thread loop does never
> >>gets freed by C#'s garbage collection.
> >>
> >>TROBLESHOOT ATTEMPTS:
> >>
> >>Teams tried with following ways to trouble shoot the problem.
> >>
> >>1. Ensured that all the objects that are not in use for particular
> >>iteration of loop are marked 'null' invariably. This does not seem to
> >>be helping to free the memory.
> >>2. Adjusted the declarations of local and member variables of thread /
> >>threadproc.
> >>3. Forced the calls to garbage collector. However, garbage collector
> >>does not seem to be acting any more effective after such calls.
> >>4. Included thread suspension calls in order to give Garbage
> >>collection some time to collect. Does not help.
> >>5. Used Win32 API calls SetProcessWorkingSetSize() that shall reduce
> >>the RAM usage. This did not solve the problem completely but changed
> >>its manifestations. Only the RAM is reduced. But this makes virtual
> >>memory increasing continuously till you get message that your virtual
> >>memory is full.
> >>6. Changed the ActiveX to have empty functionalities inside each of
> >>function call but this did not eliminate the problem.
> >>7. Dispensed the use of ActiveX control but instead wrote similar
> >>empty calls within the C# application and tested this thread for
> >>polling loop. But still the memory is increasing.
> >>8. .NET memory profiler use also was of not much use in indicating
> >>which allocations are not getting freed.
> >>
> >>CONCLUSION:
> >>
> >>As per team's understanding and analysis, the cumulative increase in
> >>memory is due to failure of C# garbage collection algorithm.
> >>
> >>Team has previously experiences the similar problem of memory. A C#
> >>string variable was being passed 'by ref' recursively to the end node
> >>from the root node of a BTree and this pass by reference was resulting
> >>into substantial memory consumption by application.
> >>
> >>HELP SOUGHT ON:
> >>
> >>1. Team will like to know expert comments as to what could be the root
> >>cause of memory not getting freed in our C# application.
> >>2. If use of ActiveX via COM inter-op may be adding to this problem or
> >>what.
> >>3. If there is any configuration issue of .NET Framework that needs to
> >>be done to resolve this issue.
> >>4. Is there any way to flush the virtual memory pagefile.sys file.
> >>5. The way to fix this problem.
> >>
> >>
> >>Thanks for your time
> >>- Kedar Agarkar
> >
> >
> >
>