1. Forum
  2. Usenet
  3. COMP.SYS.UNISYS

  • FALSE ASSERTION vs INVALID CASE

    From Barry Whenman@21:1/5 to All on Sat Apr 18 08:18:40 2020
    I’m looking at an ALGOL program which F-DSes with a FALSE ASSERTION. From the dump file I can see that the <arithmetic expression> of a Case statement has a value which is not explicitly handled - and since there is no Else condition it is clear why
    the program fails.

    However, I’ve built a simpler test case (by stripping out irrelevant code) to try to reproduce the problem – but that fails with an INVALID CASE exception (which is actually what I would expect).

    So my question is: why does one program fail with FALSE ASSERT and the other with INVALID CASE? What's the difference?

    Any ideas?
    Thanks,
    Barry.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Kimpel@21:1/5 to Barry Whenman on Sat Apr 18 11:43:14 2020
    On 4/18/2020 8:18 AM, Barry Whenman wrote:
    I’m looking at an ALGOL program which F-DSes with a FALSE ASSERTION. From the dump file I can see that the <arithmetic expression> of a Case statement has a value which is not explicitly handled - and since there is no Else condition it is clear why
    the program fails.

    However, I’ve built a simpler test case (by stripping out irrelevant code) to try to reproduce the problem – but that fails with an INVALID CASE exception (which is actually what I would expect).

    So my question is: why does one program fail with FALSE ASSERT and the other with INVALID CASE? What's the difference?

    Any ideas?
    Thanks,
    Barry.


    Without seeing the actual code for both cases, it's not possible to say.
    Would it be possible to post the full code, or at least make it
    available privately?

    I can think of two ways a CASE statement would fail:

    1. All of the CASE code I've seen uses an indexed branch table that the compiler emits after the end of the case. To limit the size of that
    table, it determines the minimum and maximum index values and generates
    a branch table that covers only that range. It also emits code to test
    the index for values above or below that range, and aborts appropriately.

    2. For invalid index values within the min/max range, the entry within
    the branch table triggers the abort.

    So there are two different modes of failure here, and it's possible that
    the abort takes place slightly differently between them. Is it possible
    that in simplifying the test case you've changed the failure mode?

    Another thing to look at is whether both situations use the same version
    of compiler and that the compiler is generating code for the same COMPILERTARGET level (e.g., EPSILON vs ETA).

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Barry Whenman@21:1/5 to All on Sun Apr 19 03:57:19 2020
    Thanks for your reply Paul,

    I'm reluctant to share publicly as this is client code, but I can try to send you something privately.

    My test case is based heavily on the original, and in particular it includes all the original index values (which range from 900-922 with a significant gap at 919); even though I've reduced the code to just a dummy display statement in most cases.

    The error actually occurs within a library call - and I've replicated that in my test - just in case. The only other difference I'm aware of is that the real code runs as an MCS.

    Ultimately this is just for my own understanding. I can fix the code by including an Else - though it would be better to understand where the 919 has suddenly started appearing from, in a program that has been in production for many years!

    Thanks again
    Barry.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Kimpel@21:1/5 to Barry Whenman on Tue Apr 21 09:50:18 2020
    On 4/19/2020 3:57 AM, Barry Whenman wrote:
    Thanks for your reply Paul,

    I'm reluctant to share publicly as this is client code, but I can try to send you something privately.

    My test case is based heavily on the original, and in particular it includes all the original index values (which range from 900-922 with a significant gap at 919); even though I've reduced the code to just a dummy display statement in most cases.

    The error actually occurs within a library call - and I've replicated that in my test - just in case. The only other difference I'm aware of is that the real code runs as an MCS.

    Ultimately this is just for my own understanding. I can fix the code by including an Else - though it would be better to understand where the 919 has suddenly started appearing from, in a program that has been in production for many years!

    Thanks again
    Barry.


    Just to close this issue for everyone else who has been following it,
    Barry sent me the source code in question. After some research on my
    part and additional investigation on his, it appears that the production
    and test systems he was using are both E-mode Eta (TARGET=LEVEL6)
    systems, both are running MCP 18 (although at somewhat different patch
    levels), and while the test code had been compiled for LEVEL6, the
    production code had not been recompiled in a while and was for E-mode
    Epsilon (TARGET=LEVEL5).

    Compiling his code for both levels, I discovered that Algol CASE
    statements generate quite different code between the two levels. LEVEL5
    uses traditional in-line code to check the bounds of the case indexes immediately after the branch index is evaluated, followed by a branch to
    the point after the CASE where a branch table is constructed for use by
    the DBUN operator.

    For LEVEL6, the branch to the point after the CASE occurs immediately
    after the case index is evaluated. The code there begins with a BTAB
    (hex 73) operator, followed by two 40-bit binary numbers containing the
    upper and lower case index bounds, followed by a branch table consisting
    of the necessary number of 32-bit BXTD branch instructions. BTAB looks
    to be a LEVEL6 addition specifically designed for this type of bounded,
    indexed branch. It must be doing the bounds checking and branch
    selection all in firmware.

    It appears that for, both E-mode levels, the use of an invalid case
    index leads to execution of a ZERO, ASRT 252 sequence, which will
    generate an invalid assertion interrupt. Why one system reports "INVALID
    CASE" and the other "ASSERTION FAILURE" remains unclear.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)