Memory retention bugs (memory leaks) in some versions of Java can lead to Statestep running out of memory. These vary by version and platform but the effect is the same: after using Statestep for an extended period of time, especially after opening and closing many windows, you may find that it starts to slow down and become less responsive. If this happens, save your model, exit and restart Statestep.

Most users should never encounter this problem. If it does occur, first try updating to the latest version of the Java Runtime Environment for your operating system. If that doesn't fix the problem, please report it to the address below. Statestep already implements workarounds for two known bugs of this kind.

Depending on the version of Java you have and your operating system, there may be occasional formatting errors in the display of windows containing hyperlinks, for example, the Help browser. Also, dialog boxes, that is, windows requiring some kind of confirmation or selection before proceeding, may fail to display properly: If only the window title bar at the top of a dialog box appears then just click its 'close window' icon (often an 'X'). Note: until you close the (mostly invisible) dialog, Statestep may appear to hang, since the other windows will be unresponsive.

These problems affect only some versions of Java and even then seem to occur very rarely.

Occasionally, to be logically complete, an explanation should include one or more variable definitions in addition to a list of constraints. For example, if asked to explain why the value b1 is not possible for variable B, the explanation provided by the program might be something like

• Constraint Table: A = {a1} => B = {b2}
• Constraint Table: A = {a2} => B = {b2 | b3}
• Constraint Table: A = {a3} => B = {b3}

In this case, the program is assuming you remember that

• Definition: A = {a1 | a2 | a3}

– that is, that these are the only three values defined for variable A.

This is one of those things that isn't a problem if you're aware of it. However, without definitions, an explanation is not strictly complete and this may sometimes be confusing.

A non-deterministic model is one where the rules allow for a choice of outcomes in the same case. If you don't create models of this kind, you can ignore what follows. You can also ignore it if the non-determinism arises through a choice of rules rather than a choice of outcomes within the same rule.

Statestep currently treats non-determinism in the most generous (forgiving) way: If a choice of outcomes within a rule means an error is not inevitable then it is not reported. This convention has the advantage of producing no spurious errors for incomplete rules (which are implicitly non-deterministic). Also, it is not generally much of a limitation: Even in non-deterministic models, most rules are likely to be deterministic.

However, it gives rise to a less obvious issue. Suppose a rule – call it rule R – in a finite state machine model permits a transition from state A to either state B or state C. Imagine the constraints make B impossible and so it should not be reachable. Because C is an alternative, it is possible to avoid entering B and so no violation is reported for rule R.

Now, imagine also that another rule for the same event, rule S, allows a transition from A to either B or D. In this case the program reports only an overlap between rules R and S: there is no conflict because, provided the choice of next state is B, both rules can agree.

This means that there is a problem with both of the possible choices of next state in rule R. However, because the checks for violations and conflicts are independent and because of the convention of ignoring avoidable errors, no error is reported. This is a subtle issue, but ultimately no more of a problem than the non-reporting of non-deterministic errors: even if the checks were combined, you would still have to be just as careful when modeling non-deterministic rules.