Will an IntPtr remain valid after memory compaction?

Question

I'm in .NET and using pointers to access raw image data. Currently I'm storing a reference to the Scan0 (and Stride) of the bitmap using:

BitmapData bmpData = bmp.LockBits(...);
*byte scan0 = (*byte)bmpData.Scan0;

Sometimes my program randomly crashes with errors like "Attempted to access protected memory". I'm assuming this is because my pointer becomes invalid after the .NET GC routinely compacts memory. So if I use IntPtr instead of the *byte pointer that I currently use, will the pointer remain valid after memory compaction?

BitmapData bmpData = bmp.LockBits(...);
IntPtr scan0 = bmpData.Scan0;

Obviously its near impossible to test this because I cannot replicate the "random" memory errors I'm getting, so I'm trying to arrive at a theoretically correct solution and hope it corrects my issues.

Edit: Please do not start a discussion on bitmap manipulation techniques. I just want to know if IntPtr is any better than *byte.

I'm curious about it. Does bmpData.Scan0 points to the managed memory? — Cédric Bignon, Jul 24 '13 at 13:49
See this: http://jieyanghu.com/2010/12/29/manipulating-raw-bitmap-data-in-net/ — Colin Smith, Jul 24 '13 at 13:50
You do NOT have to pin `Scan0`. That memory is not managed, so the GC can't move it around. The accepted answer to the linked question makes this point in the third and fourth paragraphs. — Jim Mischel, Jul 24 '13 at 13:54
IntPtr is just a numeric type that is the same size as a pointer. It has no magical GC powers. — Raymond Chen, Jul 24 '13 at 13:54
http://stackoverflow.com/questions/1148177/just-what-is-an-intptr-exactly — Colin Smith, Jul 24 '13 at 14:00
Your assumption is incorrect, so your conclusions are based on faulty reasoning. Your program is not crashing because the garbage collector is compacting the managed heap; your program is crashing because you have a bug. — Eric Lippert, Jul 24 '13 at 14:50

score 2 · Answer 1 · answered Jul 24 '13 at 13:59

IntPtr is an integer that has the same size as a pointer. It does not get tracked by the GC.

The LockBits() method already ensures that the GC will not move the bitmap data around.

If you are getting access violations, there's two possible causes:

You are accessing memory outside of the bitmap (e.g. incorrect coordinates).
You are accessing the bitmap data after the UnlockBits() call

score 2 · Accepted Answer · answered Jul 24 '13 at 14:16

No, that's not a problem for bitmap pixel data. It is allocated in unmanaged memory, the garbage collector can't touch it. It is actually a memory-mapped file, the reason that loading or saving a bitmap puts a lock on the file. The LockBits() method ensures that memory-mapped file is mapped to memory and the view is stable. This kind of optimization is required because bitmaps can be very large and the memory for them should not be backed by the paging file.

Anyhoo, using byte* or IntPtr is not a problem, the memory they point to is guaranteed to be stable as long as the bitmap is locked.

The kind of problem you ought to be looking for is running off the end of the bitmap, you are using unsafe pointers so you won't get a friendly IndexOutOfRangeException. The AV however ought to be the next best diagnostic, assuming it actually occurs inside the code that's bracketed by the lock. Having a mismatch between the pointer type and the pixel format could be a cause. There's way too little code in the snippet to theorize beyond this.

Will an IntPtr remain valid after memory compaction?

2 Answers2