RGBSurface Memory Leak

I wrote a function that converts a picture into a memoryblock and then do some other things, i discover that if i do:


dim rgbs as rgbsurface = scaledpicture.RGBSurface
  // Memory Block
  mb= new MemoryBlock(width*height*3)
  // Fill it
  for y=0 to h
    for x=0 to w
    next x
  next y

THIS will cause a huge memory leak (this function is called multiple times, cycle) Images:1920x1080

I changed to :

// Memory Block
  mb= new MemoryBlock(width*height*3)
  // Fill it
  for y=0 to h
    for x=0 to w
    next x
  next y

Now i have no memory leak problem…

Is this a Xojo bug ?


  • is this Carbon Cocoa Win32 or Linux?
  • is the picture an old-style or new-style picture?

Whats that about? Did I miss a change?

Alpha channel vs. Mask. Admittedly, this isn’t a recent change (RS2011r4).

But to access it, you have to compile to Cocoa (since RS2011r4).

You do not have to worry about that if you compile to Carbon (in that case, you have to ask seriously why you stay behind; you may have a good reason).

This worried me a bit, as I have something very similar in code, following a very recent change to a method I did another way for years.

So I checked my code.

Using Xojo 2013 R2

Using this code (non relevant stuff remove)

[code] dim bigpic2 as new picture(cwidth * 3, cheight * 3,32)
dim bigpic2rgb as RGBSurface

//code removed here

for sx = 0 to cw
sx3 = sx*3 +1
for sy = 0 to ch
//checking every 3rd pixel
if bigpic2rgb.pixel(sx3, sy *3) = &cffffff then

   // do stuff

  end if


I don’t see any memory leak.
That doesn’t point a finger, but it means that there is a way not to lose memory when using rgbsurface.pixel
So: is yours an alpha channel picture, and which Xojo are you using?

This was made in Win32, and only happens if i use that code inside a function and called from a cycle.


I tried your code in Win32 and do not experience any memory leak.

I looped a 100 times over your function with a 2000x2000 picture.

Using graphics.pixel is very time consuming compared to RGBSurface.pixel

And have you considered using this code :
Dim mb As MemoryBlock
mb = scaledPicture.GetData(Picture.FormatBMP)

Hi Alexandre

See this is from long ago.

This is execatly the same issue you had I think.

Just test what you were doing and your are right that works.

Here is the code

  dim p as picture
  dim colorPixel as Color
    for i as integer = 0 to 10
      f = new FolderItem("../Large/image.jpg",FolderItem.PathTypeShell) // just reference any file in you environment
      dim myRGB as RGBSurface
      if f <> Nil then
        p = Picture.Open(f)
         //myRGB = p.RGBSurface // If I omit this line, no Reference build up, no memory leak
        //colorPixel = myRGB.Pixel(1,1)  // This also together with the previous line is the culprit.
        colorPixel = p.Graphics.Pixel(1,1)  // This is how you did it, and then no reference build up....
        Print("****************** next file ****************")
        Print ("Object Count: " + Runtime.ObjectCount.ToText + " Using memory : " + Runtime.MemoryUsed.ToText)
        dim L as Integer = Runtime.ObjectCount -1
        for k as integer = 0 to L
          Print("ObjectID: " + Runtime.ObjectId(k).ToText + " Class: " + Runtime.ObjectClass(k).ToText + " Refs: " + Runtime.ObjectRefs(k).ToText)
      end if
      p = nil
      myRGB = nil
    next i
  end if

If you change this back to the following

         myRGB = p.RGBSurface // If I omit this line, no Reference build up, no memory leak
        colorPixel = myRGB.Pixel(1,1)
        // colorPixel = p.Graphics.Pixel(1,1)

This just stacks up additional memory and never release it until the end of the program

Doing this in the console. I was initially running it over many files, and they are large 2500x2500. Quickly running into GB and the program fails. I then narrowed it down to this one statement. The rest of the program is a reduced version fo my code.

So the answers here were never addressing this issue.

You do not even have to do a pixel inspect. You just have to assign anything from the RGBSurface to a “local” copy, like even the myRGB = p.RGBSurface, (or even just check the Pixel in an If Statement), and then it never release the Picture references. This referencing of the RGBSurface is enough to create in memory a Object Reference to the Picture you can never release.

My picture add about 25MB per picture to the memory. OSX Console, El Capitan, etc. The way my code turned out, I was creating and additional 65,000 references per additional image in the original code.

I could live with your solution in the meantime, but I think this is really a BUG.

Thanks for writing about this issue. I was using RGBSurface variables all over my code. By removing them, it has made a large improvement in running my program. I am surprised that this bug is still seen in version 2017r1.1 shouldn’t this have been fixed by now?

be aware that


was deprecated in 2016r1 [not to be confused with RGBsurface.pixel]

Make sure that you file a Feedback report ASAP. Xojo don’t fix what they don’t know.

it already has a case number, 41715, from 2015. Memory leaks make your program unstable so I consider this to be a serious bug. Not sure when XoJo will fix this for good.

Thanks for the info Dave! I updated my code to remove all graphics.pixel usage.