StateMachine incorrectly sets up the message filters for a state

[sudilav]

StateMachine incorrectly sets up the message filters for a state

[sudilav]

There also seems to be some kind of race condition happening, I can't get my second state to move to the third state however if I break at line

MARTe2/Source/Core/Scheduler/L4StateMachine/StateMachine.cpp

Line 189 in f551f39

currentStateStatus = Exiting;

and wait a while and then break at

MARTe2/Source/Core/Scheduler/L4StateMachine/StateMachine.cpp

Line 227 in f551f39

if (errSend.ErrorsCleared()) {

after some time, I can see that the state change occurs.

This setup has Mode = ExpectsReply.

[sudilav]

That was a red herring, the state was actually moving to the error state instead. So possibly not a race condition - the scheduler we're using is the GAMBareScheduler

Looking through how this works:

• MessageGAM sends message to StateMachine to GOTOSTATE1 (or 2) and waits for Reply - must be an indirect Reply.
• StateMachine receives message and calls up application to move states in three messages. and waits for indirect replies from application.
• Application triggers the scheduler to run through the changes:
  

  MARTe2/Source/Core/BareMetal/L5GAMs/RealTimeApplication.cpp

  Line 512 in f551f39

  ret = scheduler->StartNextStateExecution();

The odd behaviour is also that when it goes to error state as the file input for my test is end of file, it moves to state 3 then - not the error state instead.

[sudilav]

It looks like this only executes once:

MARTe2/Source/Core/Scheduler/L4StateMachine/StateMachine.cpp

Line 114 in f551f39

ReferenceT<ReferenceContainer> state = Get(i);

When I in fact have 4 states

[sudilav]

Okay I'm going to spend today having a good look at this. I suggest for the first state issue, the application name used in the config be a parameter for the StateMachine object. Then when it starts up, it sends a message to the application and the application will have a messagefilter setup at startup to listen for this message, when it hears this message, it then sends back the name of the state that it is starting in. Then the statemachine will execute the section which adds the message filters for this. This does create a bit of a race condition so maybe once the statemachine has completed setup, it then sends back to the application to continue as it is ready to do so. @aneto0

[sudilav]

It seems I've narrowed the issue down to the fact that the third message here:

MARTe2/Source/Core/Scheduler/L4StateMachine/StateMachine.cpp

Line 341 in f551f39

err = MessageI::SendMessage(eventMsg, this);

Never actually returns. So something about having the RT App/Scheduler call to start the next state causes this to stall. Possibly it kills the thread?

[sudilav]

Diving further, this is because This function call never returns:

MARTe2/Source/Core/BareMetal/L4Messages/RegisteredMethodsMessageFilter.cpp

Line 69 in 61e2192

ret = destinationObject->CallRegisteredMethod(methodName, *(messageToTest.operator->()));

This is because it calls this function when it is the third message:

MARTe2/Source/Core/BareMetal/L5GAMs/RealTimeApplication.cpp

Line 508 in 61e2192

ErrorManagement::ErrorType RealTimeApplication::StartNextStateExecution() {

My Scheduler is the GAMBareScheduler. This basically seems to then execute within this thread/stack in an infinite loop:

MARTe2/Source/Core/BareMetal/L5GAMs/GAMBareScheduler.cpp

Line 64 in 61e2192

ErrorManagement::ErrorType GAMBareScheduler::StartNextStateExecution() {

So the question is: How does the RealTimeApplication start the first state thread in the first place using prepare etc... and not have to wait, when it is happy to continue moving forward.

[sudilav]

It seems this possibly happens again, when we look at our logs, this call:

MARTe2/Source/Core/BareMetal/L6App/RealTimeLoader.cpp

Line 103 in 61e2192

err = rtApp->StartNextStateExecution();

Never then progress to print out:

MARTe2/Source/Core/BareMetal/L6App/RealTimeLoader.cpp

Line 105 in 61e2192

REPORT_ERROR_STATIC(ErrorManagement::Information, "Started application in state %s ", destination.Buffer());

I just reran my testing with GAMScheduler and didn't find this issue.... dratt. The whole reason we're using GAMBareScheduler is because of the MaxCycles has been exploited so we can use this for simulations and then running testing in a pipeline on Gitlab.

[sudilav]

Focusing on the issue of the StateMachine assuming you start in the first state. I can see it gets initialised here:
https://github.com/sudilav/MARTe2/blob/162882ac4416431163bc8ce084ca9db9acf91223/Source/Core/BareMetal/L6App/Loader.cpp#L142

PrepareNextState never gets called for it as it isn't part of the application but a seperate entity.

The data field in the Loader function does know and contain the first state but this doesn't get passed onto the Initialise function so is an inaccessible variables to the StateMachine to possibly know what the first state is.