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

Saturnalia

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? – Chloropicrin

There are also Marshal class methods which can do this. – Unchartered

@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). – Saturnalia

Answer 1

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 ... :) 

Subjective

Re. structs, common [StructLayout(LayoutKind.Sequential)] will not cause the heap corruption, right? – Saturnalia

@Saturnalia no, LayoutKind.Explicit is needed for this trick to work / crash :) – Subjective

@Saturnalia in general it's not possible for managed code to corrupt the heap. These are just a few ... extreme cases which could cause it. It's possible however improbable that you hit a CLR bug. – Subjective

What do you think about the last response here? – Saturnalia

Is there a way of doing it with threads not being synchronized correctly? – Saturnalia

@Saturnalia no there is not IMHO – Subjective

@Saturnalia another possible source of heap corruption would be using UI controls improperly from a background thread (i.e. not using Control.Invoke – Subjective

Really? This sounds very interesting, I mean this may give me some ideas on where to look at. – Saturnalia

@Saturnalia any invocation to a control from a background thread except for the noted safe methods (Invoke, BeginInvoke, InvokeRequired, etc ...) is inherently unsafe. It's modifying a native control in an unsafe manner. It could theoretically lead to heap corruption. – Subjective

I just realized that in this case the control will throw an exception that it is being changed from non-UI thread, so this is not possible to do I suppose. – Saturnalia

@Saturnalia most controls and most methods throw an exception. IT's not a foolproof method. – Subjective