#61 FB_AssertResultStatic.ReportResult - PLC Crash

v1.2.0.0
open
nobody
None
2022-05-18
2022-05-17
stmos
No

If I have a test that asserts a condition across multiple cycles in a timed test (by default more than 1000), the PLC crashes.

The 1000 number depends on the setup of the maximum number of asserts allowed in the library.

It is expected obviously for the PLC not to crash if the number of unique asserts, not already reported, are below 1000.

A simple example is a test like this one:

Declaration:

METHOD IfFail_test
VAR_STAT

    State : WORD := 0;
    PrevState : WORD := 0;

    Cycles : DINT := 0;
    Test_Signal : BOOL := FALSE;

END_VAR

Code:

TEST('PLC_EXCEPTION');
PrevState := State;

CASE State OF

    0:
        // Initialize test.
        AssertFalse(Test_Signal, 'Signal is active!');

        Cycles := Cycles + 1;

        IF Cycles > 2000 THEN
            State := 10;
        ELSE
            State := 0;
        END_IF; 

    10:
        TEST_FINISHED();

    ELSE
        State := 10;

END_CASE

I don't know exactly if this is "by-design".

Looking at the point where the exception is raised, I've found that the code of FB_AssertResultStatic.ReportResult has some information on how to distinguish assertions already "known" to the test, but the variables FoundOne and AdditionalIdenticalAssert are never set anywhere (at least for the knowledge I've of the code). Thus every assertion is considered a new assertion and recorded.

Discussion

  • stmos - 2022-05-18

    Attached a tentative solution for the problem, patch for the FB_AssertResultStatic.ReportResult method, based on what's implemented in FB_AssertArrayResultStatic.ReportResult.

     
    👍
    1
    FB_AssertResultStatic.ReportResult.diff

  • hermsen

    hermsen - 2022-05-18

    Hi, first off let me start by thanking you for using our unit testing framework solution. As you might know allready this software is an official fork of TcUnit. Therefore, we try to follow the original TcUnit codebase as close as possible or technically permitted. For instance, ADS will not work without a proper implementation in CODESYS, but a bespoke CI/CD runner is not necessary like in TwinCAT3. So there are pro's and con's.

    Currently we are waiting for the release of TcUnit v1.3 (or V2?). When it is officially released, you can be sure we will adopt the majority of that codebase into coUnit and hopefully that will plug the majority of the bugs. Since you have found an issue and have proposed a solution I will gladly integrate it into our framework. Just be aware that if a new TcUnit version is released, the proposed fix will be overwritten which might might undo your temporary fix. However with a little luck the original issue is mitigated in the TcUnit source. Sure porting the framwork is fun but it is also a very time consuming and complex task.

    With kind regards

    the co5e.org team

    ps if you are interested, we could add you to the development team so you can contribute if you like. Anybody who wants to contribute is welcome!

     
    👍
    1

    Last edit: hermsen 2022-05-18

Log in to post a comment.