Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error transition same state causes stack overflow #2546

simpsoneric opened this issue Dec 9, 2020 · 2 comments · Fixed by #2564

Error transition same state causes stack overflow #2546

simpsoneric opened this issue Dec 9, 2020 · 2 comments · Fixed by #2564


Copy link

simpsoneric commented Dec 9, 2020


When performing a Fault Tree Analysis with a component error behavior where the target state is the same name as the source state, a stack overflow occurs.

Expected and Current Behavior

A syntax error should be generated if the following is written

       error behavior AllGood
                BadVal: Operational -[Failure]-> Operational;
       end behavior;

According to AS5506/1A E.8.2 paragraph (4), the correct label for the target state should have been the text same state instead of Operational.

Steps to Reproduce

  1. Instantiate sys.i
  2. Execute "fault tree analysis"
package simple_unhandled
    annex EMV2 {**
        error behavior AllGood
                Failure: error event;
                Operational: initial state;
                Failed: state;
                BadVal: Operational -[Failure]-> same state;
        end behavior;
	system sys
            dinA: in data port;
            dinB: in data port;
			dout: out data port;

        annex EMV2 {**
            use types ErrorLibrary;
            use behavior simple_unhandled::AllGood;
            error propagations
				dinA: in propagation  {ItemValueError};
				dinB: in propagation  {ItemValueError};
				dout: out propagation {ItemValueError};

--                    pA: error path dinA -> dout;
--                    pB: error path dinB -> dout;
                    esrc: error source dout {ItemValueError};
			end propagations;

            component error behavior
                    Operational -[ dinA{ItemValueError} ]-> dout{ItemValueError};
            end component;
	end sys;
	system implementation sys.i
	end sys.i;

end simple_unhandled;


"Help" example for "Transient and Persistent Faults in the Sensor" also describes a state transition with the target label as the source. This also causes a stack overflow.


  • OSATE Version: OSATE2 2.9.0.vfinal
  • Operating System: 4.15.0-124-generic #127-Ubuntu SMP
@lwrage lwrage added this to the 2.9.2 milestone Jan 16, 2021
@keh181 keh181 self-assigned this Jan 22, 2021
Copy link

It seems we might be missing a legality or naming rule in the standard to properly flag this error

Could be a naming rule like

“The source state reference and the target state reference cannot identity the same defining state identifier in the namespace of the error behavior state machine containing the reference.”

It would echo the following naming rule from E.8:

"The source state reference and target state reference must identify a defining state identifier in the namespace of the error behavior state machine containing the reference."

@lwrage do you want me to create an errata for this?

Copy link

lwrage commented Jan 25, 2021

@jjhugues The proposed naming rule is insufficient if you have typed states, e.g., a{e1} -[...]-> a{e2} should be valid. We could also leave everything as is and not explicitly require same state for steady state transitions. It is really necessary only for the situation where the source is all and you want to define a steady state transition (with the same condition) for each state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

Successfully merging a pull request may close this issue.

4 participants