<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
I agree with Rodney's sentiment to double check whatever you can.<BR>
If you can rebuild the compiler/runtime, try growing the jmpbuf.<BR>
Or see what size is being used and write one line of C to see what it should be.<BR>
(#include <setjmp.h> #include <stdio.h> int main() { printf("%u\n", (unsigned) sizeof(jmpbuf)); })<BR>
If you are using user threads, try kernel threads and/or DisableSwitching/EnableSwitching around the crashing code.<BR>
Read the generated code to try to confirm correctness.<BR>
If you are optimizing the code, try not.<BR>
If the loop only runs "a few" times, print out the address as it is dereferenced.<BR>
See if the failing address is the same as one of the successful ones.<BR>
Nag me and I'll set up FreeBSD/x86/5.5, send me instructions to build pm3 and send me your code. :)<BR>
Try any other configuration. pm3 on Linux. cm3 on FreeBSD. cm3 on Linux. etc.<BR>
<BR>
- Jay<BR><BR><BR>> Date: Sat, 14 Feb 2009 14:30:23 -0600<BR>> From: rodney.bates@wichita.edu<BR>> To: mika@async.caltech.edu<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] Question about PM3<BR>> <BR>> I have no immediate ideas, but a few questions and thoughts.<BR>> <BR>> Consider the possibility that the segfault is something other<BR>> than dereferencing i, and the line number is misleading. I don't<BR>> have any specific theories right off hand, but I would try<BR>> (m3gdb) disass to see the machine code and (m3gdb) info reg<BR>> to see the registers, including the instruction pointer.<BR>> Relying on hardware traps to detect runtime errors does make<BR>> the checks fast, but it gives poorer explanations when something<BR>> goes wrong.<BR>> <BR>> How recent is your m3gdb? For a long time, it has been putting out<BR>> much better demangled names that what you are getting. You can use<BR>> the m3gdb in the CM3 distribution and build just it with<BR>> 'cm3/scripts/do-cm3-m3gdb.sh build' to get the latest. The executable<BR>> will be in cm3/m3-sys/m3gdb/FREEBSD/gdb/gdb'. It dynamically<BR>> adapts to PM3-compiled code (unless there is a bug :-).<BR>> <BR>> Which code generator did you use, the integrated i386 backend or<BR>> the gcc-derived one? (If you aren't sure, the latest m3gdb will<BR>> tell you this and other things about what language implementation<BR>> it uses with the 'info m3' command, entered after the M3 runtime<BR>> has initialized.)<BR>> <BR>> If there is a code generation problem, it could also go away after<BR>> just changing backends. However, I'm not sure if there would be<BR>> trouble without rebuilding all the libraries with the same backend<BR>> as your application.<BR>> <BR>> Consider the possibility that the segfault is something other<BR>> than dereferencing i, and the line number is misleading. I don't<BR>> have any specific theories right off hand, but I would try<BR>> (m3gdb) disass to see the machine code and (m3gdb) info reg<BR>> to see the registers, including the instruction pointer.<BR>> <BR>> Relying on hardware traps to detect runtime errors does make<BR>> the checks fast, but it gives poorer explanations when something<BR>> goes wrong.<BR>> <BR>> Mika Nystrom wrote:<BR>> > Dear Modula-3-ers:<BR>> > <BR>> > I'm going to ask a question about an old, obsolete piece of software, and<BR>> > don't expect anybody knows the answer, but would be grateful for any<BR>> > insight:<BR>> > <BR>> > I have a Modula-3 program compiled with one of the last releases of PM3<BR>> > "FreeBSD4" running on a FreeBSD/i386 5.5 system. I have some code<BR>> > that looks like this:<BR>> > <BR>> > PROCEDURE UINext(i : UpIterator; VAR f : FIXField.T) : BOOLEAN =<BR>> > VAR seq : FIXFieldSeq.T;<BR>> > BEGIN<BR>> > LOOP<BR>> > (* update seq *)<BR>> > seq := i.t.data[i.part];<BR>> > <BR>> > (* first see if we are at end or pointing to an uninteresting part *)<BR>> > (* seq can be NIL on certain error conditions *)<BR>> > IF seq # NIL THEN<BR>> > IF i.nextI = seq.size() OR NOT i.part IN i.parts THEN<BR>> > IF i.part = LAST(Part) THEN (* at bitter end *)<BR>> > RETURN FALSE<BR>> > ELSE<BR>> > INC(i.part); i.nextI := 0<BR>> > END<BR>> > ELSE (* not at end, but in the middle of an interesting Part *)<BR>> > WITH cur = NARROW(seq.get(i.nextI),ProtocolFields.T) DO<BR>> > TRY<BR>> > IF cur.type() IN i.fields THEN (* nteresting field? *)<BR>> > f := cur; RETURN TRUE<BR>> > END<BR>> > FINALLY<BR>> > INC(i.nextI) (* in any case, advance to next *)<BR>> > END<BR>> > END<BR>> > END<BR>> > END<BR>> > END<BR>> > END UINext;<BR>> > <BR>> > What I am seeing is the following<BR>> > <BR>> > Program received signal SIGSEGV, Segmentation fault.<BR>> > 0x080be11c in M_FIXMsgSuper4_1_LINE_893 () at FIXMsgSuper.mg:893<BR>> > #0 0x080be11c in M_FIXMsgSuper4_1_LINE_893 () at FIXMsgSuper.mg:893<BR>> > 893 INC(i.nextI) (* in any case, advance to next *)<BR>> > (m3gdb) list<BR>> > 888 TRY<BR>> > 889 IF cur.type() IN i.fields THEN (* nteresting field? *)<BR>> > 890 f := cur; RETURN TRUE<BR>> > 891 END<BR>> > 892 FINALLY<BR>> > 893 INC(i.nextI) (* in any case, advance to next *)<BR>> > 894 END<BR>> > 895 END<BR>> > 896 END<BR>> > 897 END<BR>> > <BR>> > The crash makes no sense, because "i" has already been dereferenced<BR>> > several times before this, without problem.<BR>> > <BR>> > (m3gdb) where<BR>> > #0 0x080be11c in M_FIXMsgSuper4_1_LINE_893 () at FIXMsgSuper.mg:893<BR>> > #1 0x080be26f in FIXMsgSuper4_1__UINext (i=16_0957a0d4, f=NIL) at FIXMsgSuper.mg:890<BR>> > #2 0x080be01c in FIXMsgSuper4_1__GetSingleField (t=16_09579ea8, ofType=SenderCompID) at FIXMsgSuper.mg:846<BR>> > #3 0x081087f3 in FIXMsg4_1__T_GetOnlySenderCompIDProc (self=16_09579ea8) at FIXMsg4_1.m3:411<BR>> > #4 0x080bef29 in FIXEngine4_1__SanityCheckFields (t=16_082a896c, msg=16_09579ea8) at FIXEngine.mg:321<BR>> > <BR>> > We're in some sort of "fake" stack frame, and...<BR>> > <BR>> > (m3gdb) up<BR>> > #1 0x080be26f in FIXMsgSuper4_1__UINext (i=16_0957a0d4, f=NIL) at FIXMsgSuper.mg:890<BR>> > 890 f := cur; RETURN TRUE<BR>> > (m3gdb) print i<BR>> > $2 = (*16_0957a0d4*) OBJECT t = 16_09579ea8; parts = {Header, Body, Trailer}; fields = {SenderCompID}; part = Body; <BR>> > nextI = 0; END<BR>> > (m3gdb) <BR>> > <BR>> > everything looks OK with i.<BR>> > <BR>> > Is it possible there is some sort of problem with TRY .. FINALLY under<BR>> > PM3? And of course, if so, might it go away with CM3?<BR>> > <BR>> > Mika<BR>> > <BR>> > <BR>> <BR><BR></body>
</html>