GameMonkey Script

Hi,

recently I got a strange infinite loop in the garbage collector, by digging in the code i found that the problem is caused by a RemoveCPPOwnedGMObject.
The condition seems quite rare and I am not sure if is caused by wrong usage of RemoveCPPOwnedGMObject.

We have a gmUserObject that holds a CPP object (a callback delegate object) that holds a GameMonkey function by using AddCPPOwnedGMObject.
When the first gmUserObject is collected by GC and the Destruct function is called, the internal CPP object is released and his cpp destructor calls RemoveCPPOwnedGMObject
to release the ownership of the gm function.

RemoveCPPOwnedGMObject internally write a barrier that change the order of the objects inside GC,
but at that time we are inside a GC DestructSomeFreeObjects function that is iterating the objects and has references to m_next and m_prev.
This condition can break the integrity of the internal list (maybe only when the two objects are consecutive).

This is just my supposition about what is happening but I am not 100% sure,
Is our design wrong? Are we doing something that it is not suppose to be done?

Question: WriteBarrier purposes is just to have a GC don't miss any object right? What it does is just pop the object to the top of the gray objects so it is evaluated again.
If WriteBarrier is not called what's happen is that an object that could be collected immediately will be collected later in another pass. Or I am missing something.

Thanks
Paolo

Pretty much. The write barrier is critical for the integrity of the system, and does behave in similar fashion to what you describe... During collection, a reference is changing, so, in our case, the left hand (old reference) side must be reprocessed.
Since we allocate 'black' in the current GC, the write barrier can be turned off when not collecting as integrity can't be compromised.

I have a fuzzy understanding of what is going on from your description.
It seems the write barrier is being called from an unexpected location, which corrupts the internal linked list.

My thoughts:
I think when a gmObject is destructing, it is deemed to be safe, with no critical reference to live objects.
It is also destructed in a phase when the GC is not tracing.
I think the WriteBarrier should not be called, or should not operate at this time.
Making the list delete safe is difficult.
Looking at the code, I think the WriteBarrier should not fire, but does so because the GC is not flagged as off, when it should be.

Instead of making you change your code, I think the GC can be 'fixed' to resolve this situation.
All I've done is reorder some code so object destruction occurs while GC is flagged off, then paranoid flagged it to enforce this.

Please try the attached files and tell me if this helps.

Your thoughts make perfectly sense.

I integrated your patch and I will test it.
But I think that it fixed the problem.

I will let you know.
Thanks