[M3devel] Question about PM3

[Jay]

I agree with Rodney's sentiment to double check whatever you can.
If you can rebuild the compiler/runtime, try growing the jmpbuf.
Or see what size is being used and write one line of C to see what it should be.
  (#include <setjmp.h> #include <stdio.h> int main() { printf("%u\n", (unsigned) sizeof(jmpbuf)); })
If you are using user threads, try kernel threads and/or DisableSwitching/EnableSwitching around the crashing code.
Read the generated code to try to confirm correctness.
If you are optimizing the code, try not.
If the loop only runs "a few" times, print out the address as it is dereferenced.
See if the failing address is the same as one of the successful ones.
Nag me and I'll set up FreeBSD/x86/5.5, send me instructions to build pm3 and send me your code. :)
Try any other configuration. pm3 on Linux. cm3 on FreeBSD. cm3 on Linux. etc.
 
 - Jay> Date: Sat, 14 Feb 2009 14:30:23 -0600> From: rodney.bates at wichita.edu> To: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Question about PM3> > 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> > > > > 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090214/cc921b2a/attachment-0002.html>