[M3devel] Question about PM3

[Mika Nystrom]

Dear Modula-3-ers:

I'm going to ask a question about an old, obsolete piece of software, and
don't expect anybody knows the answer, but would be grateful for any
insight:

I have a Modula-3 program compiled with one of the last releases of PM3
"FreeBSD4" running on a FreeBSD/i386 5.5 system.  I have some code
that looks like this:

PROCEDURE UINext(i : UpIterator; VAR f : FIXField.T) : BOOLEAN =
  VAR seq : FIXFieldSeq.T;
  BEGIN
    LOOP
      (* update seq *)
      seq := i.t.data[i.part];

      (* first see if we are at end or pointing to an uninteresting part *)
      (* seq can be NIL on certain error conditions *)
      IF seq # NIL THEN
        IF i.nextI = seq.size() OR NOT i.part IN i.parts THEN
          IF i.part = LAST(Part) THEN (* at bitter end *)
            RETURN FALSE
          ELSE
            INC(i.part); i.nextI := 0
          END
        ELSE (* not at end, but in the middle of an interesting Part *)
          WITH cur = NARROW(seq.get(i.nextI),ProtocolFields.T) DO
            TRY
              IF cur.type() IN i.fields THEN (* nteresting field? *)
                f := cur; RETURN TRUE
              END
            FINALLY
              INC(i.nextI) (* in any case, advance to next *)
            END
          END
        END
      END
    END
  END UINext;

What I am seeing is the following

Program received signal SIGSEGV, Segmentation fault.
0x080be11c in M_FIXMsgSuper4_1_LINE_893 () at FIXMsgSuper.mg:893
#0  0x080be11c in M_FIXMsgSuper4_1_LINE_893 () at FIXMsgSuper.mg:893
893                   INC(i.nextI) (* in any case, advance to next *)
(m3gdb) list
888                 TRY
889                   IF cur.type() IN i.fields THEN (* nteresting field? *)
890                     f := cur; RETURN TRUE
891                   END
892                 FINALLY
893                   INC(i.nextI) (* in any case, advance to next *)
894                 END
895               END
896             END
897           END

The crash makes no sense, because "i" has already been dereferenced
several times before this, without problem.

(m3gdb) where
#0  0x080be11c in M_FIXMsgSuper4_1_LINE_893 () at FIXMsgSuper.mg:893
#1  0x080be26f in FIXMsgSuper4_1__UINext (i=16_0957a0d4, f=NIL) at FIXMsgSuper.mg:890
#2  0x080be01c in FIXMsgSuper4_1__GetSingleField (t=16_09579ea8, ofType=SenderCompID) at FIXMsgSuper.mg:846
#3  0x081087f3 in FIXMsg4_1__T_GetOnlySenderCompIDProc (self=16_09579ea8) at FIXMsg4_1.m3:411
#4  0x080bef29 in FIXEngine4_1__SanityCheckFields (t=16_082a896c, msg=16_09579ea8) at FIXEngine.mg:321

We're in some sort of "fake" stack frame, and...

(m3gdb) up
#1  0x080be26f in FIXMsgSuper4_1__UINext (i=16_0957a0d4, f=NIL) at FIXMsgSuper.mg:890
890                     f := cur; RETURN TRUE
(m3gdb) print i
$2 = (*16_0957a0d4*) OBJECT t = 16_09579ea8; parts = {Header, Body, Trailer}; fields = {SenderCompID}; part = Body; 
    nextI = 0;  END
(m3gdb) 

everything looks OK with i.

Is it possible there is some sort of problem with TRY .. FINALLY under
PM3?  And of course, if so, might it go away with CM3?

     Mika