[M3devel] cm3 is broken: More info
Jay K
jay.krell at cornell.edu
Sat Aug 22 19:26:33 CEST 2015
It is normal to get an exception here -- I think cm3 looks in current working directory..not great but that's how it is.
That is how I know my stuff is working -- exceptions are a normal part of operation. If you break them, you know it quickly.
Anyway, you need to go back to a working cm3 + cm3cg + config + libm3 + m3core and run upgrade.py.
Nothing else is going to work. (ok, maybe upgrade.sh works, but I didn't try it.)
The interface here between cm3's generated code/data and m3core has changed.
You cannot mix them. It will fail.
- Jay
> Date: Sat, 22 Aug 2015 11:41:14 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] cm3 is broken: More info
>
>
>
> On 08/22/2015 11:33 AM, Rodney M. Bates wrote:
> > There are at least two problems. The runaway recursion happens in RTExFrame.m3:175
> >
> > PROCEDURE InvokeHandler (f: Frame; READONLY a: RT0.RaiseActivation) RAISES ANY =
> > VAR p := LOOPHOLE (f, PF1);
> > BEGIN
> > IF DEBUG THEN
> > PutExcept ("INVOKE HANDLER", a);
> > RTIO.PutText (" frame="); RTIO.PutAddr (f);
> > RTIO.PutText (" class="); RTIO.PutInt (f.class);
> > RTIO.PutText ("\n");
> > RTIO.Flush ();
> > END;
> > RTThread.SetCurrentHandlers (f.next); (* cut to the new handler *)
> > p.info := a; (* copy the exception to the new frame *)
> > <* ASSERT p.jmpbuf # NIL *>
> > ------^^^^^^^^^^^^^^^^^^^^^^^^^^^ This assertion fails and tries to raise another fault.
> > Csetjmp.ulongjmp (p.jmpbuf, 1); (* and jump... *)
> > RAISE OUCH;
> > END InvokeHandler;
> >
> > (m3gdb) frame 0
> > #0 InvokeHandler (f=16_00007fff509f4af0, a=
> > RECORD exception = 16_00007ff696883aa0; arg = 16_00000000013e4ae8; module = 16_00007ff6968a3060; line = 50; pc = NIL; info0 = NIL; info1 = NIL; un_except = NIL; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:175
> > 175 <* ASSERT p.jmpbuf # NIL *>
> > (m3gdb) p p.jmpbuf
> > $31 = NIL
> > --------^^^
> > (m3gdb)
> >
> >
> > The original problem starts in FSPosix.m3:328, when cm3.cfg is not found:
> >
> > PROCEDURE Status(pn: Pathname.T): File.Status RAISES {OSError.E} =
> > VAR status: File.Status; fname := M3toC.SharedTtoS(pn);
> > BEGIN
> > IF CStatus(fname, status) < 0 THEN Fail(pn, fname); END;
> > ---------^^^^^^^^^^^^^^^^^^^^^^
> > M3toC.FreeSharedS(pn, fname);
> > RETURN status
> > END Status;
> >
> > (m3gdb)
> > #6 0x00007ff696593c14 in Status (pn=16_00000000013e4ac0, _result=RECORD type = 16_0000000000000001; modificationTime = ; size = 1; END)
> > at ../src/os/POSIX/FSPosix.m3:328
> > 328 IF CStatus(fname, status) < 0 THEN Fail(pn, fname); END;
> > (m3gdb) p pn
> > $30 = (*16_00000000013e4ac0*) "./cm3.cfg"
> > --------------------------------^^^^^^^^^^^
> > (m3gdb)
> >
> > I have a cm3.cfg beside cm3, where it should be. Could the current directory be wrong?
>
> A bit more info:
>
> (m3gdb) down
> #6 0x00007ff696593c14 in Status (pn=16_00000000013e4ac0, _result=RECORD type = 16_0000000000000001; modificationTime = ; size = 1; END)
> at ../src/os/POSIX/FSPosix.m3:328
> 328 IF CStatus(fname, status) < 0 THEN Fail(pn, fname); END;
> (m3gdb) p Process.GetWorkingDirectory()
> $32 = (*16_0000000001420170*) "/home/rodney/proj/m3/exp/trytemp/src"
> --------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> (m3gdb)
>
> This is where I ran cm3 from.
>
>
> >
> > Also, I notice one other thing, that probably isn't part of this problem, but maybe needs
> > to be fixed. Fail, when called from Status, uses Cerrno.GetErrno in a separate call,
> > after the failing CStatus above. Obviously not thread safe. Does it matter here?
> > As I recall from many years ago, there was a change in C library that provided a thread
> > safe alternative to this, and I even think I had to change something in pm3 or SRC to
> > adapt to it. Do we care?
> >
> > PROCEDURE Fail(p: Pathname.T; f: Ctypes.char_star) RAISES {OSError.E} =
> > VAR err := Cerrno.GetErrno();
> > ---------------^^^^^^^^^^^^^^^^^
> > BEGIN
> > M3toC.FreeSharedS(p, f);
> > OSErrorPosix.Raise0(err);
> > END Fail;
> >
> >
> >
> > On 08/19/2015 05:20 PM, Rodney M. Bates wrote:
> >> As of a recent pull from modula3-cm3, done around 16:00 CDT, cm3 is going into
> >> runaway recursion trying to report a fault. This happens immediately upon
> >> running it, before it produces any output.
> >>
> >> Here is one cycle of the backtrace:
> >>
> >> #1745 0x00007fd9b0b0d935 in _m3_fault (arg=5600) from /usr/local/cm3-uniboot/bin/../lib/libm3core.so.5
> >> #1746 0x00007fd9b0b0d05d in InvokeHandler (f=16_00007fff488bcc20, a=
> >> RECORD exception = 16_00007fd9b0d4b780; arg = 16_000000000000001d; module = 16_00007fd9b0d62d40; line = 14; pc = NIL; info0 = NIL; info1 = NIL; un_except = NIL; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:175
> >> #1747 0x00007fd9b0b0cef1 in ResumeRaise (a=
> >> RECORD exception = 16_00007fd9b0d4b780; arg = 16_000000000000001d; module = 16_00007fd9b0d62d40; line = 14; pc = NIL; info0 = NIL; info1 = NIL; un_except = NIL; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:145
> >> #1748 0x00007fd9b0b0ccfe in Raise (act=
> >> RECORD exception = 16_00007fd9b0d4b780; arg = 16_000000000000001d; module = 16_00007fd9b0d62d40; line = 14; pc = NIL; info0 = NIL; info1 = NIL; un_except = NIL; un_arg = NIL; END) at ../src/runtime/ex_frame/RTExFrame.m3:91
> >> #1749 0x00007fd9b0ae9693 in Raise (ex=16_00007fd9b0d4b780, arg=16_000000000000001d, module=16_00007fd9b0d62d40, line=14)
> >> at ../src/runtime/common/RTHooks.m3:79
> >> #1750 0x00007fd9b0ae9951 in Self () at ../src/runtime/common/RuntimeError.m3:14
> >> #1751 0x00007fd9b0ae96ef in ReportFault (module=16_00007fd9b0d6a520, info=5600) at ../src/runtime/common/RTHooks.m3:98
> >> #1752 0x00007fd9b0b0d935 in _m3_fault (arg=5600) from /usr/local/cm3-uniboot/bin/../lib/libm3core.so.5
> >>
> >> So far, I haven't had the patience to keep hitting return until I get to the bottom of it.
> >>
> >
>
> --
> Rodney Bates
> rodney.m.bates at acm.org
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150822/43ce95b9/attachment-0002.html>
More information about the M3devel
mailing list