We are having a condtion in a large VWG-based application where, according to MS Support, the Finalizer thread triggers a GC and then is blocked waiting for the GC to complete.

The memory dumps we provided shows that Gizmox_WebGUI_Common!Gizmox.WebGUI.Forms.ComponentBase.Finalize() is trying to allocate a large object.

We know that it's bad practice to allocate objects during a Dispose, so we do avoid that. We also know that disposing of objects in our code rather than letting the GC do it for us is a best practice, so we do that where possible. Still, I see that we can have a half-million or more objects in our finalization queue, the large majority of which are of type Gizmox.WebGUI.Forms.ListViewItem.

My questions are:

1. Has anyone else run into this?

2. What other than doing little in Dispose and disposing of the objects that we can ourselves is recommended to avoid this?

3. I have the VWG 6.4 source code that I use for reference, but I don't see the code for ComponentBase in there. Is that available somewhere, or at least the Dispose/Finalize method code for it?

Thanks.

-Kelly

Maybe a better way to ask the question is this. Does ListViewItem.Dispose() call GC.SuppressFinalize(this) at any point in the hierarchy?

I can't locate source code for RegisteredComponent or anything above it, so I can't know for sure.

What I can see is that, even if I unwire the .MenuClick event handler and call Dispose on each ListViewItem just before calling ListView.Items.Clear(), all of our ListViewItem instances still end up in the finalize queue.

That could be because GC.SuppressFinalize(this) is not called anywhere in the hierarchy -- typically, that would be called in a  Dispose() method with no parameters, which would then also call Dispose(true).

It can be for some other reason, but I'd like to rule out this one if someone at Gizmox with access to the source code could check and let me know please.

Thanks.

-Kelly

 Thanks, Ori. I will work on a reproducible scenario ASAP.

Please note that you wouldn't see a call to any method named Finalize. Instead, if there were an explicit finalizer, it would be named like the constructor, but preceded by ~. So the finalizer, if there were an explicit one for, say, ComponentBase, would be a method named ~ComponentBase.

As I understand it, that method would only ever be called from the GC, and it's purpose would be to invoke Dispose(false) so that the object can be disposed, but (the false part) so that the dispose code knows to NOT try to dispose member objects that may no longer exist (no guaranteed order of cleanup at GC time). Ideally, the developer using the disposable object would call Dispose() when he/she is done (or put their code in a using() block) in which case as your code snippet shows, the object would get disposed, along with objects its managing, and then the object would be marked such that the GC would say "hey, this one already has been properly disposed, so don't put it in the finalization queue -- less work for me!"

In the absence of an explicit finalizer method, GC still will finalize IDisposable objects (if it hasn't been suppressed) by calling Dispose(false) - just no custom code would be executed in that condition (other than what's in Dispose(bool disposing) and not bracketed by if (disposing).

The call to GC.SuppressFinalize(this) is made to prevent GC from putting the object (this) in the queue for finalization. Obviously, that code exists (as you verified, thanks) in ComponentBase. If it were getting called, we shouldn't be seeing so many objects in our finalization queue.

One way for it NOT to be called would be having a Dispose() override anywhere in the chain that does not do a base.Dispose() call. I will look for that in our code, but so far have not seen it.