<commit_before>---

Copyright 2014 Mentor Graphics Corp.  All Rights Reserved.

---

# Fix execution freeze exiting signal body
### xtUML Project Design Note

1. Abstract
-----------
This note describes the fix for an execution problem encountered in the field.

2. Document References
----------------------
[1] Issues 179, https://github.com/xtuml/internal/issues/179

[2] CQ DEI dts0101040857 - Verifier does not properly handle events generated to
    class instances.

3. Background
-------------
This issue was reported by a customer running model test suites in Verifier.

4. Requirements
---------------
* 4.1 Execution should not stop when exiting a signal body when an activity was
interrupted while blocked waiting on a remote component to return a value.

5. Analysis
-----------
* 5.1 Investigation

This issue was quite challenging to diagnose, because all of the activities
involved had previously been executed many times prior to the failure case.

The reason the failure does not always show itself is that a number of pre-
requisites must be present before the defective code segment is entered; in non-
deterministic mode, an inter-component signal must arrive and be dequeued while
the recipient component is blocked awaiting a result being computed by another
component.

The following sequence diagram illustrates the execution state at the point of
failure:
![Alt text](./ver_blocking_behav.png "Verifier non deterministic mode behavior on blocking.")
In non deterministic mode, each component runs concurrently in its own Java
thread. Each thread runs a single activity at a time until the activity
completes or becomes blocked awaiting the results of a synchronous invocation
(or a void outcome). When this happens, the execution engine looks to see if
any other behavior is outstanding and begins any resulting activity execution.
If there is nothing to do, the component enters a wait state. This behavior is
particularly important for servicing incoming synchronous invocations, because
otherwise there would be a guaranteed deadlock in the scenario where one
component synchronously calls another which in turn synchronously calls the
first. 

In the failure case, the incoming call is asynchronous, but Verifier uses the
same execution policy; the current activity blocks and the waiting incoming
signal begins execution.

The failure manifests when the signal activity started as described above exits
with a return statement. When the return is executed, the reference to the
current statement in the stack frame that is about to have control returned to
it is advanced, even though it was blocked. The result it was awaiting is
available at the point of failure, but because the current statement is
advanced, it is never collected and the newly restored activity execution is
permanently stalled.

5.2 Rectification

Since the interrupting activity was a signal, the return statement must be a
void type return as required by the parser. As such, the behavior should be
almost identical to that shown when an activity runs out of statements and exits
without a return. This scenario is handled in the Block.popUpBlock() operation.
Examination of the OAL in this operation shows that it checks for the existence
of blocking frame, an intermediate value and whether the interrupting activity
is a transition action. Since a return statement is not legal in a transition
action, this possibility is excluded, but the two other cases must be handled in
the defective case.

The locus of the problem itself is the Return Statement.execute() operation.
We surround the first call to Statement.setupNextStatement() with checks for:

5.2.1 Incomplete intermediate value computation

This is found by looking for an instance of 'Value in Stack Frame' found across
R2951 from the stack frame being resumed.

5.2.2 Outstanding blocking activity
<commit_msg>Reference failure point in sequence<commit_after>---

Copyright 2014 Mentor Graphics Corp.  All Rights Reserved.

---

# Fix execution freeze exiting signal body
### xtUML Project Design Note

1. Abstract
-----------
This note describes the fix for an execution problem encountered in the field.

2. Document References
----------------------
[1] Issues 179, https://github.com/xtuml/internal/issues/179

[2] CQ DEI dts0101040857 - Verifier does not properly handle events generated to
    class instances.

3. Background
-------------
This issue was reported by a customer running model test suites in Verifier.

4. Requirements
---------------
* 4.1 Execution should not stop when exiting a signal body when an activity was
interrupted while blocked waiting on a remote component to return a value.

5. Analysis
-----------
* 5.1 Investigation

This issue was quite challenging to diagnose, because all of the activities
involved had previously been executed many times prior to the failure case.

The reason the failure does not always show itself is that a number of pre-
requisites must be present before the defective code segment is entered; in non-
deterministic mode, an inter-component signal must arrive and be dequeued while
the recipient component is blocked awaiting a result being computed by another
component.

The following sequence diagram illustrates the execution state at the point of
failure:
![Alt text](./ver_blocking_behav.png "Verifier non deterministic mode behavior on blocking.")
In non deterministic mode, each component runs concurrently in its own Java
thread. Each thread runs a single activity at a time until the activity
completes or becomes blocked awaiting the results of a synchronous invocation
(or a void outcome). When this happens, the execution engine looks to see if
any other behavior is outstanding and begins any resulting activity execution.
If there is nothing to do, the component enters a wait state. This behavior is
particularly important for servicing incoming synchronous invocations, because
otherwise there would be a guaranteed deadlock in the scenario where one
component synchronously calls another which in turn synchronously calls the
first. 

In the failure case, the incoming call is asynchronous, but Verifier uses the
same execution policy; the current activity blocks and the waiting incoming
signal begins execution.

The failure manifests when the signal activity started as described above exits
with a return statement. This would be at "Signal 2 Activity completes" in the
sequence diagram above. When the return is executed, the reference to the
current statement in the stack frame that is about to have control returned to
it is advanced, even though it was blocked. The result it was awaiting is
available at the point of failure, but because the current statement is
advanced, it is never collected and the newly restored activity execution is
permanently stalled.

5.2 Rectification

Since the interrupting activity was a signal, the return statement must be a
void type return as required by the parser. As such, the behavior should be
almost identical to that shown when an activity runs out of statements and exits
without a return. This scenario is handled in the Block.popUpBlock() operation.
Examination of the OAL in this operation shows that it checks for the existence
of blocking frame, an intermediate value and whether the interrupting activity
is a transition action. Since a return statement is not legal in a transition
action, this possibility is excluded, but the two other cases must be handled in
the defective case.

The locus of the problem itself is the Return Statement.execute() operation.
We surround the first call to Statement.setupNextStatement() with checks for:

5.2.1 Incomplete intermediate value computation

This is found by looking for an instance of 'Value in Stack Frame' found across
R2951 from the stack frame being resumed.

5.2.2 Outstanding blocking activity

{'fraction_non_alphanumeric': 0.04744339862630374, 'fraction_numerical': 0.011065886542864412, 'mean_word_length': 4.21765096217651, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2559272', 'n_tokens_mistral': 1834, 'n_tokens_neox': 1705, 'n_words': 1167}