[M3devel] Question about PM3

[Rodney M. Bates]

I have no immediate ideas, but a few questions and thoughts.

Consider the possibility that the segfault is something other
than dereferencing i, and the line number is misleading.  I don't
have any specific theories right off hand, but I  would try
(m3gdb) disass to see the machine code and (m3gdb) info reg
to see the registers, including the instruction pointer.
Relying on hardware traps to detect runtime errors does make
the checks fast, but it gives poorer explanations when something
goes wrong.

How recent is your m3gdb?  For a long time, it has been putting out
much better demangled names that what you are getting.  You can use
the m3gdb in the CM3 distribution and build just it with
'cm3/scripts/do-cm3-m3gdb.sh build' to get the latest.  The executable
will be in cm3/m3-sys/m3gdb/FREEBSD/gdb/gdb'.  It dynamically
adapts to PM3-compiled code (unless there is a bug :-).

Which code generator did you use, the integrated i386 backend or
the gcc-derived one?   (If you aren't sure, the latest m3gdb will
tell you this and other things about what language implementation
it uses with the 'info m3' command, entered after the M3 runtime
has initialized.)

If there is a code generation problem, it could also go away after
just changing backends.  However, I'm not sure if there would be
trouble without rebuilding all the libraries with the same backend
as your application.

Consider the possibility that the segfault is something other
than dereferencing i, and the line number is misleading.  I don't
have any specific theories right off hand, but I  would try
(m3gdb) disass to see the machine code and (m3gdb) info reg
to see the registers, including the instruction pointer.

Relying on hardware traps to detect runtime errors does make
the checks fast, but it gives poorer explanations when something
goes wrong.

Mika Nystrom wrote:
> 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
> 
>