GC contains lots of pinned objects after a while.

views:

722

answers:

+1 Q:

GC contains lots of pinned objects after a while.

+2 A:

Well, there's a bug in your code in that you're creating a lot of IDisposable instances and never calling Dispose on them. I'd hope that the finalizers would eventually kick in, but they shouldn't really be necessary. In your production code, do you dispose of everything appropriately - and if not, is there some reason why you can't?

If you put some logging in the AlphaImage finalizer (detecting AppDomain unloading and application shutdown and not logging in those cases!) does it show the finalizer being called?

EDIT: One potential problem which probably isn't biting you, but may be worth fixing anyway - if the call to CreateImageFromBuffer fails for whatever reason, you still own the memory created by AllocHGlobal, and that will currently be leaked. I suspect that's not the problem or it would be blowing up more spectacularly, but it's worth thinking about.

Jon Skeet 2008-12-17 10:59:57

The finalizer is being called (if it wouldn't I would be out of memory in a matter of seconds).Actually, there is an Image class wrapper around the AlphaImage class that calls the Dispose of the AlphaImage.

Stormenet 2008-12-17 11:38:13

Still, you shouldn't count on the finalizer - that's what IDisposable is for.You should use the using (image) { ... } construct to make sure the Dispose method is called as soon as possible. Also, use GC.SuppressFinalize() in Dispose() so that the finalizer will not be called for a disposed object.

configurator 2008-12-17 13:00:38

@configurator: True about the suppressFinalize, I added that. However, since it's an Image, much like an usual bitmap, it is used in usercontrols so you can't use the using construct, so I have to rely on the finalizer.

Stormenet 2008-12-17 13:16:13

UserControls should have a Dispose tree going down from top control to bottom. That what the dispose method automatically generated in the designer.cs is for in part. This should call your user control which should dispose any children that contain resources.

Quibblesome 2008-12-23 13:38:48

I doubt it's a bug in RPM. What we don't have here is any insight into the Ppb.Drawing stuff. The place I see for a potential problem is the GetIImagingFactory call. What does it do? It's probably just a singleton getter, but it's something I'd chase.

I also see an AllochHGlobal, but nowhere do I see that allocation getting freed. For now that's where I'd focus.

ctacke 2008-12-17 12:19:57

GetIImagingFactory is indeed a singleton getter.The Allocated memory from AllocHGlobal is freed by the com object itself. In the CreateImageFromBuffer call I secify it should free the memory from HGlobal memory.

Stormenet 2008-12-17 12:46:58

Oh, to be clear, when I look at the heap of the Application, I don't see any pinned objects (other than those I pin myself).

Stormenet 2008-12-17 13:25:16

ansaurus

tags:

views:

answers:

GC contains lots of pinned objects after a while.

related questions