Programs for Programmers

Global Static Analysis


QA Method 2 – Dynamic Analysis

If a bug is defined as “an incorrect value in a storage location” then there is a large subset (perhaps 30%) which can be defined as “an undefined value in a storage location”, and many of the remainder may cause that condition as a knock-on effect.

The Dynamic Analysis option of plusFORT is a tool for diagnosing these errors at run-time. A test version of your program is created, which detects any use of an undefined variable or array element, and logs it to a file. In other respects, the test program behaves exactly like the original. This is done by inserting calls to probe routines in the source code before any operation which depends on the value of a data item. The program is compiled and linked in the normal way, and the executable code appears to the user to operate in exactly the same way as the original. However, if a probe detects an undefined data item, it writes details to a log-file for later analysis. Source code for the probe routines is supplied.

A static analyser such as GXCHK can detect a few of these errors, but the majority can only be detected at run-time. Dynamic analysis takes account of program control flow, works with real data, and can monitor individual bytes if required. However it only validates the code which is executed in a particular run. This makes it an almost precise complement of static analysis – each excels where the other is deficient.


FeatureStatic AnalysisDynamic Analysis
Checks code whether or not it executes Yes No
Checks for unsafe/questionable source code Yes No
Identifies used before set error Sometimes Yes
Checks status of individual array elements No Yes
Handles dependence on external data No Yes
Effective with dummy args, EQUIVALENCE poor Yes


Dynamic analysis excels at detecting bugs which depend on external data, or on the use of arrays. These characteristics defeat conventional analysers.

Dynamic Analysis – Worked Example

Original Code

      INTEGER Ival , Pos , vals(50) , ios
      READ(11,*,IOSTAT=ios) vals
      IF ( ios.EQ.0 ) THEN
         DO Pos = 1 , 50
            IF ( Ival.EQ.vals(Pos) ) GOTO 100
      Pos = 0
 100  END

QKNUM reads 50 numbers, and returns the position (Pos) of the first with value Ival.

If the data file contains “2,9,,11,20*44,26*“, the READ statement leaves some elements of vals undefined, and QKNUM behaves unpredictably.

Code with Dynamic Analysis Probes

      INTEGER Ival , Pos , vals(50) , ios
      CALL SB$ENT('QKNUM','DYNBEF.FOR') <-- initialize traceback and timing
      CALL UD$I4(IOS)                   <-- set variable IOS to undefined 
      CALL UD$AI4(50,VALS)              <-- set array VALS to undefined
      READ (11,*,IOSTAT=ios) vals
      CALL QD$I4('IOS',IOS,4)  
      IF ( ios.EQ.0 ) THEN 
         DO Pos = 1 , 50 
            CALL QD$I4('VALS(POS)',VALS(POS),6)   <-- check that VALS(IPOS) is defined before use
            CALL QD$I4('IVAL',IVAL,6)             <-- check that IVAL is defined before use
            IF ( Ival.EQ.vals(Pos) ) GOTO 99999 
      Pos = 0
99999 CALL SB$EXI                       <-- for traceback and timing data 


Sample Log-file

XTOP2(I+J) value is undefined
 subprogram    FCOMP line    838 file JASO.FOR
 subprogram    VSCAN line   4255 file JASO.FOR
 subprogram   VUTREE line   1049 file JASO.FOR

ICHR value is undefined
 subprogram    VSTOP line   6682 file JASO.FOR
 subprogram     JASO line   2241 file JASO.FOR


QA Method 3 – Test Coverage and Hot-Spot Analysis.

A reasonable goal for a software test suite is to ensure that every line of source code is executed at least once. The plusFORT coverage analysis facility allows users to monitor progress against this goal, as well as identifying “hot-spots” – the sections of code which are executed most frequently, and which have most effect on program execution time.

The plusFORT coverage analysis facility places probes into Fortran source code which allow users to monitor the effectiveness of testing. At the end of each run, the probes update the coverage statistics for each source file. This data may be analysed at any time using the CVRANAL tool. CVRANAL identifies untested code blocks, and execution hot-spots.

In addition, CVRANAL can annotate your source code as shown below. The annotations are comments and do not affect the validity of the source code.

Fragment of CVRANAL Test Coverage Report

   4 Untested code blocks in subprogram MOO in file TESTMOO.BEF
     at lines     27    32    33    62
NO   Untested code blocks in subprogram BC in file TESTMOO.BEF
NO   Untested code blocks in subprogram GETNUM in file TESTMOO.BEF
NO   Untested code blocks in subprogram INIT in file TESTMOO.BEF

Fragment of CVRANAL Execution Hot-spot Report

         49682 :       IF(IGUESS(IDIG).NE.IANS(JDIG))GOTO 10
               : in s/prog BC at line    82 of TESTMOO.BEF
         16336 :       IF(IGUESS(IDIG).EQ.IANS(IDIG))GOTO 40
               : in s/prog BC at line    80 of TESTMOO.BEF
         14399 :       DO 10 JDIG=1,NDIGIT
               : in s/prog BC at line    81 of TESTMOO.BEF
         11283 : 10    IF(J.EQ.NUM(JDIG))GOTO 20
               : in s/prog GETNUM at line   104 of TESTMOO.BEF
          9039 :       GOTO 20
               : in s/prog BC at line    86 of TESTMOO.BEF

Annotated Source Code


      NBULLS=0                                           !   4084
      DO 20 IDIG=1,NDIGIT
      IF(IGUESS(IDIG).EQ.IANS(IDIG))GOTO 40              !  16336
      DO 10 JDIG=1,NDIGIT                                !  14399
      IF(IGUESS(IDIG).NE.IANS(JDIG))GOTO 10              !  49682
      NCOWS=NCOWS+1                                      !   5360
      GOTO 20
      GOTO 20                                            !   9039
40    NBULLS=NBULLS+1                                    !   1937
      RETURN                                             !   4084