.NET 4: Can the managed code alone cause a heap corruption?

Question

I have a heap corruption in my multi-threaded managed program. Doing some tests I found that the corruption happens only when the background threads active in the program (they are switchable). The threads use some 3rd party components.

After examining the code of the threads and 3rd party components (with .NET Reflector) I found that they are all managed, i.e. no "unsafe" or "DllImportAttribute" or "P/Invoke". It seems that the purely managed code causes a heap corruption, is this possible?

UPDATE

Apart from using Marshal class, is it possible to corrupt the heap with threads not being correctly synchronized? An example would be very appreciated.

Just because they are all managed, does not mean that everything is thread safe. Are you making sure the code executes in a thread safe manner, using locks, etc. where required? — Chris Dunaway
@ChrisDunaway, are you saying that improper locking or executing threads in non-thread-safe manner can corrupt the heap even without using Marshal class? I had an answer that this is not possible (here). — net_prog

JaredPar JaredPar · Accepted Answer · 2011-09-27T18:55:08

It's definitely possible to corrupt the heap without any use of unsafe code. The Marshal class is your friend / enemy here

IntPtr ptr = new IntPtr(50000);  // Random memory
byte[] b = new byte[100];
Marshalp.Copy(b, 0, ptr, 100);

This effectively copies 100 consecutive 0's into the heap at address 50000.

Another way is with explicit struct layouts

[StructLayout(LayoutKind.Explicit)]
struct S1
{
    [FieldOffset(0)]
    internal string str;

    [FieldOffset(0)]
    internal object obj;
}

S1 s = new S1();
s.obj = new Program();
s.str.Trim();  // Hope that works ... :)

.NET 4: Can the managed code alone cause a heap corruption?

1 Answers