General Protection Error after second 'New Downlaod' or 'Online Change'

Question

I'm trying to build a composite pattern in Twincat 3.1.

Everything seems to work fine on Activate Configuration and the first new download or online change. The second new download causes General Protection Error or BSOD, no matter how many objects I add or remove.

For simplicity, Object is FB implementing the I_SYS_COMP_Object interface.

The project uses FB_init and FB_exit to add or remove objects from the global object list. Previous iterations used call_after_init attributes with the same result.

As the code became lengthy, I'm adding a link to the repository. GitHub rep

How should I approach this kind of issue?

Edit 26/11:

Core dump and exception mode don't work.

So far, I have found that:

IF object <> 0 THEN 
    RETURN; 
END_IF 
_this_object = THIS^; 
IF object.parent <> THIS^ THEN 
    RETURN;
END_IF 

was part of the problem. Now I'm getting BSOD a few lines below, at

_last_child := object; 

Which is strange as this should be a straightforward assignment. Currently, _last_child is used only in the problematic method. I put a RETURN; straight after the assignment, but I'm still getting BSOD.

Answer 1

I cannot provide specific guidance regarding your issue, but my experience is debugging code called from FB_Init is extremely frustrating because you cannot step into the code.

I have therefore developed an approach where I use FB_Init for very simple things (mostly assignments, often REF= assignments) and delaying actual initialization code until after FB_Init methods have been called. I implemented my own, separate, initialization and execution framework which makes this easy. I am losing my hair at a slower pace thanks to this approach.

I use assertions a lot (especially preconditions in methods, including FB_Init), and I crash the runtime when observing an out-of-spec situation. I check them in FB_Init calls, but the framework actually delays crashing until normal execution begins. That way, I am not losing information about the reason for the crash as I would if it were to happen during FB_Init execution. Catching invalid references passed to FB_Init is one frequent case where this saves a lot of aggravation.