IBM Support

PH24026: INCORRECT STATECHART CODE GENERATION LEADING TO TIMING BUG

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

 

APAR status

  • Closed as program error.

Error description

  • Description:
    Incorrect statechart code generation leading to timing bug
    
    
    Environment:
    8.4 Build No. 9841247 64bit.
    Windows 10
    
    Summary:
    Incorrect statechart code generation leading to timing bug
    
    Steps to reproduce:
    The issue can be seen and reproduced in the Castle Image(Once
    you access EcuRep file, I will transfer VDI)
    
    Please look at the statechart for TestClass and TestClass.cpp in
    the attached example project.
    
    If the timeout for the transition out of TestClass state_0 fires
    but the guard condition is false, the variable rootState_timeout
    is left pointing to the OMTimeout object.
    ⠔⠔> This will get returned to the pool of available
    OMTimeouts by the framework dispatcher once the call to the
    classâ ™s handleEvent() returns.
    ⠔⠔> This OMTimeout object can then potentially be allocated
    to another timeout in another class while still pointed to by
    rootState_timeout in TestClass.
    
    
    If the timeout transition out of state_2 then fires with the
    guard condition true, state_0_exit() is called which cancels
    rootState_timeout,
    â ”-> Thus it wonâ ™t fire if another class statechart is now
    waiting on it.
    
    Conclusion from Skill Case:
    It is possible that generated code misses cleanup of expired
    timeout. It could cause its later cleanup, while this OMTimeout
    object already allocated for different timeout (in another
    instance).
    Correct code should look like:
    
      if(isEventTypeOf(OMEvent::getSxfTimeoutEventId()) == true)
        {
          if(getCurrentEvent() == rootState_timeout)
            {
              //## transition 5 
              if(x<6)
                {
                  state_0_exit();
                  //#[ transition 5 
                  x++;
                  //#]
                  state_0_entDef();
                  res = eventConsumed;
                }
                else
                 cancel(rootState_timeout);
            }
    }
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED:                                              *
    * Rhapsody                                                     *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    * There is a scenario, when already scheduled timeout is       *
    * deleted in another class, where it was used in conjuction    *
    * with transition guard equal false. The problem could occur   *
    * if statechart transition is defined with timeout trigger and *
    * guard. If guard is false but timeout expired, timeout data   *
    * struct is free and returned back to static pool. It may be   *
    * used for another timeout (in another class instance). But    *
    * its pointer variable stays not nullified and it could be     *
    * cleanup later in the statechart by calling of                *
    * cancelTimeout() function, which analyses value ot timeout    *
    * pointer. As a result this new timeout may be lost.           *
    * Note: the problem exists in SXF-based models only (because   *
    * it maintains static timeout pool).                           *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    

Problem conclusion

  • The timeout variable is  nullified if timeout expired even
    though guard is equal to false and transition is not performed.
    

Temporary fix

Comments

APAR Information

  • APAR number

    PH24026

  • Reported component name

    TLOGIC RHAPSODY

  • Reported component ID

    5724V74RP

  • Reported release

    840

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2020-04-03

  • Closed date

    2020-07-06

  • Last modified date

    2020-07-06

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

  • Fixed component name

    TLOGIC RHAPSODY

  • Fixed component ID

    5724V74RP

Applicable component levels

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SS7P9W","label":"Rational Rhapsody"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"840","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
14 December 2020