Force Garbage Collection

[JDYoder]

Is there a way to tell / force the Garbage Collection to do it's think and release all the stuff it's holding?

[IceAzul]

GC.Collect()

[IngisKahn]

/me notes that's usually a Bad Idea.

(waits for PD's links) :)

[thenerd]

Using Gc.collect is, as mentioned, usually not something you should do. Basically, it's a quick, inefficient band-aid to a memory leak. You should try to plug those leaks instead, because Gc.collect is processor intensive and very slow.

[Wraith]

Read this Rico Mariani's Performance Tidbits - When to call GC.Collect().

[neodammer]

/me notes that's usually a Bad Idea.

(waits for PD's links) :)

 

 

Agreed. Debugging perhaps the one of the few reasons I could see use. Many better ways than GC.Collect()

 

I would personally use a memory program (many free online) to check the memory for leaks when you run the program and go from there with rewriting code.

[JDYoder]

I definitely have a memory leak, but it's not from my code, but from a third-party control we purchased. So I was trying to determine if I could force GC to release the memory the control continues to eat up. However, the real problem seems to be their control is not telling the GC to dump it in the first place, so trying this didn't help. Thanks anyway.

[PlausiblyDamp]

Have you tried running the CLRProfiler against your application to check where these allocations are coming from? What does this 3rd party control do? How much memory is it leaking?

Unless the control is allocating critical resources it shouldn't need to tell the GC anything - when variables are no longer required the GC can free up the memory. If the variable isn't going out of scope then it makes no odds how often you call GC.Collect() there will be nothing to collect.

 

If the problem really is the 3rd party control then have you contacted their support to see about a fix?

[JDYoder]

>> Have you tried running the CLRProfiler against your application to check where these allocations are coming from?

 

No. What's that?

 

 

 

 

>> What does this 3rd party control do?

 

It's the DataDynamics Designer control that gives end users an interface to create reports.

 

 

 

 

>> How much memory is it leaking?

 

That's the odd thing. Maybe I'm wrong to call it memory, so maybe you can help me out. If I watch the Task Manager, the memory never goes out of control. However, if I watch the counters in ".NET CLR Memory" within the "Performance" application (under Administrators Tools in the Control Panel) I see two values that continue to climb and never drop back down, even after I've stopped the app and closed Visual Studio. Those two counters are...

 

1) # of GC Handles

2) # of Sink Blocks in use

 

Once they reach a certain height, my entire computer locks up, even though Task Manager show there is plenty of Memory left. (Maybe it crashed because "# Total reserved Bytes" seems to remain static? *shrug*)

 

 

 

 

>> If the problem really is the 3rd party control then have you contacted their support to see about a fix?

 

Yeah. If curious, I posted my question (and got their response) here. Not very helpful: http://www.datadynamics.com/ShowPost.aspx?PostID=78299

[PlausiblyDamp]

If it's leaking GC Handles then I would personally class that as "a bad thing" ™ - a GC handle is a handle to a managed object that is being passed to an unmanaged API. If these are not being cleaned up then I would class it as a bug - pure and simple.

GC Handles need to be explicitly freed by calling GCHandle.Free(), unfortunately there is nothing you can do to fix this as firstly it is a problem with their code and secondly a GCHandle is a value type and not at the mercy of the garbage collector.

[JDYoder]

How would I use GCHandle.Free? (I typed it into VB.NET but it was unrecognized.) You say I can't use it, but I'll at least pass it on to them and see if they can intergrate it.

 

Also, do you have any idea what "# of Sink Blocks in use" are and what can be done about them?

[PlausiblyDamp]

GCHandle

You wouldn't be able to do anything with it - if they are allocating them it is their responsibility to free them, they should be aware of how to free the handle as they are the ones that are allocating them in the first place so I doubt telling them about this is going to help.

 

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/gngrfMemoryPerformanceCounters.asp is probably worth a glance over to explain what the various counters mean.

[Nerseus]

I've never worked with DataDynamics. But, if you have proof that their product has a memory leak and you let them know, I would bet they'd provide a fix. Is it possible that you're using their component in some way, but forgetting to call some method when you're done? Even if you're not positive that their code has the memory leak, you could show them some sample code and ask for advice.

 

I've used DevExpress and they were VERY responsive to bugfixes (and there were many - but that was about two years ago) as long as we were able to provide code sample to illustrate the problem. Before you send anything off, make sure you have someone else read it and see if they have any questions - if they do, then DataDynamics will likely have the same questions and they may be less likely to respond.

 

-ner

[FZelle]

If it is really leaking and they don't fix it, change to something different.

 

On Codeproject.com there is just a link to easyreports.

The Developer put the aktuell version into freeware, incl. the source.

It also has a designer.

[JDYoder]

I've never worked with DataDynamics. But' date=' if you have proof that their product has a memory leak and you let them know, I would bet they'd provide a fix...[/quote']

 

I've already tried. They're not being very helpful: http://www.datadynamics.com/ShowPost.aspx?PostID=78299