Home/ Questions/Q 103317
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T01:06:18+00:00

I have a strange phenomenon while continuously instantiating a com-wrapper and then letting the

  • 0

I have a strange phenomenon while continuously instantiating a com-wrapper and then letting the GC collect it (not forced).

I’m testing this on .net cf on WinCE x86. Monitoring the performance with .net Compact framework remote monitor. Native memory is tracked with Windows CE Remote performance monitor from the platform builder toolkit.

During the first 1000 created instances every counter in perfmon seems ok:

  • GC heap goes up and down but the average remains the same
  • Pinned objects is 0
  • native memory keeps the same average
  • …

However, after those 1000 (approximately) the Pinned object counter goes up and never goes down in count ever again. The memory usage stays the same however.

I don’t know what conclusion to pull from this information… Is this a bug in the counters, is this a bug in my software?

[EDIT]

I do notice that the Pinned objects counter starts to go up as soon the total bytes in use after GC stabilises as does the Objects not moved by compactor counter.

The graphic of the counters http://files.stormenet.be/gc_pinnedobj.jpg

[/EDIT]

Here’s the involved code:

    private void pButton6_Click(object sender, EventArgs e) {         if (_running) {             _running = false;             return;         }         _loopcount = 0;         _running = true;          Thread d = new Thread(new ThreadStart(LoopRun));         d.Start();     }      private void LoopRun() {         while (_running) {             CreateInstances();             _loopcount++;             RefreshLabel();         }     }      void CreateInstances() {         List<Ppb.Drawing.Image> list = new List<Ppb.Drawing.Image>();         for (int i = 0; i < 10; i++) {             Ppb.Drawing.Image g = resourcesObj.someBitmap;             list.Add(g);         }      }

The Image object contains an AlphaImage:

    public sealed class AlphaImage : IDisposable {     IImage _image;     Size _size;     IntPtr _bufferPtr;      public static AlphaImage CreateFromBuffer(byte[] buffer, long size) {         AlphaImage instance = new AlphaImage();         IImage img;         instance._bufferPtr = Marshal.AllocHGlobal((int)size);         Marshal.Copy(buffer, 0, instance._bufferPtr, (int)size);         GetIImagingFactory().CreateImageFromBuffer(instance._bufferPtr, (uint)size, BufferDisposalFlag.BufferDisposalFlagGlobalFree, out img);         instance.SetImage(img);         return instance;     }      void SetImage(IImage image) {         _image = image;         ImageInfo imgInfo;         _image.GetImageInfo(out imgInfo);         _size = new Size((int)imgInfo.Width, (int)imgInfo.Height);     }      ~AlphaImage() {         Dispose();     }      #region IDisposable Members      public void Dispose() {         Marshal.FinalReleaseComObject(_image);     } }
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. 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.

    • 0